MCP Gateway Controls Every Enterprise Deployment Should Have

When MCP went from developer curiosity to Fortune 500 infrastructure in roughly two quarters, the security apparatus did not keep pace. The protocol was built to make agents capable, not to enforce enterprise access boundaries, and the gap between those two objectives is now measurable in CVEs, exposed credentials, and at least two production incidents serious enough to pull integrations offline. An MCP gateway is the architectural answer to that gap, but only if it is running the right controls. The gateway itself is just a choke point; what runs through it determines whether it provides real protection or just the appearance of one.

The vulnerability profile that uncontrolled MCP deployments produce

The numbers are not subtle. More than 30 CVEs were filed in the first two months of 2026 alone. Path traversal vulnerabilities appeared in 82% of tested MCP implementations across more than 2,600 servers in Endor Labs' 2025 assessment. Command injection showed up in 43% of tested servers. SSRF in more than 36% of over 7,000 servers scanned by BlueRock Security in 2026. A third of 1,000 servers scanned by Enkrypt AI in October 2025 carried critical vulnerabilities. These are not edge cases discovered by unusually aggressive researchers. They are the predictable output of a permission-rich protocol that scaled faster than its governance model.

Credential exposure sits at the center of the problem. Astrix Research found that 53% of more than 5,000 public MCP servers use hard-coded credentials, and 88% of those servers require credentials at all. GitGuardian tracked over 24,000 unique secrets exposed in MCP configuration files in 2025 alone, including Google API keys and PostgreSQL connection strings. Only 8.5% of public MCP servers use OAuth. That last figure is worth sitting with: the authentication standard the spec formally endorsed has been adopted by fewer than one in twelve servers currently running.

Trend Micro scanned the public surface and initially found nearly 500 confirmed MCP instances running with no client authentication and no traffic encryption. A follow-up scan found close to 1,500 exposed servers, nearly three times more, with the vast majority still running the long-deprecated SSE transport. That growth in exposed surface happened without any corresponding growth in controls.

The real-world incidents give the statistics their weight. CVE-2025-6514 in mcp-remote was a shell command injection that compromised more than 437,000 developer environments. CVE-2025-49596, scored at a CVSS 9.4, allowed arbitrary command execution against unauthenticated MCP Inspector instances. In June 2025, a privileged Supabase Cursor agent processing support tickets was manipulated through prompt injection into leaking integration tokens. That same month, an MCP-powered Asana feature caused customer data to bleed across MCP instances; the integration was pulled offline for two weeks. The Azure MCP Server SSRF vulnerability, CVE-2026-26118, demonstrated something important that the other incidents also imply: inbound authentication alone is not sufficient.

There is one more dimension that makes this profile genuinely uncomfortable. MCPTox benchmark testing found that o1-mini had a 72.8% attack success rate against tool poisoning. More capable models, the ones enterprises are deploying precisely because of their capability, are more susceptible to this class of attack. The model's ability to follow complex, nuanced instructions is exactly what the attacker exploits. Gartner projects that 25% of enterprise breaches will be traced to AI agent abuse by 2028, and that through 2029, more than half of successful attacks on AI agents will exploit access-control issues. That is where this is going. The gateway controls below are what stand between current exposure and that projected outcome.

What an MCP gateway actually does, and what it cannot do

The architecture is straightforward to describe. The gateway sits between AI agents and MCP servers as a reverse proxy. Every request is authenticated, authorized, routed to the correct server, returned to the requester, and logged, all before any tool executes. Nothing reaches a tool that has not passed through that sequence.

What makes an MCP gateway different from a traditional API gateway is the unit of analysis. Traditional API gateways see individual HTTP requests in isolation; they have no view of conversational context. An MCP gateway must inspect that context, enforce tool-level permissions within a single endpoint, detect prompt injection attempts, and maintain audit trails that capture the full chain from user prompt through multiple tool invocations to a final response. That chain, prompt to agent decision to tool selection to data access to response, is exactly what traditional API gateways were not designed to evaluate.

