Notifications
Clear all
Topic starter
30/07/2026 10:48 pm
TL;DR: MCP’s 2026 authorization model separates resource server, authorization server, and client roles, adds protected resource metadata and resource indicators, and moves enterprise consent into the IdP through EMA, according to SlashID. The remaining gap is not protocol correctness but post-issuance behaviour, token lifetime drift, and cross-hop provenance that conventional OAuth validation does not reveal.
NHIMG editorial — based on content published by SlashID: MCP authorization, consent, and identity-layer security gaps
By the numbers:
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: How should security teams govern MCP access when tokens are valid but behaviour is not trustworthy?
A: Security teams should treat token validity as the starting point, not the end of the control check.
Q: Why does MCP increase the governance burden for IAM and NHI teams?
A: Because one published capability can be reused across many hosts, models, and runtime surfaces.
Q: What breaks when consent is handled by the wrong layer in MCP?
A: When consent is handled in the browser or app layer, the enterprise loses policy consistency and revocation control.
Practitioner guidance
- Separate resource-server and authorization-server responsibilities Map every MCP endpoint to one identity role only.
- Enforce audience binding on every MCP token Require the resource parameter, validate the audience claim, and reject tokens that were minted for any other server.
- Move enterprise consent into the IdP Use IdP-managed policy decisions for MCP integrations instead of relying on browser prompts or app-local approval flows.
What's in the full article
SlashID's full article covers the operational detail this post intentionally leaves for the source:
- The full RFC-by-RFC authorization flow, including protected resource metadata, resource indicators, and client registration mechanics.
- The confused-deputy scenario and the consent-cookie failure path across stacked OAuth layers.
- The EMA and ID-JAG exchange details, including the exact delegation sequence and token lifetime behaviour.
- The mapped detection gaps, including identity graph traversal and post-issuance read-burst behaviour.
👉 Read SlashID's analysis of MCP authorization, consent, and identity-layer gaps →
MCP authorization and consent: what identity teams need to fix?
Explore further
30/07/2026 10:55 pm
Valid token, wrong behaviour is the central MCP governance problem. MCP authorization is not failing because tokens are absent. It is failing when valid grants are treated as sufficient evidence of trustworthy use, even after delegation, fan-out, or downstream reuse. That changes the governance question from authentication success to identity behaviour review. Practitioners should stop equating protocol validity with access legitimacy.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to the State of MCP Server Security 2025.
- Our research on NHI exposure shows that 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which confirms that configuration sprawl is still a live identity risk.
A question worth separating out:
Q: Who should own MCP authorization in an enterprise?
A: MCP authorization usually sits at the intersection of IAM, API security, and platform engineering, but the ownership model should be explicit. Identity teams should own authentication and policy standards, platform teams should own gateway enforcement, and application teams should own the tool inventory and business justification.
👉 Read our full editorial: MCP authorization shifts the security problem to identity layer control
