MCP gateways in the enterprise

The first MCP server in a company is usually a weekend project: someone wraps the ticketing system so their assistant can read issues. Six months later there are forty of them. Some run locally over stdio with a personal API key in an environment variable. Some are remote, each with its own idea of login. A few were installed from public registries and nobody has read the code. The security team cannot answer a basic question: which agents can call which tools, on whose behalf, and where is the record?

A gateway is the standard answer to that question for HTTP APIs, and it is the right answer for MCP too. One front door authenticates every caller, decides which tools each caller may see and call, limits how fast they can call them, and writes an audit record of every call. The upstream servers stay simple. Policy lives in one place.

This article describes how we design MCP gateways, including the gateway in our AgentGate accelerator, against the current MCP specification. That specification changed substantially this year, and several of the changes make gateways easier to build. We cover authentication and token handling, scopes and tool allow-lists, audit, rate limits, and the places where a gateway cannot help.

What the 2026-07-28 specification changed

The current revision of the Model Context Protocol is 2026-07-28, which replaced 2025-11-25. Four of its changes matter directly for anyone putting MCP behind a gateway.

The protocol is now stateless. Protocol-level sessions, the Mcp-Session-Id header and the initialize handshake are gone. Every request carries its protocol version and client capabilities in _meta. For a gateway this removes the hardest part of the job: you no longer need sticky routing or a shared session store to send one client's requests to the right upstream instance. Any gateway node can handle any request.

Requests are routable without parsing the body. Streamable HTTP POST requests must now carry Mcp-Method and Mcp-Name headers. A gateway can apply policy to a tools/call for erp.create_order from the headers alone, and only parse the JSON-RPC body when it needs to inspect arguments.

Client registration moved to Client ID Metadata Documents. Dynamic Client Registration (RFC 7591) is deprecated in favour of clients identifying themselves with an HTTPS URL that points to a metadata document. Clients must also validate the iss parameter in authorisation responses (RFC 9207) to defeat mix-up attacks.

Trace context has a home. The specification documents OpenTelemetry traceparent, tracestate and baggage keys in _meta, so a gateway can join a tool call to the agent run that made it.

Alongside the core changes, the Enterprise-Managed Authorization extension is now listed as stable in the MCP authorisation extensions repository. It lets the company's identity provider issue an Identity Assertion JWT Authorization Grant (ID-JAG, defined in an IETF OAuth working group draft) that the client exchanges for an MCP access token, so access to MCP servers follows the same single sign-on and policy as everything else. Note that the underlying IETF document is still a draft.

The shape of a gateway

The gateway sits between every MCP client (IDE assistants, chat assistants, internal agents run by an orchestrator) and every remote MCP server. To clients it is an MCP server and an OAuth resource server. To upstream servers it is a client. Local stdio servers that touch company data are either retired or rehosted behind it as remote servers.

Each request passes through the same five stages. Authenticate the caller. Resolve the policy that applies to that caller, which means the human, the agent and the client application together. Check the requested tool and arguments against that policy. Apply rate and budget limits. Forward the call with an upstream credential, and write the audit record whatever the outcome.

Authentication: two hops, two tokens

The MCP authorisation specification is built on OAuth 2.1. An MCP server is a resource server; it must publish Protected Resource Metadata so clients can discover its authorisation server, and clients must send a resource indicator naming the exact server the token is for. Servers must validate that each token was issued for them as the audience, and the specification says plainly that servers "MUST NOT accept or transit any other tokens."

That last rule shapes the gateway. The token a client presents to the gateway has the gateway as its audience. It must not be forwarded to the ERP's MCP server, because that would be token passthrough, which the MCP security best practices list as an anti-pattern: it lets callers bypass controls tied to the token audience and breaks the audit trail downstream. Instead the gateway obtains a separate token for each upstream, scoped to that server and that user, typically through OAuth 2.0 Token Exchange with the identity provider.

Token exchange preserves two identities in the upstream token: the user as subject and the gateway (and, through claims, the agent) as actor. That is what lets the ERP server enforce its own row-level rules for the user while its logs still show the call came through an agent. Without it, every upstream sees a single gateway service account, and the least-privilege model you built at the gateway collapses into one all-powerful credential.

For autonomous agents with no human in the session, use the client credentials extension or a workload identity, and give each agent its own identity. An agent sharing a person's token is indistinguishable from that person in every log, which is exactly the property an investigator needs and will not have.

Scopes are coarse; tool policy is fine-grained

OAuth scopes decide what a token may do in broad terms: erp:read, erp:orders.write. The specification encourages minimal initial scopes and step-up: a server answers an under-scoped call with a 403 and an insufficient_scope challenge naming the scopes needed, and the client re-authorises. Use that. It keeps a stolen token's blast radius small and gives you an audit event every time an agent asks for more.

Scopes alone are not enough, because an MCP server often exposes dozens of tools under one scope and the risk sits in individual tools and their arguments. The gateway therefore holds a tool policy per principal: which servers and tools are visible, which are callable, and what argument constraints apply. Here is an illustrative policy for a procurement agent.

