Notifications
Clear all
Topic starter
06/07/2026 9:38 am
TL;DR: MCP’s auth spec leaves the orchestration layer unresolved, so routing, consent, step-up MFA, tenant selection, and claim enrichment become the real control points for AI agent access, according to Descope. The gap is not token issuance alone, but whether identity governance can express context, scope, and approval inside the OAuth flow.
NHIMG editorial — based on content published by Descope: The Power of Descope Flows for MCP identity orchestration
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should teams govern MCP access when multiple tenants share the same user identity?
A: Treat tenant selection as an authorization decision, not a convenience step.
Q: Why do MCP deployments need more than standard OAuth token validation?
A: Because the protocol only defines the token endpoints and format, not the control logic between request and issuance.
Q: What do security teams get wrong about consent screens for AI agents?
A: They often treat consent as a list of scope names instead of a governance checkpoint.
Practitioner guidance
- Map the authorization journey before the server code Document every decision that happens between MCP request and token issuance, including tenant routing, consent, MFA, and claim enrichment.
- Bind each token to an explicit tenant context Require a deterministic tenant selection step when users can belong to multiple organisations, and populate a tenant claim that the server can trust for downstream tool exposure and role evaluation.
- Make high-risk scopes trigger step-up authentication Inspect requested scopes at authorization time and branch sensitive actions into a stronger challenge before consent is shown.
What's in the full article
Descope's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step configuration of MCP authorization flows, including the specific Descope Flow actions used for routing and consent.
- Examples of tenant selector and SSO enforcement behaviour inside the auth journey, including how the dct claim is populated.
- Implementation details for claim enrichment connectors that fetch roles or permissions from external systems before token issuance.
- Policy examples showing how scope approval is blocked or reduced when a user context does not meet access requirements.
👉 Read Descope's analysis of MCP identity orchestration with Flows →
MCP identity orchestration: what IAM teams need to control?
Explore further
06/07/2026 9:53 am
The real control plane for MCP is the orchestration layer, not the protocol itself. MCP deliberately avoids prescribing what happens between authorization request and token issuance, which means the implementer inherits the hardest governance decisions. That creates a policy gap if tenant routing, consent, and scope gating are treated as afterthoughts. The implication is that teams must stop thinking about MCP auth as a standards problem and start treating it as an identity orchestration problem.
A few things that frame the scale:
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
A question worth separating out:
Q: How can IAM teams decide which MCP scopes should trigger stronger authentication?
A: Use the risk of the requested action, not the volume of scopes, to decide. Sending mail, accessing sensitive records, or writing to production systems should branch into step-up authentication before consent, while lower-risk actions can follow the normal flow.
👉 Read our full editorial: MCP identity orchestration shows why auth needs more than OAuth
