The MCP Gateway is not a brand-new beast.
It is the API gateway growing a weird, highly-specialised, new limb.
The limb matters. It has new joints, odd reflexes, and occasionally tries to operate the chainsaw because a PDF told it to. But the nervous system is still API management: identity, policy, routing, observability, audit, lifecycle, and the grim little question every platform team eventually has to answer:
What is this actor allowed to call?
Citrix gave us a useful market flare this week with its announcement of “NetScaler MCP Gateway capabilities” for unified governance of LLM and agentic AI traffic. Useful flare. Not gospel.
The interesting bit is not Citrix specifically. The interesting bit is that enterprise buyers are now being taught a new category label. “MCP Gateway” is starting to sound like a thing procurement will ask about before most architecture teams have decided what they actually need.
First, define the thing without drinking the Kool-Aid
I’m going to assume you know what the Model Context Protocol is…
For those who don’t know, The Model Context Protocol, introduced by Anthropic in November 2024, is an open standard for connecting AI assistants to external data sources, tools and services. In MCP terms, servers expose capabilities through primitives like tools, resources and prompts. Clients — usually agents or AI applications — connect to those servers over transports such as stdio or HTTP/SSE.
An MCP Gateway sits between clients (agents, AI Assistants), and servers. It mediates the calls. It decides which tool can be called, by whom, under which auth context, at what rate, with what logging, and ideally with some ability to revoke access when the robot starts redecorating production.
That sounds suspiciously familiar.
API gateways, AI gateways, MCP gateways, “agent control planes” — the boundary between them is collapsing around the same operational job: callers, credentials, policies, routing, observability and audit trails.
The protocol changes. The job does not.
Lesson One: agents are callers, not magical interns
We need to stop anthropomorphising agents in architecture diagrams
They are not interns. They are not colleagues. They are not tiny consultants living in your sidebar.
They are non-human API consumers with strange behaviour patterns: dynamic tool selection, delegated credentials, long chains of action, fuzzy intent, high confidence, and the situational awareness of a toddler with scissors. A very fast toddler. With OAuth.
That means the governance problem is not “how do we make the model nicer?” It is:
- Who is the agent acting for?
- Which workload or user identity is being delegated?
- Which tools can it discover?
- Which tools can it execute?
- Which destinations can those tools reach?
- Which actions require approval?
- Where is the full trace from human → agent → tool → API?
- How do we revoke, roll back, or at least stop the bleeding?
This is where the hype machine gets annoying. It keeps talking about agentic workflows as if “workflow” magically removes the need for boring controls. It does the opposite.
What actually needs governing
A serious agent access layer needs to govern identity, authorization, scopes, tool discovery, request routing, quotas, schema translation, prompt/tool injection risks, egress allow-lists, logging, tracing, approvals, revocation, rollback, policy-as-code, and lifecycle/versioning of tools… breathe.
Yes, that is a long list. Infrastructure usually is, once it leaves the keynote
Some of this is old API-management muscle: authentication, authorization, rate limiting, routing, transformations, analytics, catalogues, policy enforcement. Some of it is agent-specific ligament: delegated identity, tool-level risk, multi-step task correlation, human approval gates, destination-aware egress, and reversibility.
Cloudflare’s temporary accounts are a nice example of the identity shift. Their June 2026 pattern lets an AI agent run wrangler deploy –temporary and get a short-lived account that expires after 60 minutes unless claimed. That is not “give the bot an API key and pray.” It is ephemeral, claimable, policy-bound identity
That is the direction of travel.
The standards bit, because it does not end with MCP
MCP has momentum because it gives agents a common way to reach tools and data. Good. We need that.
But MCP is not the last protocol your platform team will have to care about. Google announced Agent2Agent (A2A) in April 2025 for agent-to-agent cooperation — capability discovery, task-oriented messaging, artifact exchange, long-running work, and authentication/authorization built on existing web standards. Google positions A2A as complementary to MCP: MCP is agent-to-tool; A2A is agent-to-agent.
Then there are OpenAPI-based tools, OpenAI-style function calling, Anthropic tool use, LangChain and LangGraph abstractions, Semantic Kernel plugins, and whatever acronym escapes from a strategy offsite next quarter.
So if you hard-wire your governance to one protocol flavour, you are not building an agent platform. You are building a migration project with better stickers.
Design for protocol plurality. Adapters at the edge. Common policy and audit underneath.
Citrix as market flare, not thesis
Citrix’s announcement matters because of what it signals. Their NetScaler language talks about securely routing, governing and observing agent traffic to backend MCP servers, with a single front door for MCP clients, policy enforcement, traffic monitoring, session persistence and rate limiting across MCP traffic. The coverage also highlights centralized authentication, tool-based rate limits, allow/block lists, model routing and usage tracking.
Trade press picked it up too. ITBrief framed it as NetScaler adding MCP Gateway for AI traffic, with enterprises controlling chatbot and agent traffic through one gateway. GBHackers framed it as securing LLM and agentic AI traffic from a single platform.
Again: not about Citrix. This is about the market deciding to rename a problem API people already know.
And once buyers learn the label, vendors will happily sell the label.
Some will deserve it. Some will slap “agentic” on a proxy and wait for the category fairy to visit procurement. (She is busy. She has a Gartner subscription and no patience.)
The security mechanism underneath the symptom
Prompt injection is the symptom people like to demo because it looks spooky.
The deeper mechanism is that tool-enabled agents convert text into network actions.
O’Reilly’s “prompt injection to data exfiltration in 3 hops” pattern is a good example: malicious instructions hidden in input data, an agent invoking a normal MCP tool, and then the MCP server making an outbound HTTPS request carrying exfiltrated data to an attacker-controlled destination. The nasty bit is that, from the system’s point of view, everything may look legitimate: the agent had permission to call the tool, and the tool had network permission.
The same piece points out why standard Kubernetes NetworkPolicy is often the wrong abstraction here: it is IP/port oriented and cannot distinguish destinations like api.github.com from another domain behind the same CDN, inspect outbound TLS SNI, or log which MCP server opened the connection by name. That matters because your security question is not merely “which pod talked to port 443?” It is “which agent, using which tool, under which user context, tried to send what, to where?”
One is packet plumbing. The other is accountability.
Why API-management discipline wins
This is where I will be predictably biased, because I have spent a long time in API management and I run Tyk.
Mature API-management discipline already knows how to deal with contracts, authentication, authorization, traffic shaping, transformations, versioning, catalogues, analytics, audit and policy enforcement. Agent infrastructure needs those muscles. It also needs new ligaments: tool-level policy, delegated identity, task-level traceability, approval gates, egress control and kill switches.
At Tyk we describe the MCP problem in deliberately boring terms: the same gateway discipline used for APIs, now applied to MCP. That is not because boring is fashionable. It is because boring is what survives contact with production.
The New Stack’s broader agent-control-plane framing gets at the same thing: the enterprise fight is about who controls the agent’s app/API surface, with portability, reversibility and customer control becoming architectural questions rather than marketing garnish
Whoever controls the tool endpoint controls the blast radius.
What I would build
If I were advising a platform team, I would not create a one-off proxy per agent experiment. That way lies YAML archaeology.
I would build an agent access layer as part of the API/platform control plane:
- central policy, with distributed enforcement where latency or locality demands it
- protocol adapters for MCP, A2A, OpenAPI, GraphQL and whatever comes next
- destination-aware egress controls, not just broad port 443 permission
- a registry of approved tools, owners, schemas and risk levels
- human approval for expensive, destructive or externally visible actions
- a full audit chain from human to agent to tool to backend API
- short-lived credentials, scoped tokens and immediate revocation
- kill switches and rollback/compensation paths for high-risk operations
This is not glamorous. It is plumbing with consequences.
A fair word for MCP-native gateways
There is real value in MCP-native gateways. MCP has semantics worth understanding: tools, resources, prompts, sessions, transports, server discovery, multi-step flows. A gateway that cannot see those things will be blunt.
So the argument is not “ignore MCP.”
The argument is: do not mistake protocol support for governance maturity.
A parser is not a policy model. A proxy is not an audit strategy. A dashboard is not a control plane just because someone put a gradient on it.
Enterprise buyers are about to be sold a category. Engineering leaders should define the architecture before the label defines it for them.
The dull control plane is the moat, the safety rail, and possibly the only thing between agentic productivity and a very expensive incident report
Make of that what you will, but I would rather reuse boring discipline than worship a shiny proxy.