The alternative to a gateway is distributing security responsibility across every individual MCP server. That approach guarantees inconsistency. Some servers will implement it well; most won't, and defenders rarely have the visibility to tell the difference. Attackers reliably find the gaps. Cycode's 2026 State of Product Security found that 81% of organizations have zero visibility into how their AI agents are consuming external data or which tools are being pulled in. That organizational condition is precisely what the gateway is designed to correct.

Honest accounting requires acknowledging what a gateway cannot do. It is not a semantic abuse detector; it can determine whether an action is authorized, not whether it is contextually appropriate. It does not protect the management plane. It does not prevent schema drift if tool manifests are not pinned at registration, a vector sometimes called "rug-pull" behavior, where a server changes what a tool does after it has already been approved. The gateway is an enforcement layer, not a catch-all. The controls running through it determine its value.

Strong identity at the entry point: OAuth 2.1 with enterprise IdP integration

The November 2025 MCP specification formalized OAuth 2.1 as the authentication standard for remote MCP servers. Implementation quality across the ecosystem varies considerably, and the 8.5% adoption rate on public servers tells you that the specification alone does not drive uptake. A gateway makes it the default.

The minimum viable posture is specific. Every remote endpoint requires OAuth 2.1 with PKCE. Tokens are stored centrally, not in client configurations, which eliminates the hard-coded credential pattern that the majority of public servers still rely on. Access is scoped through enterprise IdP groups rather than per-user configuration. Every tool invocation is logged with user identity attached. Sensitive operations require explicit approval before execution.

For cloud-native teams, managed identity is the cleanest implementation path. Azure API Management's MCP support integrates natively with Entra ID, enabling agents running in Azure Container Apps or AKS to authenticate via managed identities, with no client secrets to rotate. Platforms like Kong, Zuplo, and Gravitee offer MCP-aware gateway capabilities with IdP integration that covers the same requirements for teams not anchored to a single cloud. Tyk, similarly, provides an enterprise gateway layer that can enforce OAuth 2.1 upstream of MCP servers across heterogeneous environments.

The reason central token management matters is operational, not just architectural. When tokens live in client configurations, rotation is a per-developer task; coordination failures are routine. When the gateway holds them, rotation is a single operation that propagates everywhere. The 8.5% OAuth adoption figure is not evidence that OAuth is difficult to implement. It is evidence that the default implementation path does not require it. The gateway changes that default.

Tool-level access control: limiting what each agent can reach

OWASP's MCP Top 10 identifies over-privilege as the foundational risk pattern, and the framing is correct. When a customer support agent carries the same credentials as a database administrator, a successful attack against that agent exposes the database. The blast radius of any compromise scales directly with how much access the compromised agent held. Tool-level ACLs are blast-radius containment, and that is the right way to think about them.

The mechanics at the gateway level are straightforward. The backend MCP server may expose many tools; the gateway presents only the subset explicitly authorized for each agent or consumer group. The default posture is deny: no agent receives tool access unless it has been explicitly granted through a policy or consumer group mapping. One OAuth scope per tool, enforced at the gateway, not at the server level and not embedded in the agent's prompt.

The March 2025 MCP specification update introduced tool annotations indicating whether a tool is destructive, read-only, and similar properties. Well-configured gateways can use these annotations to enforce annotation-aware policies, flagging or blocking destructive tool calls that appear in contexts where they would not be expected. That is a meaningful layer of defense against agents that are operating outside their intended scope.

Tool registry pinning is the control that closes the rug-pull vector. Manifests pinned at registration mean that a tool cannot change its behavior after it has been approved without triggering a re-review. ACLs alone do not catch this; a tool can be authorized for a purpose it no longer performs. Pinning is what keeps the authorization model current with the actual tool behavior.

An agent that is compromised but constrained to two tools does bounded damage. An agent compromised with access to a full server does not. That distinction is the entire argument for tool-level ACLs.

Rate limiting and request throttling tuned to agent behavior

Agent traffic patterns are fundamentally different from human API traffic, and rate limiting designed for human interaction rates will fail in both directions. A single agent task can trigger dozens or hundreds of tool calls in rapid succession as part of normal operation. A limit calibrated for human use will throttle legitimate orchestration. A limit calibrated loosely enough to accommodate agent bursts may leave the door open to runaway loops.

