Sep 2, 2026/11 min readCore Platform
The Enterprise Guide to MCP Gateways: Governing the Next Generation of AI Agents
AI agents are no longer just answering questions — they are taking actions. Across engineering, sales and operations teams, agents are reading databases, triggering cloud workflows, modifying CRM records, and executing multistep tasks and self-improving loops.
One of the underlying drivers of this shift is the Model Context Protocol (MCP). Developed as an open standard and now stewarded by the Linux Foundation, MCP has become the "USB-C port for AI" — a unified abstraction layer that connects AI clients to enterprise context, tools and data. Any MCP-compatible agent can connect to any MCP-compatible server.
That standardization is exactly what makes it powerful. It is also exactly what makes it dangerous if left ungoverned.
The scale is no longer hypothetical
Three enterprise earnings calls in August 2026 made the adoption curve concrete. Datadog reported MCP tool calls up 22x since Q4 2025, quadrupling again quarter over quarter.1 Figma reported MCP write usage up 75% in a single quarter.2 Atlassian reported MCP calls up 400% in one quarter and noted that growth came "with barely a blip in people actually using the applications through the web or through a mobile client."3 Salesforce reported sixfold growth in the agentic use of their apps through MCP and CLI calls.4
Agents have become a parallel, high-volume access channel to enterprise systems — running alongside human users, invisible to most security stacks and in most organizations entirely ungoverned.
Anthropic's December 2025 ecosystem update cited more than 10,000 active public MCP servers. Industry analysts predict that a significant share of enterprises will operate their own MCP servers by the end of 2026. The question is no longer whether your organization has MCP traffic. It is whether that traffic has a control layer.
The shadow agent problem
When a developer spins up a local MCP server to connect an AI coding assistant to a staging database or production API, the connection works immediately. The productivity gain is real and visible. The security gap is invisible.
Security teams have no inventory of which MCP servers are running across the organization, which credentials those servers hold, which systems they can reach, or what data flows through them. Hardcoded tokens sit in local configuration files. Agents act with whatever access was granted at setup — rarely reviewed, never scoped to least privilege.
This is shadow IT all over again, except this time the unauthorized software can read production databases, modify records in enterprise SaaS and execute commands in cloud consoles. And it operates nondeterministically: The agent decides at runtime what to do with the access it has.
Security research has documented what follows: malicious MCP servers that manipulate agent behavior through forged tool descriptions (tool poisoning), agents leaking data across session boundaries (context leakage), and servers overriding trusted tools in an agent's toolchain (tool shadowing). These are not theoretical attack vectors. They are the direct consequence of MCP running without governance.
Why traditional API gateways fail with AI agents
The first instinct from most enterprise security teams is to route MCP traffic through existing API gateway infrastructure. That approach falls short quickly.
Traditional API gateways were built for a deterministic world. System A calls System B along predictable, static routes with fixed credentials. The gateway checks authorization, applies rate limits and forwards the request.
AI agents operate differently:
- They choose which tools to invoke dynamically, based on user prompts
- They chain multiple tool calls across different systems in real time, each call dependent on the output of the last
- They operate asynchronously on behalf of users, adjusting execution paths based on intermediate results
- They can take significant actions — exports, writes, deletions — as a downstream consequence of a prompt that appeared innocuous
An API gateway asks: Is this client authorized to hit this endpoint? An MCP gateway answers a different question: Is this specific agent authorized to execute this specific tool call, with these specific parameters, on behalf of this user, right now?
| Traditional API Gateway | Enterprise MCP Gateway | |
|---|---|---|
| Traffic model | Deterministic (app-to-app) | Nondeterministic (agent-to-system) |
| Auth model | Static API keys, fixed IP ranges | Dynamic, short-lived tokens; user-delegated OAuth |
| Control unit | URL endpoints and rate limits | Tool parameters, prompt context, user session identity |
| Security surface | SQL injection, DDoS, broken auth | Tool poisoning, context leakage, indirect prompt injection |
| Audit log | HTTP request/response metadata | Full agent trajectory: intent, tool choices, blocked attempts |
The five pillars of an enterprise MCP gateway
A complete MCP gateway architecture operates as a centralized control plane between AI clients and enterprise systems. Five technical pillars define a complete implementation.
1. Zero-secret exposure and dynamic identity
Hardcoding static service tokens into local agent configurations is an unacceptable vulnerability at enterprise scale. Neither the user's local environment nor the LLM's context window should ever have access to raw production credentials.
Modern gateway architectures intercept tool executions at runtime and inject authorized credentials on the fly — the agent operates with the authority it has been granted without ever possessing the underlying secret. This approach eliminates an entire class of credential leak risk: The agent cannot exfiltrate what it never had.
Equally important is how agents act on behalf of users. When an agent requests a tool execution — updating a record, querying a database, posting to an internal system — the gateway should ensure the agent acts strictly within the permission scope of the user it represents. Not the permission scope of whoever set up the integration. Not a shared service account. The specific user, through user-delegated OAuth flows, at the time of the request.
The June 2026 Enterprise-Managed Authorization (EMA) extension to the MCP spec formalizes this further: Enterprise identity providers become the authoritative provisioner for MCP server access. Users authenticate once through their existing enterprise identity; the IdP automatically provisions the MCP servers they are authorized to use. No more OAuth consent screens for each server, mix-ups between personal and work accounts, and manual setup. Access decisions live in the IdP admin console with a single auditable trail.
2. The governed tool catalog
To eliminate shadow MCP instances running on developer terminals, organizations need a centralized, IT-curated registry of approved MCP servers.
This functions as an internal app store for agent capabilities. IT and security teams control what is available, who can access it and under what conditions. Employees discover approved connectors through a searchable catalog rather than installing whatever they find in a public repository. Access requests go through approval workflows. role-based access control (RBAC) ensures that engineering teams see GitHub and code execution tools while finance teams see ERP integrations.
Without this layer, every developer with a laptop and an AI coding assistant is a potential shadow MCP instance. With it, approved capabilities are the path of least resistance — and unapproved ones generate audit events when they appear.
3. Runtime security, data loss prevention (DLP) and context narrowing
Preventing data exfiltration requires real-time inspection before a tool call reaches a backend system.
Data loss prevention at the MCP layer means inspecting both prompts and tool outputs — stripping PII, proprietary code snippets and confidential tokens before data crosses network boundaries. Unlike network-level DLP, which operates on packets, MCP-layer DLP understands the semantic content of what an agent is doing and why.
Context narrowing addresses a subtler but equally important problem. An agent with access to an entire database schema or a complete API specification has a larger attack surface and performs worse — excess context causes hallucinations and increases the probability of unintended tool selections. Gateways that dynamically trim tool definitions presented to the LLM based on user intent and session context reduce both risk and error rates.
Pre- and post-call hooks allow organizations to inject validation middleware into the request path — checking parameters before execution, sanitizing responses before they reach the agent's context and enforcing business rules that policy definitions alone cannot capture.
4. Telemetry, audit traces and cost controls
AI agents can execute dozens of tool calls in a single reasoning loop. Standard HTTP logging infrastructure is not designed to make that coherent.
Enterprise MCP telemetry needs to capture the full agent trajectory: not just which API calls were made and whether they succeeded, but what the agent was trying to accomplish, which tool calls were denied and why, and how the agent adapted after a denial. This is the audit trail that makes compliance achievable — and incident investigation possible.
Cost controls are equally important. An agent running a malformed loop, or a user who inadvertently triggered a long autonomous workflow, can generate significant spend in minutes. Granular financial controls — per-user, per-team, per-agent token and dollar budgets with automated circuit breakers — prevent runaway costs.
5. Integration with the data and workflow layer
MCP governance does not operate in isolation from the platforms where enterprise data and business logic already live.
Major data platforms now offer managed MCP servers tied directly to their existing permission models. An agent querying enterprise data through a platform-native managed endpoint automatically inherits the same access controls that govern human users — the same row-level security, column masking and data classification the organization already manages in its data governance layer.
Enterprise workflow orchestration platforms similarly expose existing integration logic and API workflows as secure MCP endpoints. Rather than giving agents raw API credentials and letting them figure out how to interact with enterprise systems, this approach surfaces prebuilt, tested, governed workflows as callable tools — agents invoke the organization's existing integration assets, with access scoped to the requesting user's permissions.
The build-vs-buy reality
Enterprise architects regularly consider building a lightweight proxy to manage MCP connections internally. Simple HTTP forwarding is straightforward. What it grows into is not.
Three forces make in-house MCP governance unsustainable:
Ecosystem velocity. The MCP specification has had material releases in March, June and July 2026 alone — stateless sessions, Enterprise-Managed Authorization, Dynamic Client Registration replaced by Client ID Metadata Documents, server-to-client change notifications. Each release requires implementation decisions. Organizations that tried to build internal governance in early 2026 are now evaluating external platforms because the spec moved faster than their engineering teams.
Multi-client complexity. Modern enterprises rarely run a single AI client. Engineering teams use coding assistants, business users use chat applications, operations teams run autonomous agents, and custom internal tools sit alongside all of them. Governance needs to cover all of it consistently — not just the client the internal team got to first.
Deep operational requirements. Runtime DLP, secret rotation, dynamic OAuth proxying, granular token metering, spec-version compatibility management — each is a meaningful engineering problem in its own right. Together they constitute a full-time product. Organizations that have tried to build this internally describe the same experience: The scope expands faster than the team.
MCP governance follows the same build-vs-buy logic as identity management, endpoint protection and email security. It is core infrastructure best solved by dedicated platforms.
Implementation checklist
Step 1 — Audit the perimeter: Identify all MCP servers running in your environment, including developer laptops and shared machines. Catalog what systems they connect to, what credentials they hold and who set them up. This inventory is almost always larger and messier than expected, and it is the prerequisite for everything that follows.
Step 2 — Deploy a centralized control plane: Establish an MCP gateway that routes all agent-to-system connections through a single observable layer. Connect it to your EDR (endpoint detection and response) and MDM to catch new unmanaged instances as they appear. Stand up the approved tool catalog so developers have a governed path that is also the easy path.
Step 3 — Enforce identity-bound policies: Connect your gateway to your enterprise identity provider. Configure agents to operate under user-delegated OAuth scopes — not shared service accounts. Enable EMA for zero-touch provisioning. Set runtime DLP rules, context narrowing policies and cost guardrails. Define what each class of agent is allowed to do, enforce it at the tool-call layer and log everything.
Final thoughts
The promise of AI agents lies in their ability to take real action on real enterprise data. The Atlassian earnings call put the scale in concrete terms: 400% MCP growth in a quarter, driven almost entirely by agents, while human UI traffic barely moved.
That growth is not slowing. Enterprise security and IT teams have a choice: whether to govern MCP usage and allow it to safely accelerate, or get left behind as unmanaged sprawl takes over.
An MCP gateway is how organizations confidently make that pivot. It works not by limiting what agents can do, but by ensuring the enterprise can see it, control it and stand behind it.
That is why we built Cortex AI Gateway — to give every enterprise a production-ready MCP control plane that governs agent access, eliminates credential exposure, and delivers the audit trail needed to let agents run at scale with confidence.
