The Model Context Protocol (MCP) is rapidly changing how AI agents interact with the world, moving from a novel concept to critical enterprise infrastructure. As one developer in the r/MCPservers community recently noted, "My take is that MCP servers are starting to function as 'the new APIs' — not because they fully replace REST/GraphQL, but because they increasingly become the standard integration layer between business systems and AI agents/clients." But as enterprises rush to give their agents access to internal tools, a critical architectural debate has emerged: how do you secure these connections?
For years, the default answer in machine learning and AI development has been the SDK. Want to add guardrails to your generative model? pip install guardrails-ai or npm install some-middleware. Want to log actions? Add a telemetry package to your LangChain setup. But as AI agents move from single-script prototypes running on local machines to polyglot, multi-tenant enterprise deployments interacting with sensitive data, this library-level approach is fundamentally breaking down.
Hyperscalers and cutting-edge tech companies are signaling a massive architectural shift. At the recent Agentic AI Foundation Keynote, engineering leaders from Uber and Anthropic made it clear: to secure autonomous AI agents at scale, you must abandon heavy SDKs and embrace the MCP Gateway.
In this post, we will explore why the industry is shifting from embedded SDKs to inline network proxies, how an MCP Gateway differs from an MCP server, and how you can implement an agentic workflow without writing a single line of security middleware code.
Why Doesn't Library-Level AI Security Scale?
The "middleware SDK" approach—embedding security guardrails directly into the agent's application code (like Python, LangChain, or CrewAI)—seems intuitive at first. It gives developers direct programmatic access to the data flowing in and out of the LLM. However, it introduces a cascade of operational, architectural, and security failures at scale.
The Polyglot Nightmare in Enterprise AI
Modern enterprises do not write all their software in a single language, and they certainly don't write all their AI agents in Python. A typical platform engineering team might have a customer support agent written in TypeScript (using the Vercel AI SDK), a backend data analysis agent in Go, and high-performance Rust agents for low-latency, mission-critical tasks.
If your enterprise security strategy relies on a Python SDK or a LangChain-specific wrapper, you immediately fracture your security posture across different languages. You are forced to either maintain feature parity across half a dozen different security SDKs, or worse, leave non-Python agents completely unprotected. This creates massive blind spots in your architecture.
The "Bring Your Own Agent" (BYOA) Problem
Perhaps the most fatal flaw of the SDK model is that it assumes you actually own and control the agent's application code. In the era of "Bring Your Own Agent" (BYOA), this assumption is entirely false.
Developers are increasingly using standalone coding agents like Cursor, Claude Code, or GitHub Copilot Workspaces to automate their workflows. As discussed in our previous post, Your AI IDE Is an Attack Surface, security teams have zero ability to inject custom SDKs into these closed, third-party environments. If an employee connects their local, unmodified Claude Code instance to a sensitive internal database via an MCP tool, an SDK-based security posture is entirely blind to the interaction.
What Do the Contrarians Say About SDKs?
While many traditional MLSecOps vendors push heavy Python SDKs (like guardrails-ai) to embed into agent code, the emerging consensus at hyperscalers is quite the opposite. The contrarian view—which is rapidly becoming the mainstream enterprise view—is that network-level gateways are fundamentally superior because they decouple agent architecture from data and security layers. You cannot trust an agent to police itself, especially if the agent might be compromised via indirect prompt injection.
What is an MCP Gateway?
An MCP Gateway is a network-level middleware proxy that sits securely between the AI agent and its target tools or data sources (the MCP servers). Instead of living inside the agent's memory space or application codebase, it operates on the network boundary.
How Does an MCP Gateway Differ from an MCP Server?
To understand the architecture, we must clarify the terminology:
- MCP Server: The endpoint that exposes specific capabilities to an agent. This could be a GitHub search tool, a Postgres query runner, or a web scraper. As noted in a recent
r/WebDataMiningpost: "If you have set up an AI agent lately, you have probably seen that scraping vendors now ship an MCP server... This is spreading fast." - AI Gateway: A proxy sitting between the application and the LLM provider (like OpenAI or Anthropic). These gateways focus on rate limiting, prompt caching, routing, and basic prompt injection detection.
- MCP Gateway: A proxy sitting between the agent and the tools. It focuses on authorization, tool-use auditing, and semantic payload inspection before the agent is permitted to execute an action on a target system.
Can an AI Gateway Replace an MCP Gateway?
Unlike a traditional AI API gateway, an MCP Gateway must handle the highly specific and complex nuances of the Model Context Protocol. This includes dynamic tool discovery, managing Server-Sent Events (SSE) for streaming responses, and handling complex protocol buffers.
Handling these protocols is notoriously difficult. For instance, developers frequently encounter edge cases when dealing with raw MCP connections. A recent issue in the popular Dify framework highlighted how systems "cannot authorize streamable-http MCP servers when URL path's last segment isn't mcp/sse — SSE-first fallback never triggers" (Langgenius/dify Issue #39301). An enterprise-grade MCP Gateway abstracts these connection complexities away, providing a stable, unified connection point.
By centralizing these controls at the network layer, the gateway achieves what Karan Sampath of Anthropic calls "establishing a unified root of trust." The agent only talks to the gateway, and the gateway strictly enforces the rules before routing any traffic to the underlying MCP servers.
How Did Uber and Anthropic Standardize on Gateways?
The shift toward gateways is not theoretical; it is already powering some of the largest, most sophisticated agentic deployments in the world.
In his recent talk, Gateways are All You Need, Anthropic's Karan Sampath directly addressed the limitations of direct agent-to-tool connections. He noted:
"MCPs are often flaky, face multiple security vulnerabilities, and are generally hard to scale. Most enterprises struggle to use more than single digit numbers of MCPs due to issues with security, observability, and access control... Gateways establish a unified root of trust."
Uber's platform engineering team reached the exact same conclusion when attempting to scale their internal AI operations. During their Agentic AI Foundation Keynote, How Uber Runs 60,000 AI Agent Tasks Per Week With MCP, they detailed their transition to an MCP Gateway and Registry architecture.
The scale of Uber's deployment is staggering: they support 5,000+ engineers, 10,000+ services, and 1,500+ monthly active agents generating 60,000+ agent executions per week.
Attempting to manage access control, PII redaction, and code scanning by distributing SDK updates to 1,500 distinct agents would be a logistical nightmare. It would require coordinating dependencies across hundreds of teams. Instead, Uber's agents connect to a central MCP Gateway. This gateway handles central authorization and PII redaction at the network layer. This architecture allows them to scale agentic workflows rapidly without fragmented security lifecycles slowing them down.
How Does a Gateway Solve the 3-Headed Hydra of Agent Operations?
Anthropic identifies observability, access control, and security as the "three-headed hydra" of agent operations. An MCP Gateway solves all three simultaneously, robustly, and without touching a single line of the agent's code.
1. Central Authorization and Identity-Aware Proxying
When agents connect directly to MCP servers, managing credentials is chaotic. Teams end up hardcoding API keys into environment variables or scattering secrets across various agent configurations.
An MCP Gateway acts as an identity-aware proxy. It authenticates the calling agent, verifies its permissions in a central registry, and then seamlessly injects the necessary credentials (like short-lived OAuth tokens) into the request destined for the target tool. The agent never possesses the raw API keys. If an agent is compromised, the attacker cannot simply dump the environment variables to steal the keys, as the keys are held securely by the gateway.
2. Network-Level PII Redaction and Data Loss Prevention (DLP)
Agents frequently ingest massive amounts of data from tools. For example, an agent might retrieve a customer's full profile from a Salesforce MCP server just to answer a simple billing question.
An MCP Gateway inspects the payload returning from the tool and performs network-level Data Loss Prevention (DLP). It strips out Social Security Numbers, credit cards, or sensitive Protected Health Information (PHI) before the data ever hits the agent's context window. Because this happens at the gateway level, the sensitive data never reaches the LLM provider, ensuring compliance with strict data residency and privacy regulations. For more on how this works, see our guide on Data Exfiltration via AI Agents.
3. Tamper-Evident Audit Logs and Independent Observability
Relying on an agent to log its own actions is a severe security anti-pattern; if an agent is compromised via a prompt injection attack, it can easily be instructed to alter, suppress, or delete its own logs.
An MCP Gateway provides tamper-evident audit logs because it observes the network traffic independently of the agent runtime. The metrics, tracing, and tool-use auditing are completely decoupled. Security teams get an immutable record of exactly which tools the agent called, what parameters it used, and what data it received, regardless of the agent's internal state.
How Do You Implement an Agentic Workflow Without Heavy SDKs?
To visualize how this architecture comes together in practice, consider a standard enterprise flow where a developer is using a coding agent (like Claude Code) to analyze internal repositories and push changes.
The Direct Architecture (Vulnerable and Unmanageable): Claude Code (Local Machine) -> Direct Network Connection -> Internal GitLab MCP Server
In this model, the local agent has direct, unmediated access to the internal server.
The Gateway Architecture (Secure and Scalable): Claude Code (Local Machine) -> MCP Gateway (Enforces Rules) -> Internal GitLab MCP Server
In this secure model, the gateway intercepts the request.
Enforcing Deterministic Boundaries at the Network Layer
By routing through the gateway, security teams can enforce deterministic hard boundaries rather than relying on probabilistic LLM guardrails. For a deeper dive into this philosophy, see our post on Guardrails vs. Hard Boundaries.
This is critical because recent disclosures have highlighted severe vulnerabilities in open-source MCP implementations. A recent disclosure in the r/AI_Governance subreddit titled MCP Security Just Became a Must-Defend Problem noted "4,982 known vulnerabilities across 2,259 exposed MCP servers," alongside an alarming 85% agent hijacking success rate. They concluded: "Three weeks ago, MCP security was 'optional hardening.' Today it's an operational risk you cannot ignore."
A primary attack vector against these servers is Server-Side Request Forgery (SSRF), where an agent is tricked into using a web-fetching tool to access internal cloud metadata endpoints. As highlighted in a recent GitHub issue for the Agenta-AI project (Harden user-MCP http SSRF guard), preventing DNS rebinding and loopback SSRF is critical for any open-source project turned on by default.
An inline gateway blocks these attacks deterministically. Tools like the open-source ToolBastion project demonstrate how an MCP security gateway can enforce loopback SSRF blocks and path traversal mitigation before the target execution even occurs. The gateway sees the malicious parameter (e.g., a request to 169.254.169.254) and terminates the connection before the tool is ever invoked.
How GuardionAI Delivers Gateway-Level Security
This network-level, proxy-first approach is exactly how GuardionAI secures enterprise agentic traffic. As an AI Security Gateway, GuardionAI provides an inline control point for every agent and MCP call—requiring absolutely no SDKs or code changes to your underlying applications.
Whether you are running Python microservices, TypeScript Next.js apps, or standalone coding agents, GuardionAI acts as the "EDR for AI agents." It governs the runtime to detect prompt injection, enforce data loss prevention, and block malicious tool execution at the network layer. By centralizing security at the gateway, platform engineering teams can deploy agents at the scale of Uber without sacrificing the strict security and compliance standards required by the modern enterprise.
Frequently Asked Questions
What is the difference between an MCP Gateway and an MCP Server?
An MCP Server exposes specific tools or data (like a database query interface, a web scraper, or an internal API) to an AI agent. An MCP Gateway is the network proxy that sits between the AI agent and the MCP server, enforcing access control, observability, and security rules before allowing the connection to complete.
Can an AI Gateway replace my existing API Gateway?
No. Traditional API Gateways (like Kong, Apigee, or AWS API Gateway) are optimized for REST/GraphQL and human-to-machine traffic. AI and MCP Gateways are purpose-built for machine-to-machine agentic workflows, handling the Model Context Protocol, dynamic tool discovery, LLM token streaming, and semantic payload inspection.
How does an MCP Gateway handle Server-Sent Events (SSE)?
MCP relies heavily on SSE for streaming real-time updates and tool outputs back to the agent. A robust MCP Gateway maintains stateful proxy connections, ensuring that SSE streams are authenticated, monitored for malicious content (like data exfiltration or injection attacks), and cleanly terminated if a security policy is violated.
Why are SDKs considered a security risk for multi-agent systems?
SDKs fracture your security posture across different programming languages and require you to own the application code. They are completely ineffective at securing "Bring Your Own Agent" scenarios (like developers using Cursor or Claude Code on their local machines) where you cannot inject a security library into the runtime, leaving massive blind spots in your network.
How do gateways prevent Server-Side Request Forgery (SSRF) in AI agents?
Gateways inspect the parameters being passed to tools before execution. If an agent attempts to use a web-fetching tool to access internal IP addresses (like AWS metadata at 169.254.169.254), local hostnames, or loopback addresses, the gateway evaluates the request against strict network boundaries and blocks the SSRF attempt deterministically.
References & Research
- How Uber Runs 60,000 AI Agent Tasks Per Week With MCP (Agentic AI Foundation Keynote)
- Gateways are All You Need — Karan Sampath, Anthropic
- MCP Security Just Became a Must-Defend Problem
- Harden user-MCP http SSRF guard (DNS rebinding + redirects) for OSS default-on
- ToolBastion v0.1.4 — Live MCP Security Gateway Demo | Path Traversal, SSRF & Audit Evidence