Topic starter
06/11/2026 6:35 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Axiomatics: “MCP Got Serious about Identity. Authorization is Still Your Problem.”.
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.
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.
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.
Practitioner guidance
- Define separate policy points for server access and tool execution Treat MCP server reachability, tool visibility and argument-level authorization as different decisions.
- 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.
- 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.
Bottom line: MCP now provides stronger identity signals and request context, but it still leaves most authorization design to the enterprise.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:41 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Mcp identity hardening still leaves authorization to each server