An agent gateway is the data plane of enterprise agent infrastructure: the inline component that every agent invocation passes through, where authentication is verified, RBAC is enforced, the call is routed, rate limits and circuit breakers fire, and an observability record is written for the audit trail. It is the only point in the stack where you can answer the runtime question — should this particular invocation actually happen right now? — with the version, policy, and identity context of the moment.
The gateway pairs with the agent registry on the catalog-plane side, and frequently with an MCP gateway when the agents being governed are MCP servers. The three are not interchangeable. The registry tells you what exists. The gateway enforces what runs. The MCP gateway is the protocol-specific flavor of the agent gateway when MCP is the wire.
What an agent gateway has to enforce
A serviceable agent gateway enforces five things at every invocation. Anything less is a reverse proxy with extra logging. The concrete shape of the work is easier to see through a single call. An orchestrator presents an on-behalf-of token for analyst-agent v1.4, but the registry advertised v1.6 two hours ago with a tighter scope on the run_query tool. The gateway has to refuse the stale version reference, surface the registry's current capability schema in the error, and write an audit record that names both versions — the one the caller asked for and the one that was current at the moment of the call. If the token's scopes fall short of what run_query now requires, the same call also has to fail the OBO scope check before it ever reaches the downstream agent. That is two independent enforcement decisions on a single invocation, and the audit row has to record both.
- 01
Authentication
OAuth 2.1 with PKCE (RFC 7636), plus RFC 8707 resource indicators — the MCP authorization specification requires clients to send the
resourceparameter in both the authorization request and the token request, and requires servers to validate that a token was issued for them as the intended audience. A token minted for one MCP server therefore cannot be replayed against another. On-behalf-of token exchange (RFC 8693) is what keeps the downstream agent running under the calling user's identity rather than a shared service account; RFC 8693 distinguishes impersonation from delegation, and for audit purposes you want delegation. - 02
Authorization
RBAC referencing IdP groups, evaluated against the access policy the registry currently advertises for the called agent. Not the policy from the last sync — the current one.
- 03
Routing
Pick the right backend version of the agent (active vs deprecated vs canary), with the routing decision logged so audit can answer "which version of agent X served this call."
- 04
Rate limiting and circuit breakers
Per-user, per-agent, per-tool quotas, with circuit breakers that trip when downstream MCP servers degrade. Without this, an autonomous agent in a loop will quietly bankrupt the budget.
- 05
Observability
A structured record per tool call: identity, agent version, MCP tool name, inputs, expanded results, success/failure, and the policy version that authorized the call. Not raw HTTP logs. The open schema to emit against is the OpenTelemetry GenAI semantic conventions, which now carry spans, metrics, and events for GenAI clients and for MCP specifically — emit once, ingest in whichever backend you already pay for.
| Requirement | Level | Bound party | What the gateway has to do |
|---|---|---|---|
| Protected Resource Metadata (RFC 9728) | MUST | MCP server, and client for discovery | Serve /.well-known/oauth-protected-resource for every server it fronts. Clients MUST use it to find the authorization server, so a gateway that skips it forces manual per-client configuration. |
| Resource indicators (RFC 8707) | MUST | MCP client | Send resource in both the authorization request and the token request, carrying the canonical URI of the server being called — and send it "regardless of whether authorization servers support it." |
| Token audience validation (RFC 8707 §2) | MUST | MCP server | Reject any token not issued for this resource. "Invalid or expired tokens MUST receive a HTTP 401 response." This is evaluated per call, so there is no propagation window to reason about. |
| Token pass-through to upstream APIs | MUST NOT | MCP server | The server "MUST NOT pass through the token it received from the MCP client" when calling an upstream API. Egress needs a separate token from the upstream authorization server — which is why egress credential handling is a gateway feature, not an afterthought. |
PKCE with the S256 challenge method | MUST | MCP client | Implement PKCE and "MUST verify PKCE support before proceeding." If code_challenge_methods_supported is absent from the authorization server metadata, clients "MUST refuse to proceed." |
| Authorization server metadata discovery (RFC 8414 or OpenID Connect Discovery 1.0) | MUST (at least one) | Authorization server; clients MUST support both | A gateway fronting more than one identity domain cannot assume a single discovery shape — clients are required to handle either. |
iss in the authorization response (RFC 9207) | SHOULD emit / MUST validate | Authorization server emits, client validates | Mix-up defence. The client must compare iss against the recorded issuer before sending the code to any token endpoint. The spec states a future revision "is expected to upgrade" the emit side from SHOULD to MUST. |
| Insufficient-scope challenge | SHOULD | MCP server | Answer HTTP 403 with WWW-Authenticate: Bearer error="insufficient_scope" and "all scopes required for the current operation in a single challenge" — not one scope per retry. |
| OAuth Client ID Metadata Documents | SHOULD | Clients and authorization servers | The default registration path "when client and server have no prior relationship." Client IDs are self-hosted HTTPS URLs, so they stay portable when the authorization server changes. |
| Dynamic Client Registration (RFC 7591) | MAY — deprecated | Clients and authorization servers | "Dynamic Client Registration is deprecated. New implementations should use Client ID Metadata Documents instead." Retained only for backwards compatibility with servers that lack CIMD support. Do not architect a new gateway around it. |
Two rows carry most of the failed security reviews we see. The MUST NOT on token pass-through is the one teams discover late, because the naive proxy design — forward the caller's token upstream — is explicitly forbidden and requires an egress credential store to fix. And the DCR row moves the other way from what most 2025-era gateway designs assumed: registration by POST /register is now the fallback path, not the default. Both are read from the MCP authorization specification, its security considerations, and the client registration page for revision 2026-07-28.
Gateway vs registry: where the line sits
The cleanest framing we have found for procurement conversations: the registry is the catalog plane (out of the call path, source of record), and the gateway is the data plane (in the call path, enforcement point). Both are required for governed agent infrastructure. Neither is a substitute for the other.
The two must share state — schema, policy objects, version reference — or the gateway becomes either over-permissive (enforcing a stale schema that is now broader than the current one) or under-permissive (refusing a call that the registry approved last week). We work through the three concrete failure modes, and the two diagnostic questions that catch them, in Agent Registry vs. Agent Gateway: Two Roles, One Control Plane.
How an agent gateway differs from a standard API gateway
An API gateway terminates TLS, authenticates the call, and forwards. An agent gateway has to do four extra things that no Kong / Apigee / AWS API Gateway configuration will handle natively.
The protocol itself now assumes an intermediary. MCP's Streamable HTTP transport mirrors selected JSON-RPC body fields into HTTP headers — Mcp-Method on every request and Mcp-Name on tools/call, resources/read, and prompts/get — expressly so that load balancers, gateways, and observability tooling can route and inspect a call without parsing the body. The specification also requires servers that read the body to reject any request whose headers disagree with it, precisely because a gateway routing on the header and a server executing on the body is a security bug waiting to happen.
| Capability | Agent gateway | Standard API gateway | MCP gateway |
|---|---|---|---|
| Wire protocol | MCP / A2A over JSON-RPC 2.0 | REST or GraphQL | MCP over JSON-RPC 2.0 |
| Identity across nested tool calls | On-behalf-of token propagated to every hop | Drops on the second hop | On-behalf-of native; MCP-specific |
| Observability granularity | Resolved tool name, args, result per call | Raw HTTP frame | Per MCP tool call, including resolved arguments |
| Schema enforcement | Versioned, sourced from registry on every call | Static endpoint config; ages out of sync | Versioned per MCP server capability advertisement |
Five questions for an agent gateway vendor
If you are running a gateway evaluation, these five questions are the floor. Vendors that hedge on any of them are not yet enterprise-ready, regardless of what the deck says.
- 01
Revocation timing
If you revoke a user's access in the registry now, how long until the gateway stops authorizing their invocations? Real-time or first-call. Anything else is a security gap.
- 02
Deprecation timing
If you deprecate an agent version in the registry now, how long until the gateway stops routing to it? Same answer. Sync-interval propagation is the wrong shape.
- 03
Audit granularity
Does the per-call record name the specific MCP tool invoked (apply_compile, run_diff, etc.) or just the agent? Tool-level granularity is what compliance asks for.
- 04
Policy snapshot
Does the audit record include the policy configuration in effect at the moment of the call, not just a policy ID? IDs mutate; snapshots do not.
- 05
Multi-provider reach
Can it gateway across AWS AgentCore, Azure AI Foundry, Cloudflare MCP Server Portals, and self-hosted MCP servers — or does each provider need its own gateway, with reconciliation by hand?
Jarvis Registry as a unified gateway
Jarvis Registry is the gateway and the registry at the same time. The catalog plane and the data plane share the schema, the policy objects, and the version reference. Deprecation in the catalog takes effect in the gateway on the next call, not the next sync. Each per-call audit record names the registry version and policy snapshot in effect at the moment of the call. RBAC consumes IdP groups directly through SAML / OIDC; there is no parallel role system to drift from.
The product registers as the unified MCP endpoint that Jarvis Chat, Claude Desktop, Claude Code, VS Code, Cursor, GitHub Copilot, Microsoft Copilot, Windsurf, and ChatGPT all connect to. From the client's perspective there is one MCP server. Behind it, Jarvis Registry is gatewaying invocations across AgentCore, Azure AI Foundry, and self-hosted servers — with one audit trail, one policy surface, one version of the truth.