TL;DR: The latest MCP revision tightens client identity, issuer validation and request integrity, and adds enterprise-managed authorization, according to Axiomatics, but it still leaves fine-grained tool and data decisions to each server team. That means coarse login-time policy is not enough when access varies by user, tool and payload.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Axiomatics's blog post: MCP now hardens identity and request handling, but practical authorization for tools, arguments and returned data remains a separate governance problem.
Why it matters: IAM, PAM and NHI teams need to treat MCP as a layered enforcement problem, because sign-in security alone does not control which tools an agent can see, call or read from.
By the numbers:
- The protocol shipped its largest revision since launch on 28 July 2026.
Context
MCP is the protocol layer that lets an AI agent reach external tools and data sources, so its identity and authorization model now matters to infrastructure teams rather than only to AI builders. The governance gap is no longer whether an agent can connect, but which tools, arguments and returned records should be allowed at each step.
The latest revision changes the trust boundary around authorization models by making identity signals stronger and request context more explicit, but it does not collapse fine-grained access control into the protocol itself. That means control design still has to happen in the enterprise policy layer, not in the transport alone.
At this scale, MCP is starting to behave like shared infrastructure, which means access control mistakes will show up as repeated operational patterns rather than isolated application bugs. The question for practitioners is how to govern each request without assuming a single coarse policy can cover every tool call.
Key questions
Q: How should teams handle MCP authorization when multiple users share the same server?
A: They should avoid shared secrets wherever possible and use delegated authorization that preserves per-user scope and revocation. If a server cannot explain which user or workload owns which access path, the authorization model is too coarse for enterprise use.
Q: Why do stateless MCP servers require tighter authorization than session-based designs?
A: Stateless handling removes reliance on a prior handshake or session ID, so each request has to stand on its own. That reduces the value of session continuity as a trust signal and makes per-call authorization and policy enforcement essential. If the server cannot establish authority at request time, an agent can reach tools that were never meant to be broadly callable.
Q: How do header-based MCP decisions work?
A: Header-based MCP decisions use request headers to carry routing, capability, or policy signals that the server can inspect before exposing tools or context. The header values can drive allowlists, tenant selection, prompt handling, or access checks, so header integrity and normalisation matter. If headers are mutable by intermediaries, they must not be treated as trusted identity proof.
Q: What should teams do when MCP tool lists are user-specific?
A: They should treat the tool list as an access-controlled catalogue, not a fixed client feature. User-specific tool discovery should be tied to the authenticated identity, role, and session state, with server-side filtering so each user sees only the tools they are permitted to invoke. Cached lists, shared sessions, and stale entitlements must be handled carefully.
Technical breakdown
Stateless MCP shifts the control point from session state to request context
The new model removes protocol-level sessions and the initialize handshake, so each request carries its own version, client identity and capability metadata. That makes any server instance able to handle any request behind ordinary load balancing, which simplifies scale but also removes the old assumption that an authorization decision can be tied to a stable conversation state. Security decisions now have to ride on request-local facts rather than a long-lived session container. See the Authorisation Models Guide.
Practical implication: Design enforcement so each request is independently authorizable, not dependent on sticky session state.
Enterprise-managed authorization centralises coarse access, not fine-grained decisions
Enterprise-managed authorization lets the corporate identity provider decide which MCP servers a user may reach, then issues a token that represents that approval. That solves the first gate, but it only covers coarse reachability. It does not know whether a later tool call should be allowed for a classified field, a different legal entity, or a particular sequence of actions, so the server still needs its own decision logic. See the AI Agent Authorisation Guide.
Practical implication: Use central identity policy for server reachability, then enforce tool and data rules separately at the server or gateway.
Header-based decisions make tool calls policy-readable before payload parsing
The protocol now places the method, tool name and selected arguments into headers so intermediaries can evaluate policy before opening the body. That is useful because gateways, routers and policy engines can make an authorization decision earlier in the path. The integrity check matters just as much: if headers and message body disagree, the server must reject the request. Without that consistency rule, header-based policy would be easy to spoof.
Practical implication: Evaluate policy from signed or validated request context, and reject any header-body mismatch immediately.
Threat narrative
Attacker objective: The objective is to move from approved MCP access to broader tool visibility or data access than the policy intended.
- Entry begins with an agent or client reaching MCP through a normal sign-in flow or preconfigured credential path, giving the request a legitimate-looking identity context.
- Escalation can occur when coarse server-level approval is reused for later tool calls that should have been filtered by tool, attribute or data sensitivity, allowing broader access than intended.
- Impact follows when cached tool lists, mismatched headers or overbroad server grants let an agent call or discover capabilities that expose sensitive records or operational actions.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Authorization for MCP is now a layered control problem, not a login problem. The revision improves who the client is and how requests identify themselves, but that only settles the first decision on the path. Every later tool call still needs its own governance logic for tool visibility, argument sensitivity and response filtering. The practitioner implication is that identity hardening must not be mistaken for complete access control.
Coarse enterprise-managed authorization is useful, but it does not solve request-time discretion. Central approval can answer which MCP servers a user may reach, yet it cannot determine whether a specific tool call should return masked data, partial records or a refusal. That is why authorization models still matter after the IdP has spoken. The implication is that teams must separate server reachability from per-call policy.
Header trust is the new authorization boundary, and it fails if request metadata and payload drift apart. MCP now gives gateways enough context to decide early, but that benefit only exists because the protocol demands consistency between headers and body. Without that check, a policy engine would be making decisions on attacker-controlled hints. The implication is that enforcement points need to treat metadata integrity as part of the control, not as an implementation detail.
Tool-list caching creates a visibility governance gap. If different users are meant to see different tools, cached lists can accidentally flatten those differences and expose capabilities to the wrong identity. That is not just a cache setting issue; it is a failure of per-user entitlement design. The implication is that tool discovery must be governed like any other identity-sensitive entitlement.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- Read next: MCP Security Guide
What this signals
Fine-grained authorization will become the differentiator in MCP programmes. Identity hardening will keep improving, but the practical risk will remain the gap between who can sign in and what each tool call is allowed to do. Programmes that stop at server-level reachability will still leak privilege through discovery, argument handling or cached visibility.
Tool visibility is now a governance control, not a UX detail. Once agents can only act on what they can see, per-user discovery responses become part of the security model. Teams should expect policy mistakes here to look like ordinary caching bugs until an overexposed tool or response reveals the real problem.
The new request model also pushes enforcement closer to the boundary where agent intent becomes observable. That means gateways, policy engines and server teams will need a shared view of authorization evidence, not separate interpretations of the same call.
For practitioners
- Define separate policy points for server access and tool execution Treat MCP server reachability, tool visibility and argument-level authorization as different decisions. Map each one to a distinct enforcement point so a single coarse grant does not become the default for every request.
- Mark per-user tool lists as private by default If a user should not see every tool, ensure discovery responses cannot be stored in a shared cache under public scope. Visibility filtering only works when cached results stay identity-bound.
- Reject any mismatch between request headers and message body Compare the tool name, method and mirrored parameters in the headers with the message content before authorizing the call. If the values differ, fail closed rather than letting policy rely on inconsistent metadata.
- Move coarse server approval into the identity provider Use enterprise-managed authorization for the question of which MCP servers an identity may reach, then handle record-level and tool-level rules at the point where the data or action is actually exposed.
Key takeaways
- MCP now provides stronger identity signals and request context, but it still leaves most authorization design to the enterprise.
- The main governance challenge is no longer whether an agent can connect, but which tools, arguments and returned records it may use.
- Practitioners need separate controls for reachability, discovery and per-call decisions if they want MCP to stay safe at scale.
Related NHI Mgmt Group resources: AI Agent Authorisation Guide · Authorisation Models Guide · MCP Security Guide · AI Agent Observability, Audit and Incident Response Guide
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 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP now carries agent identity and privilege decisions closer to runtime, which is central to agent privilege abuse. |
| ASI02 — Tool Misuse | The post focuses on tool selection, tool visibility and request-time authorization for agent actions. | |
| ASI09 — Human-Agent Trust Exploitation | MCP authorization still has to prevent deceptive or overbroad trust between users and agents. | |
| Recommendation — Limit agent privileges to the exact tool and data scope needed for each call. Constrain tool exposure and validate every call against policy before execution. Require policy checks that prevent agents from acting on assumptions about user intent or consent. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The revised MCP identity checks address issuer validation, client identity and token binding for non-human clients. |
| NHI-05 — Overprivileged NHI | The article warns that coarse grants and cached tool lists can still expose more access than needed. | |
| Recommendation — Bind tokens and client identity to a trusted issuer and reject mismatched authentication context. Scope each MCP identity to the minimum server and tool access required for its task. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | MCP authorization is fundamentally about entitlements, per-request permissions and tool-level access decisions. |
| Recommendation — Apply entitlement controls at server, tool and data levels rather than relying on login-time approval alone. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- Enterprise-Managed Authorization: Enterprise-managed authorization is a policy model in which the identity provider decides what an agent may do and encodes that decision into the token or access flow. It helps organisations keep control logic centralized instead of spreading entitlement decisions across many servers.
- Header-body mismatch: Header-body mismatch occurs when the metadata carried in an HTTP header disagrees with the action encoded in the request body. In MCP, that mismatch can undermine gateway policy unless implementations compare both representations and reject any inconsistency.
- Policy Enforcement Point: A policy enforcement point is the control that applies an authorization decision at the place where an action occurs. In distributed systems, it may sit inside an API gateway, application, or workflow engine, and it depends on a consistent decision format to avoid bespoke integrations.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org