I spend a lot of my time trying to explain why a company needs an AI gateway. Half the time I end up in security mode: if you don’t give people a safe way to use MCP servers, they’ll pull them off the internet and go around you. That’s true, and it matters. But it’s not really the pitch.
The pitch is simpler. AI with tools is a completely different product than AI without tools. If your people are using a chat window with no connection to your systems, they’re getting a fraction of what AI can do for your business. The gateway is how you close that gap without losing control of it.
Last week on The Context, Emanuel and Atanas from BVNK told a story that makes that case better than I ever have. Bill Maxwell from our team sat in for Darren, who was off at GitHub Universe, and we got a very candid look at how a 400-person, Mastercard-owned fintech went from zero to 80 MCP servers and 200 regular users in about six months.
Who BVNK is
BVNK is a stablecoin payments company for enterprises. They’ve been around about five years, grew from under 100 people to close to 400, and were acquired by Mastercard early this year. Their products now sit at the center of the Global Money Platform Mastercard announced in October. They run 20-plus engineering teams, plus the usual finance, compliance, legal, product and commercial departments, and they operate under the kind of regulatory scrutiny you’d expect from a payments company that’s now part of a card network.
The AI team driving all of this is tiny. A data engineer, a tech lead Atanas described as a jack of all trades, and Atanas himself, who called himself “the nuts and bolts guy from the development world.” Their mandate was to use AI tools and experienced people to let the company deliver more with less. Emanuel is the platform product manager who works with them.
Before the gateway
The first phase will sound familiar. Engineers started with Cursor and used it for automations. Exposing internal tools to it was painful, so every tool became its own little project and almost nobody adopted them.
Then MCP arrived and the opposite problem showed up. In Atanas’s words, people started installing MCP servers “left, right and center.” The team had no control over what was running, and this is a company that had been watching the news: MCP servers compromised, VS Code extensions compromised, “even people in Microsoft got hacked.” For a regulated payments business, that’s not a tolerable state.
So they wanted a procedure. Scan the servers. Integrate with them once. Give people a centralized way to get to them. In other words, an AI gateway.
One day to production
My favorite moment in the episode was when I asked how long they evaluated Obot, our open source AI gateway, before putting it into production. Emanuel laughed and said Stanka, their tech lead, came to the team and said “I found something interesting,” and it was in production the next day.
To be fair to their process, it was a separate environment with limited capabilities, and it took about a month before they were using it at full extent. But it tells you what they were optimizing for. The field was changing too fast to commit to a vendor on a long evaluation. They wanted to try things, see the value, and then bind to a technology. Open source made that possible, and it’s why they lean on Agentic AI Foundation projects like Goose and Obot for the tools they hand to teams.
They deployed in March. Then Emanuel did something I think a lot of companies skip. He went to every team at BVNK and ran a training. One workshop for the whole company didn’t get the job done, so he did roughly 25 of them over two months, and some teams got retrained as the product changed from release to release. “It was a journey,” he said. “Definitely a journey.”
The part I keep thinking about
Here’s the thing I asked them to elaborate on, because it’s the heart of the story.
They started with a small focus group of business users and gave them the boring stuff. Mail. Sheets. The Google tools. Atanas said it “wasn’t even something spectacular.” But the day-to-day lives of those people visibly improved, and they started asking: can you add this one too? It would make my life easier.
So the team added it. Then another request came. Then another. They added the data warehouse. They added the ticketing system. Every new MCP server brought new requests and new users. The more they gave people, the more people wanted, and the more people showed up.
At one point they went a few months without adding servers and the backlog got so big that Atanas spent two full weeks doing nothing but adding MCPs. His fix was very much in the spirit of a three-person team: he wrote a skill that adds an MCP server to the catalog, so now anyone can do it by invoking the skill. “If we are not scrappy enough, we get overwhelmed,” he said. “We don’t want to be the bottleneck.”
Today they have more than 80 servers and about 200 people using them regularly, across engineering, finance, compliance, product and commercial teams. And it’s starting to level off, not because demand died but because, as Emanuel put it, people have 95% of the tools they need.
Atanas told me the single biggest impact was non-technical people querying the data warehouse themselves instead of raising a ticket and waiting days for the data team to get back to them. That put real pressure on the data team, who had to build semantic models so the agent would write the right queries without burning tokens going back and forth. But nobody pushed back. People just wanted more.
A couple of other numbers stuck with me. The team used the Claude Agent SDK, with their approved MCP servers preloaded, to let internal teams build their own support bots in plain English. Those bots are now the first line of defense on tickets for 12 business units and 14 product teams, with more than 20 commands and 25-plus contributors. They either solve the issue or hand an engineer a head start with the Grafana queries and warehouse data already pulled. And Atanas checked that morning: one in six MCP calls going through the gateway is a write. One in six is someone actually doing something in a system, not just reading from it.
How a regulated company moved this fast
If you’re a CISO reading this, the obvious question is how a payments company under Mastercard let 200 people loose on 80 MCP servers, including write access, in six months. The answer is that the governance was in place before the adoption curve started, and none of it was exotic.
Everyone at BVNK gets access to a general group of servers. Specific groups like legal and finance get additional servers on a need-to-know basis. Where it makes sense to have a per-user instance, they do that, with each person logging in separately. Where it doesn’t, they run one shared instance with secrets stored in AWS Secrets Manager.
They prefer official remote MCP servers wherever a vendor publishes one, because when a user authorizes against that external system, their claims and roles come with them. The list of tools the agent can see is the list that person is allowed to use. For external services that don’t speak MCP at all, Atanas called out Obot’s OAuth gateway as the feature he’s been using most: it turns the OAuth provider into your MCP provider, so you can wrap an existing API and put it behind the same access controls as everything else.
And then they watch it all. Atanas said observability is what gives them confidence. They can see how an agent is talking to each MCP server and how it reasons through a task. His advice for anyone deciding whether to make MCP a central function of their IT organization was three steps: get as many MCP servers as you can, let people work with them, and then observe them, because observability is what builds trust between the agents and the people using them.
Note the order. Governance wasn’t the thing that slowed adoption down. It was the thing that made it safe to say yes to the next request, and the one after that.
What they’re not building
I asked whether they were thinking about a bigger agent platform, the “software factory” layer on top of the LLMs and MCP servers. Emanuel’s answer was careful. They’re building in small pieces that can talk to each other, not a big internal infrastructure, because anything they invest in deeply could be obsolete in six months. They have an internal agent framework so any engineer can deploy an agent without wondering where or how, but they’re waiting for protocols to earn adoption the way MCP did before betting on them.
I think that’s exactly right, and it’s the same reason the AI gateway matters. It’s the one piece of this that doesn’t churn. Models change, clients change, agent frameworks come and go. The list of systems your people are allowed to reach, and the record of what they did there, stays.
Watch the episode
Thanks to Emanuel and Atanas for joining us from Bulgaria, and to Bill for stepping in. Emanuel also dropped some news at the very end: BVNK is releasing its own MCP server, a few months in the making, so their customers’ agents can check balances, review transactions and look up payments directly. It’s in private beta now. It does feel like an MCP server is becoming as important as a website. If you want to deliver your value in an agentic world, you have to deliver it in a way agents can consume.
