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.
Editorial analysis by NHI Mgmt Group, based on content published by SlashID: “Breaking MCP at the Identity Layer”.
By the numbers:
- The 2026-07-28 MCP specification shipped with a 12-month deprecation window on legacy versions.
- The ID-JAG in the spec’s example expires in 300 seconds, while the access token it produces expires in 86400 seconds.
Key questions
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 do enterprise consent flows create risk in MCP environments?
A: Because consent can be repeated, confused, or detached from the real enterprise policy decision.
Q: What breaks when MCP tokens outlive the grants that authorised them?
A: Accountability breaks first, because a token can remain valid long after the approving identity context has changed.
Practitioner guidance
- Validate issuer, audience, and resource binding Confirm that every MCP access token is tied to the intended resource server and that cross-server replay is rejected.
- Measure token lifetime drift Compare the lifetime of the grant that authorised access with the lifetime of the token that remains active after issuance.
- Instrument post-issuance behaviour Detect unusual read fan-out, rapid tool chaining, and access bursts that occur after the first valid token use.
Bottom line: MCP authorization shifts the real control point to identity decisions because valid tokens can still be misused after issuance.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
30/07/2026 10:55 pm
MCP authorization is no longer a protocol-only question, it is an identity governance question. The article shows that the server can validate a token perfectly and still be operating under the wrong trust decision. That means access control now depends on how identity systems issue, scope, and interpret authority across the client, host, resource server, authorization server, and IdP. The practitioner conclusion is that MCP governance belongs in identity architecture, not only in API security review.
A few things that frame the scale:
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
A question worth separating out:
Q: How do security teams detect shadow MCP access in practice?
A: They correlate client configuration, registry data, and network telemetry to identify servers that were installed outside approved workflows. The key signal is a valid connection that exists without an approval record, owner, or business justification. If the server is reachable but not governed, it should be treated as exposed delegated access.
👉 Read our full editorial: MCP authorization shifts the security problem to identity layer control