MCP-aware rate limiting needs to handle several distinct dimensions simultaneously. Per-agent limits must account for multi-step task execution, not per-user limits based on human interaction cadence. Per-tool limits should reflect the cost and sensitivity of individual tools: a read against a public dataset carries different risk than a write to a payment system, and the limits should reflect that difference. Burst allowance must accommodate legitimate orchestration patterns without enabling recursive agent loops. Token budget enforcement adds a complementary constraint, limiting not just the number of calls but the volume of data an agent can pull within a session.

Agent runaway loops, where an agent enters a recursive tool-calling pattern and does not self-terminate, are a production failure mode. Catching them at the model layer depends on model behavior, which varies across providers and versions. Catching them at the gateway is deterministic and does not depend on model self-regulation.

Rate limiting is also a cost control. Uncapped agent tool use against third-party APIs passes directly through to vendor billing. The gateway is the appropriate place to enforce spend envelopes, and the operational pressure to do so is real even where the security pressure has not yet landed.

Input and output inspection to catch prompt injection and data leakage

The 72.8% tool-poisoning attack success rate against o1-mini from MCPTox testing is the number that concentrates attention on this control. The capability that makes a model valuable, its ability to follow complex, layered instructions, is exactly what an attacker exploits in a prompt injection. Authentication and ACLs do not catch it. The Supabase Cursor agent incident in June 2025 demonstrated this precisely: a legitimate, fully authorized agent processing user-supplied content was manipulated into performing actions its operators never intended. Every authorization check passed. The inspection layer was the missing piece.

Content inspection at the gateway layer works across three directions. Inbound inspection scans tool call parameters for injection patterns, known malicious payloads, and attempts to override system instructions before they reach the tool. Outbound inspection scans tool responses before they reach the agent, catching sensitive data patterns including credentials, PII, and internal system paths that should not flow into the model context. Cross-turn context inspection flags sequences where earlier conversational turns appear to be establishing preconditions for a later injection, a pattern traditional API gateways cannot evaluate at all.

Indirect prompt injection is the specific attack vector that makes outbound and cross-turn inspection critical. Content retrieved from external sources, documents, emails, database records, can contain instructions directed at the agent. The gateway's inspection layer is the only infrastructure control positioned to intercept this before it reaches the model.

Output inspection also carries a compliance function that is distinct from its security role. Preventing the model from echoing regulated data, PHI, PCI-scope fields, back through tool responses is a data-handling obligation in many regulated industries. It is not discretionary.

The limitation to state plainly: content inspection at the gateway is heuristic and pattern-based. It catches known patterns reliably and novel patterns poorly. It is a necessary layer, not a complete one. Treating it as the latter is a mistake.

Real-time audit logging that captures the full agent action chain

The Asana incident is the clearest argument for logging, and the timing is the clearest part of the argument. Two weeks elapsed between the data bleed and its discovery. For two weeks, the exposure was real, active, and organizationally invisible. A complete, real-time audit record collapses that window.

What a complete audit record must capture, in sequence: the user prompt or agent trigger that initiated the chain; the identity of the agent and the session context; each tool invocation, including which tool was called, with what parameters, and at what time; the response returned by each tool; and any exceptions, rejections, or anomalies flagged by other gateway controls. The chain from prompt through every tool invocation to final response must be reconstructable as a single coherent sequence, not as disconnected log lines that require manual correlation.

That reconstruction is what makes the audit log operationally useful rather than just archivally complete. Incident response requires the ability to answer: what did this agent do, in what order, with what data, and on whose authorization. Logs that answer those questions in sequence transform a two-week discovery gap into something measured in minutes. They also provide the evidentiary record that compliance obligations in regulated industries require, not as a secondary benefit but as a core function.

The 81% of organizations with zero visibility into agent data consumption are organizations that cannot answer those questions today. The audit log is where visibility becomes operational. Every other control in the gateway generates an event; the logging layer is what turns those events into a record that can be queried, alarmed on, and acted upon. Without it, the gateway enforces in the moment and disappears from memory. With it, enforcement becomes accountable.