It leaves the organisation unable to evaluate who is really behind the tool call, why the call is happening, and how sensitive the target tool is. That creates a gap where technically valid requests can still trigger privileged actions without meaningful authorisation context. The result is control that looks present but cannot govern agent behaviour.
Why routing and authentication are only the outer shell
An mcp gateway that stops at routing and authentication proves only that a request arrived from a recognised client. It does not answer the harder questions that determine whether the request should be allowed: who is acting, what delegated authority they have, whether the target tool is appropriate, and whether the action is consistent with the user’s intent and the tool’s sensitivity.
That is why MCP guidance now treats the gateway as an authorisation decision point, not just a transport filter. The security model has to carry context from identity, token scope, tool purpose, and downstream resource sensitivity, otherwise the gateway becomes a pass-through layer that can be bypassed by any technically valid call.
For the protocol side of that boundary, the MCP authorization specification is the clearest reference point for how gateways should treat access tokens, audiences, and server-side enforcement rather than token passthrough.
What breaks when authorisation context is missing
The first failure is decision quality. A gateway may be able to authenticate a client, but still be unable to distinguish a harmless read from a privileged write, or a tool that is safe for one workflow from a tool that should only be used under tighter conditions. Without contextual authorisation, the gateway cannot apply policy that reflects the actual business impact of the call.
The second failure is blast-radius control. If all valid calls are treated as equally acceptable, an agent or integration can invoke high-value tools with the same ease as low-risk ones. That creates a path for overprivileged action, confused-deputy behaviour, and accidental or malicious escalation through a gateway that appears secure at the perimeter but is blind to runtime intent.
The third failure is auditability. When a request is only checked for route and login state, logs may show a successful request but not the reason it was allowed, the policy basis for the decision, or whether the call matched the actor’s delegated scope. That makes incident review and access governance much weaker than the presence of a gateway implies.
The protocol-level control problem is closely related to the agent-side risk in OWASP Agentic AI Top 10, especially where tool misuse and identity or privilege abuse occur through trusted integration paths.
What a gateway must evaluate beyond login success
A useful MCP gateway has to evaluate more than authentication state. It needs policy that can distinguish the caller’s identity from the authority granted to that caller, the intended tool from the sensitive one, and the current action from the broader workflow it supports. In practice, that means binding tokens to the right audience, avoiding blind passthrough, and enforcing per-tool or per-operation rules at the enforcement point.
It also needs an answer to the question, “Is this call proportionate?” A gateway that can’t express proportionality will either block legitimate automation or allow excessive access. The mature middle ground is to constrain access by context, scope, and purpose, then step up only when the action crosses into a higher-risk tool or a more sensitive operation.
Where organisations need a broader practitioner frame for this design, the MCP Security Guide covers the authorisation model, token handling, and gateway checks that prevent a routed request from becoming an unreviewed privileged action.
Risk and Threat Considerations
A gateway that validates only routing and authentication creates a false sense of control. The main exposure is not login failure, it is authorised-looking traffic being allowed to reach sensitive tools without a meaningful check on delegated authority, tool criticality, or the legitimacy of the action itself.
Failure mechanism: the gateway accepts a request because the caller is authenticated and the route exists, but it lacks policy context to decide whether that caller should be allowed to invoke that specific tool or action. That gap can be exploited by overprivileged agents, stolen tokens, or legitimate integrations that are pointed at the wrong tool with no runtime restriction.
Impact: privileged actions can execute under technically valid requests, making the control ineffective exactly where it should provide separation between access and authority. The result is exposed tools, weak containment, and an audit trail that cannot explain why the action was permitted.
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 and OWASP Non-Human Identity Top 10 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Gateway-only checks fail when agent authority is not evaluated. |
| ASI02 — Tool Misuse | A routed authenticated call can still invoke the wrong or risky tool. | |
| ASI09 — Human-Agent Trust Exploitation | Weak gateway checks let trusted-looking requests trigger harmful actions. | |
| Recommendation — Enforce action-level authorization for each agent tool call. Restrict tool invocation by context, scope, and policy. Require explicit policy checks before high-impact agent actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Authentication alone is insufficient if authorisation context is missing. |
| NHI-05 — Overprivileged NHI | Valid requests can still overreach when tools are broadly exposed. | |
| NHI-10 — Human Use of NHI | Human-driven actions through a gateway need clear delegation and intent. | |
| Recommendation — Bind tokens to the correct audience and enforce server-side authorization. Constrain non-human identities to least-privilege tool access. Separate human intent from machine execution with explicit policy checks. | ||
Practitioner Guidance
What to verify: confirm that the gateway enforces authorisation decisions at the tool or action level, not just at the route or session level. If the only evidence is “the request authenticated successfully,” the control is incomplete for agentic use cases.
Decision rule: if a request can change data, trigger an external side effect, or touch a sensitive system, require policy that evaluates caller context and target sensitivity before execution. Treat authentication-only approval as insufficient for anything beyond low-risk read paths.
Practitioner takeaway: The gateway should decide whether the actor may do this thing now, not merely whether the request came from someone who was allowed to knock on the door.