I’ve had the same conversation repeatedly this month.
Someone building an AI agent system, getting excited about MCP, connecting their agents to internal tools and then asking: “Wait, how do we rate limit this? How do we audit what the agents are calling? What happens if an agent goes rogue and starts hammering our internal APIs?”
We’ve been here before
Ten years ago, enterprises were running the same playbook with HTTP APIs. Teams were connecting services directly, scraping together point-to-point integrations, and then slowly discovering that at scale, you need a control layer. Rate limiting. Auth. Observability. Access policies. Routing. Security.
That’s why the API gateway market exists. It grew from a sensible answer to a real problem: when you have hundreds of services, thousands of clients, and millions of requests, you cannot manage traffic without a centralised control plane.
The global API management market is on track to hit $16.9 billion by 2029. That growth exists because enterprises learnt that direct API connections at scale are a liability, not a feature.
We are now repeating that lesson with AI agents.
What MCP is, and why it changes everything
The Model Context Protocol is Anthropic’s open standard for letting AI systems talk to external tools and data sources in a consistent way. Think of it as a common language for AI agents to connect to databases, APIs, services, calendars, CRMs, code repositories or pretty much anything.
Adoption has been extraordinary. MCP’s SDKs hit 97 million monthly downloads in March 2026, up from roughly two million at launch. Of ‘in production’ AI teams, 78% are now running MCP. Forrester predicts that 30% of enterprise app vendors will launch their own MCP servers this year. By the end of 2026, 75% of API gateway vendors will have MCP features.
That last stat is telling and suggests that the industry already knows where this goes.
The problems are almost identical
What I’m seeing in early enterprise MCP deployments rhymes almost perfectly with the early API management challenges we addressed with Tyk :
Authentication is a patchwork. Individual MCP servers implement their own auth. Some use API keys. Some use OAuth. Some use nothing. When you have 50 agents calling 30 different MCP servers, you have an authentication nightmare. Every enterprise building on MCP is discovering this as the project moves out of innovation and into line-of-business.
Nobody can see what’s happening. An AI agent makes a tool call. The tool responds. There’s no unified place to understand what happened, how long it took, whether it’s a pattern, whether it’s a problem. Observability in raw MCP is essentially zero unless you build it yourself.
Rate limiting is an afterthought. An AI agent, especially one in an agentic loop, can make tool calls at machine speed. Many internal services were not designed to handle that. Without rate limiting at the gateway layer, a misconfigured agent can take down internal infrastructure in minutes. With LLM driven capabilities launching onto the public web, with non-deterministic behaviour, this is a real and present risk.
Audit trails don’t exist. For any enterprise operating in a regulated industry, whether financial services, healthcare, government or defence, knowing exactly what data an AI agent accessed, when, and why is not optional. It’s a compliance requirement. The raw MCP protocol doesn’t give you that.
Access control is tribal knowledge. Which agents should be allowed to call which tools? What’s the policy for an agent that tries to access a system it shouldn’t? Right now, most enterprises are answering this question with a mix of hope and spreadsheets.
These are not exotic problems, though they come with exotic budgets, blessed by the LLM aura. These are the same problems that drove the API gateway market to exist.
We are just running the same script, a decade later, with a different protocol.
“Almost identical”
AI agent behaviour is non-deterministic in ways that HTTP APIs are not. An agent making tool calls does not behave predictably, and a gateway alone cannot solve the alignment and safety challenges that come with autonomous AI systems. The governance layer is necessary but not sufficient.
The harder problems of constraining what an agent is allowed to decide, not just what APIs it’s allowed to call, are still to be solved convincingly.
A gateway gets you auditability and access control. It does not get you intent-level governance.
What it does get you is visibility and control over the infrastructure layer. And that’s where every enterprise we’re speaking to now, is starting.
What good looks like
We’ve been building Tyk’s MCP gateway to address exactly these patterns.
The same control plane that enterprises use for their REST and GraphQL APIs: auth, rate limiting, routing, analytics, access policies; now handles MCP traffic. One platform, one place to see what’s happening across API and AI traffic.
But the wider point is not about Tyk. It’s that every serious enterprise building with AI agents will need to answer these governance questions. The ones that answer them early, with a coherent strategy, will move faster and more safely than the ones that bolt on governance after the fact.
We were instrumental in building the API gateway category because distributed services at scale need a control layer. We’re doing the same for a new generation of distributed AI.
The Open Source MCP Gateway
If you’re building AI agents and you haven’t thought about how you’ll handle auth, rate limiting, audit trails, and access policies at scale, start now.
We built these control layers once. We’re building them again. The good news is we know what they need to do and we’ve made our MCP Gateway Open Source.
Further reading
