Why do stateless MCP headers not solve authorisation on their own?

Why stateless MCP headers do not authorise a caller

Stateless headers improve observability, but they do not establish entitlement. A request can carry Mcp-Method and Mcp-Name and still be unauthorised if the caller is not allowed to invoke that tool in that context. The control point is not the header itself, it is the policy decision behind it.

What the headers actually do, and what they do not

In an MCP flow, headers are useful metadata for routing, logging, filtering, and request classification. That is valuable, because it gives servers and gateways more structured context about what is being asked. But metadata is not proof of permission. A tool name in a header says what the caller wants to do, not whether it may do it.

This distinction matters because authorisation is a decision, not a declaration. The decision needs an independent trust basis, usually combining identity, permissions or capability grants, and policy context such as environment, user intent, tool sensitivity, or risk posture. Without that separate decision, a stateless header is just an input to enforcement, not the enforcement itself.

Why protocol visibility is not the same as trust

Stateless designs are often attractive because they reduce server-side session state and make requests easier to inspect at the edge. But inspectable does not mean trustworthy. An attacker, a misconfigured client, or a compromised agent can present the same header values as a legitimate caller unless the server validates who is calling and what that caller has been allowed to do.

The same problem appears in broader access-control design: if the system treats request attributes as if they were proof of authority, it creates a confused deputy risk. The service may know the method name, but it still needs a policy engine or equivalent authorisation check to decide whether that method is permitted for this caller right now. NHI lifecycle and access-governance material such as Authorisation Models Guide and AI Agent Authorisation Guide cover the underlying decision models that stateless headers cannot replace.

What a correct authorisation path needs instead

A sound MCP implementation separates signalling from decision-making. The header can identify the requested method, but the server should still evaluate the caller against identity, token scope or capability, and the applicable policy. In practice, that means checking whether the request maps to an allowed action, whether the token is valid for the audience, and whether the invocation is acceptable in the current trust boundary.

That is why the MCP specification treats authorisation as an explicit protocol concern rather than an inference from request metadata. The same principle is reinforced in broader guidance on API and workload access control, including Model Context Protocol: Authorization specification, MCP Security Guide, and the OWASP OWASP Agentic AI Top 10 because tool misuse and identity and privilege abuse are separate failure modes from request parsing.

Risk and Threat Considerations

When headers are mistaken for authorisation, the main risk is overexposure of tools and downstream actions. A caller can replay or forge a seemingly valid method header, then reach operations that were never intended for that principal. In agentic and MCP-style systems, that can quickly become tool misuse, privilege abuse, or sensitive data access through a trusted integration path.

Failure mechanism: the service trusts request metadata as evidence of entitlement, or it fails to bind the request to a validated identity and policy decision. That leaves the tool surface open to header spoofing, confused deputy behaviour, and privilege escalation through an integration channel that appears stateless and therefore deceptively simple.

Impact: unauthorised tool execution, wider blast radius for a compromised client or agent, and weak auditability because the system can log what was requested without proving that the requester was allowed to request it. Over time, this also makes least-privilege enforcement and incident review much harder.

Practitioner Guidance

What to verify: verify that every tool invocation is authorised after authentication, not before it. The header should feed the decision, never substitute for it. If the same request can succeed from two principals with different entitlements, you still need a policy check that distinguishes them.

Decision rule: if a request header can influence routing or logging, treat it as metadata only; if it can influence whether the tool runs, bind it to an identity-aware authorisation decision with explicit policy inputs. For MCP gateways and agent integrations, IAM and IGA Basics and MCP Security Guide are useful references for the separation between access control and request metadata.

Practitioner takeaway: statelessness reduces server memory, not security trust. If you want safe tool execution, make authorisation an explicit runtime decision with identity and policy context, then treat MCP headers as informative inputs rather than proof of permission.

Related resources from NHI Mgmt Group

• How can organizations secure their MCP server credentials?
• Why is OAuth considered a better alternative for MCP servers?
• Why is it crucial to adopt new authentication methods in MCP usage?
• What is MCP Step-Up Authorisation and how does it implement least privilege for agents?