MCP Gateway Architecture: Components and Trust Boundaries
A practical MCP gateway architecture covering discovery, OAuth, policy, tool mediation, credential isolation, audit evidence and protected upstream execution.
An MCP gateway is an enforced intermediary between MCP clients and one or more MCP servers. It centralizes server discovery, authentication, token handling, policy, tool filtering, rate limits and evidence. It does not become a security boundary merely because traffic can pass through it. Direct routes, forwarded credentials and permissive tool policies can still bypass the intended control.
The full category definition is in the MCP gateway guide. This article gives platform teams a reference deployment and the trust questions behind each component.
Reference data flow
[MCP client]
| request + caller credential
v
[edge authentication]
| verified caller context
v
[gateway router] <---- [approved server registry]
| <---- [policy bundle / grants]
v
[tool schema validation + action authorization]
| exact allowed request
v
[credential broker] ---> [protected MCP server] ---> [domain API]
| |
+------ decision/event ------+
v
[evidence pipeline]
The registry says which servers and tools are approved. It should not decide whether a principal may run a particular tool call. The credential broker keeps upstream secrets outside model context and exchanges or obtains a narrowly scoped credential for the intended server. The enforcement point validates the exact tool arguments before execution.
Respect the protocol boundary
The current MCP authorization specification defines authorization for HTTP transports. Protected servers publish OAuth protected-resource metadata, clients include the intended resource in authorization and token requests, and servers validate token audience. Authorization is optional across MCP implementations, so a gateway must inventory transport and authentication behavior rather than assume uniform support.
{
"resource": "https://mcp.example.com/finance",
"authorization_servers": ["https://id.example.com"],
"scopes_supported": ["invoices:read", "payments:submit"]
}
RFC 9728 defines protected-resource metadata. RFC 8707 defines the resource indicator. The gateway should preserve these semantics when it fronts several servers; one broad gateway audience must not silently make every upstream token interchangeable.
Separate gateway decisions
| Decision | Input | Failure result |
|---|---|---|
| server admission | owner, provenance, endpoint, review status | server not discoverable |
| client access | issuer, token, audience, scope | 401 or 403 |
| tool availability | tenant, role, server and tool policy | tool removed from list |
| action authority | grant, exact arguments, state, approval | deny or approval required |
| execution | upstream identity, idempotency, timeout | rejected, accepted or uncertain |
Tool-list filtering improves usability and reduces accidental calls. It must not replace server-side authorization because a client can construct tools/call directly.
Test the enforced path
Run these acceptance tests before rollout:
- Send a token issued for server A to server B. Both gateway and server B reject it.
- Add
x-user-idandx-tenant-idat the client. The gateway strips and regenerates them. - Call a blocked tool without listing tools first. The gateway still denies it.
- Change one approved argument after policy evaluation. Digest comparison stops dispatch.
- Reach the MCP server through an internal address. Service identity or network policy rejects it.
- Make the evidence sink unavailable. The documented risk-class behavior occurs.
The MCP security test guide supplies malicious fixtures. The registry comparison separates discovery from enforcement. Evaluate the live Intelliger platform overview for request-bound authorization and evidence patterns.
OATI and the gateway reference paths are in developer preview. They demonstrate schemas and enforcement concepts but do not claim completed customer production operations or independent security assessment.
Architecture questions to resolve
Is the gateway the MCP host?
Not necessarily. The host is the application that coordinates clients, permissions and user interaction. A gateway can sit between host-managed clients and servers as a shared enforcement point. Keep these roles explicit because the host may hold user context while the gateway owns enterprise policy and upstream credentials. Test that a compromised host cannot bypass gateway policy by opening a direct server route.
Should the gateway terminate MCP sessions?
Termination gives the gateway protocol visibility and control over tool lists, calls and errors. A transparent proxy may preserve server behavior but cannot enforce argument-aware policy without parsing messages. Choose deliberately and document session ownership, cancellation, resumption and backpressure. For streaming transports, test disconnects and partial messages so a retry does not repeat a completed side effect.
Where should tool schemas be validated?
Validate at gateway and protected server. The gateway uses its approved schema to reject unwanted calls before credential use. The server validates again because another route or version mismatch may exist. Compare schema digests and quarantine material drift. Do not trust a model client to have run validation simply because it generated arguments from the advertised description.
How should several authorization servers be handled?
Apply a tenant and server trust policy rather than selecting any issuer named in metadata. Define approved issuer-server relationships, client registration, scope mapping and failure behavior. Cache discovery under bounded rules and preserve the metadata version used. A server that suddenly advertises a different issuer should trigger review, not an automatic trust expansion.
Does the gateway own business policy?
It can enforce the decision without owning all domain semantics. For a refund, a domain policy service may resolve order state and merchant limits, then return a request-bound decision. The gateway compares the digest and obligations before dispatch. This division keeps routing and credential isolation centralized while leaving supplier, payment or production rules with accountable domain teams.
What should scale testing include?
Measure authorization latency, session count, message size, streaming behavior, registry refresh, policy distribution and evidence backpressure. Include a burst of denied requests and a replay-store slowdown, not only successful reads. Verify tenant isolation under cache pressure and confirm horizontal replicas share atomic replay and idempotency state where the action requires it.
Document the path for each transport. HTTP servers can use the authorization and metadata flow described in the specification. A local STDIO server runs inside a different trust boundary and may obtain credentials from the environment. Sending both through one diagram without naming the difference hides an important control gap. If the enterprise gateway cannot mediate a local transport, restrict what that process can reach and record the exception in the server inventory.