MCP identity orchestration shows why auth needs more than OAuth

At a glance

What this is: This is an analysis of how MCP authorization depends on an orchestration layer for tenant routing, consent, MFA, and claims before a token is issued.

Why it matters: It matters because IAM and NHI teams have to govern agent access decisions inside the auth flow itself, not just validate tokens after the fact.

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.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Descope's analysis of MCP identity orchestration with Flows

Context

MCP authorization is not just about validating a token. The security and governance problem is the orchestration that happens before issuance, where tenant selection, consent handling, MFA, and claim enrichment determine what the MCP server will later trust.

For IAM and NHI programmes, that means the meaningful control point is the authentication and authorisation journey itself. If the flow cannot express context such as which tenant, which scope, and which approval conditions apply, the resulting token is too blunt for agentic access.

Descope positions Flows as the layer that carries this orchestration burden. The broader takeaway is that MCP deployments expose a familiar identity problem in a new place: policy has to live close to issuance, not only at the resource server.

Key questions

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. The flow should determine which organisation is active before token issuance, then place that choice into a trustworthy tenant claim so the MCP server can apply the correct tools, SSO path, and role boundaries.

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. Teams still need routing, consent, step-up checks, and claim enrichment to turn a valid token into a governed one with real operational context.

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. Users need plain-language descriptions, selective approval, and a clear sense of what the agent can do, otherwise the consent step becomes a formality rather than a control.

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.

Technical breakdown

MCP authorization needs orchestration, not just token issuance

The MCP auth spec defines the endpoints, token format, and PKCE expectations, but it leaves the decisioning between request and issuance to the implementer. That middle layer is where tenant routing, consent wording, step-up checks, and claim shaping happen. In practice, it acts like an identity policy engine wrapped around OAuth, because the server later receives only a JWT and must infer context from claims. If that orchestration is missing, the server sees a valid token but not a sufficiently governed one.

Practical implication: keep authorisation logic in a controllable orchestration layer instead of scattering it across MCP server code.

Tenant routing and SSO determine which identity context the token represents

Multi-tenant users often belong to several organisations, so a single email address is not enough to infer the right access context. Routing based on domain, selector choice, or request context determines which tenant claim is embedded in the token. That tenant context then drives which SSO provider authenticates the user and which tools the MCP server exposes. Without that step, the server risks accepting the wrong organisational identity, which is a governance failure as much as an authentication one.

Practical implication: make tenant disambiguation explicit before token issuance, then bind downstream authorisation to that tenant claim.

Scope-aware step-up MFA and claim enrichment tighten tool-level authorisation

MCP scopes are only useful if they carry real meaning for users and for the server. A scope-aware flow can branch to stronger authentication when the requested action is sensitive, then enrich the JWT with external role, entitlement, or feature-flag data from internal systems. That lets the MCP server make tool-level decisions without a secondary API call. The architecture matters because the token becomes the policy carrier, not just a login artifact.

Practical implication: use step-up MFA for high-risk scopes and enrich tokens with the context the server actually needs.

NHI Mgmt Group analysis

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.

Contextual authorisation matters more for AI agents because scope text is not enough. Agent-driven access often hides the operational meaning of a scope from the user, so plain-language consent and selective approval become governance controls, not UX polish. When users can approve some permissions and reject others, the flow carries actual intent into the token. That makes consent quality part of the trust model for agentic access.

Tenant ambiguity is a hidden identity risk in multi-context environments. A single user can represent a personal workspace, a client tenant, and an employer account, all from one identifier. If the flow does not disambiguate which organisation is active, the wrong tools, claims, or SSO route can be applied. Practitioners should treat tenant selection as an access decision, not a navigation step.

Claim enrichment turns MCP tokens into governance-bearing artefacts. When roles, entitlements, and feature flags are embedded during issuance, the token carries enough context for tool-level decisions without additional lookups. That aligns better with zero trust and least privilege than relying on generic identity assertions alone. For NHI programmes, the lesson is clear: access context has to be minted with the credential, not inferred later.

From our research:

• 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.
• That governance gap connects directly to OWASP Agentic Applications Top 10, which practitioners can use to frame runtime controls and policy boundaries for agent-driven access.

What this signals

Context-rich token issuance will matter more as agentic access expands. As MCP deployments mature, the question is no longer whether a server can validate a JWT. The question is whether the identity layer can preserve enough tenant, scope, and entitlement context to make the token usable for governance, audit, and safe tool exposure.

AI agent access control is moving upstream into the auth journey. If 92% of organisations say governing AI agents is critical but only 44% have policies in place, the gap is not conceptual, it is operational. That is why orchestration, not just validation, is becoming the identity control point for autonomous access patterns.

Tenant disambiguation is becoming a named control problem in multi-organisation identity. When one user can represent several business contexts, the active tenant becomes part of the security boundary. Teams should expect more policy decisions to be made at issuance time and should align that model with NIST AI Risk Management Framework governance expectations.

For practitioners

• 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. Then decide which of those decisions belong in a policy layer instead of application logic.
• 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. Use the pause to force user review of what the agent will actually do.
• Enrich issued tokens with operational claims Pull roles, permissions, and account metadata from internal systems during the flow so the JWT carries enough context for granular authorisation at the MCP server without a secondary lookup.

Key takeaways

• MCP exposes a governance gap between protocol compliance and real authorisation control.
• Tenant routing, consent quality, step-up MFA, and claim enrichment are the practical identity controls that shape agent access before token issuance.
• IAM and NHI teams should treat orchestration as a policy surface, because validated tokens alone do not guarantee governed tool use.

Key terms

• Mcp Authorization Orchestration: The control layer that manages what happens between an MCP authorization request and token issuance. It can route tenants, enforce step-up checks, shape consent, and enrich claims so the resulting token carries the right context for downstream access decisions.
• Tenant Claim: A token claim that identifies which organisational context a request should operate under. In multi-tenant environments, it prevents ambiguous identity from collapsing into the wrong access boundary and gives the MCP server a reliable signal for tool selection and policy enforcement.
• Scope-Aware Step-Up Authentication: An authentication pattern that increases the strength of verification when the requested action is sensitive. It treats scope risk as a trigger for extra assurance, which is especially useful when AI agents request actions that users may approve too quickly.
• Claim Enrichment: The process of adding externally sourced identity or entitlement data to a token during issuance. It lets downstream systems make finer-grained decisions without calling back to another service, but it only works if the added claims are trustworthy and operationally maintained.

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.

👉 The full Descope post covers flow design, tenant routing, and claim enrichment details for MCP deployments.

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.