Put only ingress coordination and deployment checks in the gateway, then move authentication, authorization, token exchange, webhook execution, and audit logging into the shim when those functions need protocol context. The dividing line is simple: if the control depends on the server’s behaviour, it should live beside the server, not in the proxy. That keeps the gateway thin and the trust boundary clearer.
Where the gateway should stop and the shim should begin
The cleanest way to split responsibilities is to keep the gateway focused on transport entry, request routing, and basic deployment hygiene, while the shim owns anything that needs to understand the MCP server’s local behaviour. That includes authentication and authorization decisions that depend on server context, token exchange, webhook handling, and audit events that must reflect what the server actually did.
This matters because a gateway can only safely enforce rules it can observe without guessing. Once a decision depends on tool semantics, server-specific policy, or the lifecycle of a particular credential, the control belongs next to the server logic rather than in a proxy that sees only the wire.
Why protocol context changes the control boundary
An mcp gateway is useful when the control is generic and repeatable across backends, such as ingress filtering, coarse allowlisting, deployment checks, rate shaping, or health validation. A shim becomes necessary when the decision must be made in the context of a specific MCP server, its tools, or its trust relationships. That is where identity-bearing material, delegation state, and server-issued responses can be evaluated accurately.
For teams building agentic integrations, this boundary is not just architectural elegance. It is the difference between a policy that can be enforced correctly and a policy that only appears centralized. The Model Context Protocol: Authorization specification is a useful reference for the protocol-side rules, especially where servers act as OAuth resource servers and token handling cannot be treated as a blind passthrough.
Gateway-only enforcement is usually acceptable when the rule is protocol-level and independent of tool execution. Shim-side enforcement is the right move when the server must decide whether a token, user, agent, or delegated action is valid for a specific operation at runtime.
How to place controls without creating a false trust boundary
Teams should ask one simple question for each control: can this decision be made correctly without knowing how the server behaves? If yes, keep it in the gateway. If no, move it into the shim and let the shim speak for the server. That rule reduces confused-deputy risk, avoids leaky token handling, and keeps audit records closer to the action that actually mattered.
The same principle applies to request provenance and downstream execution. If the gateway tries to handle authorization, token exchange, or audit logging for actions it cannot truly interpret, it becomes a policy surface that may be bypassed, duplicated, or mismatched from server reality. A shim can still be thin, but it must be authoritative for the server-specific parts of the interaction.
For protocol-heavy deployments, the MCP Security Guide is a practical companion because it ties gateway design to authorization, token passthrough, confused deputy concerns, and deployment choices. For broader agent-level context, OWASP Agentic Applications Top 10 helps teams see how tool misuse and privilege abuse emerge once an agent can act through MCP-connected tools.
What good looks like in practice
A sound design usually has a thin gateway and a server-aware shim. The gateway handles entry-point controls that can be applied uniformly, while the shim performs context-sensitive checks, exchanges or binds tokens where required, logs the real security-relevant action, and returns decisions based on the server’s own policy surface. That separation also makes troubleshooting easier because the logs and enforcement point line up with the actual control owner.
Teams should also avoid mixing policy roles in a way that hides accountability. If the gateway is partly enforcing application logic and the shim is partly enforcing transport logic, nobody has a clean answer when a request succeeds or fails. Keeping the gateway narrow makes deployment changes safer, while keeping the shim authoritative makes authorization and logging defensible.
When teams need a more mature identity pattern for these server-adjacent checks, the NHI Authentication Guide is helpful because it covers machine and workload authentication patterns such as client credentials, mTLS, token exchange, and sender-constrained tokens. For an implementation lens on agent identities and least privilege, AI Agent Identity Security: The 2026 Deployment Guide gives the right deployment instincts for short-lived credentials and task-scoped access.
Risk and Threat Considerations
The main risk of putting too much in the gateway is a control that looks central but cannot actually see the conditions it needs to enforce. That creates bypass opportunities, incorrect authorization outcomes, and audit records that do not match the server action that occurred. In MCP environments, that mismatch can become a confused deputy problem, especially when tokens are forwarded without the server understanding the true audience or context.
Failure mechanism: The proxy makes a decision without the server-specific state, so authorization, token handling, or logging drifts away from the actual execution path. Attackers or misconfigured clients can then exploit the gap between what the gateway thinks happened and what the server really did.
Impact: Teams can end up with overbroad access, weak traceability, broken accountability, and a larger blast radius if a token or tool path is abused. In the worst case, the gateway becomes a false security boundary that hides real privilege.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP boundary decisions affect delegated authority and tool access. |
| ASI02 — Tool Misuse | Gateway and shim placement shapes how tool calls are constrained and observed. | |
| Recommendation — Place authorization where agent privilege is actually evaluated. Constrain tool execution where the server can validate intent and context. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The split should minimize standing authority in the gateway path. |
| AU-2 — Event Logging | Audit logging is explicitly part of the gateway versus shim boundary decision. | |
| IA-5 — Authenticator Management | Token exchange and credential handling depend on how authenticators are managed. | |
| Recommendation — Assign only the minimum gateway privileges needed for ingress handling. Log security-relevant actions at the component that actually performs them. Manage token handling beside the server that validates the credential context. | ||
Practitioner Guidance
Decision rule: If a control can be enforced from request metadata alone, keep it in the gateway; if it depends on tool semantics, server policy, token exchange, or execution outcome, place it in the shim.
What to verify: Confirm that every security-relevant action has one clear enforcement point and one clear audit source. If the same decision is duplicated in both layers, decide which layer is authoritative and remove the other copy.
Practitioner takeaway: The safest MCP pattern is not the most centralized one, it is the one where each control sits next to the information it actually needs to be correct.
Related resources from NHI Mgmt Group
- How should security teams decide whether JIT access is safe for non-human identities?
- How should security teams decide whether they need an AI gateway, an MCP gateway, or both?
- How should teams decide between a single MCP gateway and multiple servers?
- How do organisations decide whether an MCP gateway belongs in their identity architecture?