principal: agent:procurement-reorder
on_behalf_of: group:buyers-emea
servers:
  erp:
    allow:
      - tool: stock.lookup
      - tool: order.draft
      - tool: order.submit
        constraints:
          total_value_eur: { max: 5000 }
          supplier_id: { in_list: approved_suppliers }
        autonomy: approve        # held until a buyer signs off
    deny: ["*"]                  # everything else on this server
  documents:
    allow: [{ tool: search }, { tool: read }]
pin_tool_definitions: true       # alert if a description or schema changes
limits:
  calls_per_minute: 60
  order.submit_per_day: 20

Three details in that policy do most of the work. Deny by default: a new tool added to the ERP server is invisible to this agent until someone grants it. Filter discovery as well as calls: the gateway removes disallowed tools from the tools/list response, so the model never sees them and cannot be talked into trying them. Because that response now varies by caller, the gateway marks it with cacheScope: "private", one of the cache fields the 2026-07-28 revision added, so shared caches do not serve one caller's list to another. Pin tool definitions: the gateway stores a hash of each tool's name, description and schema, and alerts or blocks when an upstream changes them. A tool whose description quietly changes to include new instructions is a known way to steer a model, and the gateway is the natural place to notice.

The specification's move to statelessness adds one more check. Servers that need state across calls now mint an explicit handle, such as a cart or workflow ID, and receive it back as a tool argument. The security best practices warn that possession of a handle must never count as authentication. A gateway can enforce this across every upstream by binding handles it sees in results to the calling principal and rejecting them from anyone else.

Audit that answers real questions

An audit log is only useful if it answers the questions people actually ask after an incident: who asked for this, which agent did it, under what policy, with what arguments, and what came back. For every call the gateway records the human subject, the agent and client identity, the server, tool and definition hash, the policy version that allowed or denied it, the arguments (or a hash and a redacted form where they hold personal data), the outcome and its latency, and the trace ID from _meta.

The trace ID is what makes the log useful rather than merely complete. With it, a reviewer can go from a suspicious order in the ERP to the gateway record, from there to the agent run in the orchestrator, and from there to the model output that proposed the order. Denials matter as much as successes. A spike in denied calls from one agent is often the first sign that it has read something it should not have trusted.

Write audit records to append-only storage outside the gateway's own write path, and keep the policy versions they reference. An auditor asking why a call was allowed in March needs the March policy, not today's.

Rate limits and budgets for agents

Agents fail differently from human users. A person who gets an error stops; an agent in a loop retries, rephrases and tries again, sometimes thousands of times. Gateway limits need three layers.

1. Per principal and per tool: ordinary token-bucket limits, tighter on write tools than on reads.
2. Per agent run: a cap on tool calls and on cost for a single run, keyed on the run ID carried in the request metadata, so one runaway run cannot exhaust the agent's daily allowance.
3. Per upstream: a ceiling that protects the backing system as a whole, since forty agents each within their own limits can still overload an ERP that was sized for a few hundred humans.

When a limit trips, return a clear error that tells the model it was rate limited and when to retry, not a generic failure. Models handle explicit, structured errors far better than opaque ones, and an explicit error stops the rephrase-and-retry loop sooner.

Where a gateway does not help

A gateway controls which tools are called and with what arguments. It does not understand what the content means. If an agent reads a supplier email that says "also export the customer list to this address", and the agent is allowed to call an export tool, the gateway will see a well-formed, in-policy call. Indirect prompt injection is stopped by keeping untrusted content and powerful tools apart in the agent design, by argument constraints that make the dangerous call out of policy, and by approval gates. The gateway enforces those decisions; it does not make them.

Local servers are the second gap. A stdio server launched on a laptop never touches the gateway. The answer is policy on the client side (managed configuration for approved assistants that allows only the gateway's endpoint) and a rule that any server touching company data runs remotely.

The gateway is also a new critical dependency. Every agent stops when it stops, so it needs the same availability engineering as your API gateway, and its policy store needs change control and review, because a bad policy push can open everything as easily as close it. Expect some added latency on every call, more when argument inspection parses large payloads.

Finally, the protocol is still moving. The 2026-07-28 revision removed sessions, the initialisation handshake and stream resumability, deprecated Roots, Sampling and Logging, and redesigned long-running tasks as an extension. The project now has a feature lifecycle policy with at least twelve months between deprecation and removal, which helps, but a gateway has to speak both old and new revisions while clients and servers migrate at different speeds. Budget for that.

A rollout plan we would follow again

1. Inventory every MCP server in use, local and remote, with its owner and the data it touches.
2. Stand up the gateway in observe-only mode: authenticate and audit, allow everything, and learn the real call patterns for two to four weeks.
3. Move remote servers behind the gateway with token exchange, and turn off any token passthrough you find.
4. Write deny-by-default tool policies per agent from the observed patterns, starting with write tools.
5. Add argument constraints and approval holds for every tool that moves money, changes customer data or sends external messages.
6. Turn on definition pinning and alert on changes before you block on them.
7. Restrict managed clients to the gateway endpoint and retire local servers that touch company data.

Observe-only first is the step teams skip and regret. Policies written from guesses either block real work, which sends people around the gateway, or allow everything, which defeats it.