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 8707 resource indicators (mandatory in MCP since March 15, 2026), and on-behalf-of token exchange so the downstream agent runs under the calling user's identity, not a shared service account.
- 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.
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.
| 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.