Should security teams use API gateways alone to control MCP access?

Why API gateways are not enough for MCP access control

API gateways are good at traffic control, request validation, and coarse policy enforcement, but MCP changes the decision point. The real question is not just whether a request is syntactically valid, but whether this specific agent, at this moment, should be allowed to invoke this tool with this authority and context. That requires runtime authorization closer to the MCP server and policy decisions that understand the agent’s delegated context.

A gateway can inspect headers, enforce schema, and throttle abuse, but it usually cannot tell whether the request represents legitimate delegated action or an unsafe blend of human intent and agent autonomy. In MCP environments, that distinction matters because tool access often carries real side effects, not just data retrieval.

The practical implication is that gateway-only control leaves a gap between transport security and decision security. If you rely on the gateway as the sole enforcement point, you may still pass requests that are well-formed yet wrong in authority, scope, or purpose.

What MCP changes about identity, context, and authorization

MCP is not just another API surface. It introduces a structured way for agents to reach tools, which means the security model has to account for who or what is acting, what authority it inherited, and whether the context attached to the action still matches the intended task. That is why identity-first enforcement matters: authorization must be tied to the agent instance, the user-derived attributes it carries, and the specific tool invocation.

This is especially important where the agent can operate across multiple tools or environments. A request that looks harmless at the gateway can still be dangerous if the agent has broader delegated authority than the task requires, or if the context was modified, stripped, or reused in a way that changes the meaning of the action.

In practice, MCP access control works best when policy is evaluated at the point of use, not only at the front door. MCP Security Guide is a useful companion for understanding why gateways, token handling, and tool-level checks need to work together rather than as substitutes.

For broader identity and authorization design, Authorisation Models Guide helps frame why static roles alone are often too blunt for tool-mediated actions, especially when attributes, relationships, and policy context change from one invocation to the next.

Where gateway-only control breaks down in real deployments

The most common failure is assuming that network location or API shape equals trust. In an MCP setup, the gateway may see a valid token and an allowed endpoint, yet still miss the real risk: the agent is about to exercise authority that is too broad, too persistent, or too detached from the human approval context that originally justified it.

Another failure mode is token replay or token passthrough that preserves access beyond the intended audience or tool. A gateway can forward the request, but it cannot always enforce whether the token is bound to the right resource, whether the call is intended for that MCP server, or whether a downstream tool is being invoked under an incorrect security assumption.

Operationally, this is why teams should treat the gateway as one control layer, not the control layer. The right pattern is to combine edge enforcement with server-side policy, strong token scoping, and explicit checks on tool identity and invocation context. For MCP-specific authorization details, the Model Context Protocol: Authorization specification is the clearest standards reference.

For the underlying API control plane, OWASP API Security Top 10 remains relevant because MCP still inherits API-style failure modes such as broken authorization, but MCP adds a runtime context problem that generic API controls do not solve on their own.

Risk and Threat Considerations

Gateway-only designs create a false sense of containment. The main risk is that policy becomes too coarse to distinguish legitimate delegated activity from overreach, which can expose sensitive tools, broaden blast radius, or allow an agent to act outside the human’s intended scope.

Failure mechanism: The gateway validates the request format and transport, but the actual authorization decision is either too shallow or too far from the tool execution point, so context loss, token misuse, or excessive delegation slips through.

Impact: An attacker, malicious prompt, or simply an over-capable agent can trigger unintended tool use, data exposure, or destructive actions while still appearing to use an allowed path.

Practitioner Guidance

What to prioritise: Put runtime authorization at the MCP server or equivalent policy decision point, then use the gateway for coarse ingress control, schema validation, and rate limiting. If those layers disagree, trust the narrower tool-level policy.

What to verify: Confirm that every tool call is bound to the intended audience, that delegated context is preserved end to end, and that policy can distinguish read-only access from state-changing actions.

Common mistake: Treating a valid token or a passing gateway check as proof that the agent should be trusted. For MCP, approval has to be conditional on the specific tool, the current context, and the authority actually granted.

Practitioner takeaway: Use gateways to reduce noise and exposure, but use runtime policy to decide trust, because MCP security fails when transport control is mistaken for authorization.

Related resources from NHI Mgmt Group

• How should teams use APIs and MCP access for security automation without losing control of sensitive context?
• How should security teams apply role-based access control to MCP gateways without giving operators unnecessary data visibility?
• How should AppSec teams use MCP to bring API security data into AI assistants without creating unsafe access paths?
• How should security teams decide whether JIT access is safe for non-human identities?