Most AI agents reach enterprise applications the same way: a static API key stored in a config file, rotating only when something breaks. That credential carries whatever permissions the person who created it had, gives no indication which agent used it, and can't be revoked without hunting down every place it was pasted.
As organizations move from individual AI experiments to agents running workflows on behalf of teams, that approach stops working. The identity problem shows up before the productivity gains do.
The governance gap
In most SaaS-to-SaaS OAuth flows today, the enterprise SSO identity provider sees the human login but not the agent connection that follows. When a user authorizes an AI application to reach a tool, that grant is negotiated directly between the client and the resource, outside the SSO IdP. The IdP records "user signed in" rather than "an AI application can now act as this user in this tool."
That leaves IT unable to answer basic security questions: which AI applications have access to which tools, under whose authorization, and with what permissions. A survey of 750 technology leaders found that 54% of organizations experienced or suspected an AI agent security incident in the past year. IBM research found that 97% of organizations hit by an AI-related security incident lacked proper AI access controls.
The gap isn't a failure of OAuth. OAuth was designed for direct user-to-application relationships, not for the layered structure where an AI client acts on behalf of a user to reach a downstream application. When the SSO IdP isn't the downstream application's authorization server, it sits outside that grant and has no role in governing it.
What the MCP authorization extension does
The MCP specification now includes a stable extension for enterprise-managed authorization, built on the Identity Assertion JWT Authorization Grant (ID-JAG), which is currently being standardized at the IETF. The extension is also known in the ecosystem as Cross App Access (XAA).
The core idea: put the enterprise identity provider back in the authorization flow for agent connections. Instead of agent-to-application OAuth happening outside IT's view, the IdP becomes an explicit decision-maker. Administrators configure which AI clients can connect to which MCP servers. Users authenticate via SSO. From there, authorization runs without further user interaction: the AI client requests a short-lived assertion from the IdP, the IdP evaluates policy and issues it, and the MCP server's authorization server validates it and issues a scoped access token.
The result is what the spec calls zero-touch SSO: a user signs in once and authorized connections provision automatically, without per-server OAuth prompts, without per-user consent screens during organization-wide rollouts.
"Cross App Access is the result of a massive, two-year collaborative effort within the OAuth working group to ensure secure, revocable agent delegation."
Aaron Parecki, Co-Chair of the IPSIE Working Group (OpenID Foundation) and Co-Chair of the SCIM Working Group (IETF)
The authorization flow
The ID-JAG flow runs in six stages:
1. SSO login. The user authenticates to the AI client via enterprise SSO (OIDC). The IdP validates credentials and returns an ID token to the client.
2. Assertion request. The AI client calls the IdP's token endpoint via OAuth Token Exchange (RFC 8693), requesting an identity assertion targeting a specific MCP server. This is the key departure from standard OAuth: the client isn't requesting resource access directly, it's requesting a signed authorization grant from the IdP.
3. Policy evaluation. The IdP evaluates the request against administrator-configured policy: whether this client is authorized to connect to this MCP server, whether the requested scopes meet least-privilege requirements, whether the user belongs to an allowlisted group, and whether the resource requires step-up authentication.
4. Assertion issuance. If policy passes, the IdP returns a short-lived, signed JWT assertion scoped to the specific client, user, server, and approved permissions. The assertion carries an audience claim bound to the downstream authorization server, so it can't be accepted by a different one.
5. Assertion presentation. The AI client presents the assertion to the MCP server's authorization server using the JWT-bearer grant (RFC 7523).
6. Access token issuance. That authorization server validates the assertion's signature against the IdP's JWKS endpoint, using the same trust mechanism already in place for SSO tokens. On successful validation, it issues a short-lived access token limited to the approved scopes. The client presents that token to the MCP server on each tool call, which enforces the approved scopes.
No long-lived per-server API keys accumulate, so there's no downstream secret to store or rotate across every place it was pasted. Client credentials and any IdP refresh tokens still follow normal lifecycle management. The IdP's policy controls what gets through, and short assertion and token lifetimes, single-use jti handling, and optional sender-constraining bound the damage from a stolen assertion.
What this means for security teams
The extension shifts the control point for AI agent access from individual application configurations to the identity provider, where enterprise governance already operates. For IAM and security teams, that changes a few things concretely.
Centralized visibility. The IdP logs which AI clients request access to which MCP servers, for which users, with what scopes. That data flows into the same audit trail that already captures employee logins. Runtime tool-call auditing still lives in the MCP server or gateway layer, so the IdP logs complement it rather than replace it.
Policy-driven provisioning. Administrators define access rules once in the IdP console. When a new MCP server is added to the environment, access policy is configured there, not distributed across individual user consent screens.
Single revocation. Disabling a client's access at the IdP immediately blocks new authorizations for all users. Already-issued tokens age out on their short expiry, or where the downstream authorization server supports revocation, can be cut off directly, so there's no long-lived secret to track down across applications.
Short credential lifetimes. Because the IdP reissues assertions under policy on each request, no long-lived downstream secret needs to persist. The blast radius of a compromised credential is bounded by the assertion's expiry window.
Standards-based interoperability. The ID-JAG specification is built on OAuth Token Exchange and JWT assertions. It defines common OAuth building blocks for interoperable implementations, so organizations aren't locked into a single client-server combination.
Practical considerations for IAM teams
A few things to evaluate before planning a rollout:
Confidential client requirement. The ID-JAG profile is intended for confidential or otherwise protected clients, those that authenticate to the IdP with a client secret or private-key JWT. Public browser-only apps without a backend generally can't participate and should fall back to the standard authorization-code flow. This limits the pattern to server-side or similarly protected applications.
Audience claim coordination. The IdP must issue assertions with audience claims pointing to the downstream MCP server's authorization server. For SaaS applications that have shipped XAA support, this mapping is typically pre-configured. For custom MCP servers, it requires coordination between the client developer, IdP administrator, and server operator.
Assertion validation. The authorization server issuing MCP access tokens must validate assertions with the same rigor applied to enterprise OIDC tokens: signature verification against JWKS, claims validation, audience checks, scope enforcement, expiry checks. Weak validation here breaks the control point even if the IdP is correctly configured.
IdP readiness. The spec is newer than most deployed IdP versions. Okta is the first identity provider with public support at launch, so confirm that your IdP has shipped a compatible implementation before planning an enterprise rollout.
Where adoption stands
The MCP enterprise authorization extension shipped as stable in mid-2026. On the server side, early adopters include Asana, Atlassian, Canva, Figma, Linear, and Supabase. On the client side, implementation has started in Claude and Visual Studio Code. The IETF standardization process for ID-JAG is active.
For enterprise security teams, the practical shift is that AI agent access no longer has to operate outside existing governance infrastructure. Identity-governed agent access is now technically defined, so the remaining work is assessing which implementations are production-ready for your stack and what configuration sits between your current IdP setup and the controls the spec enables.
The extension specification and reference implementation are available at github.com/modelcontextprotocol/ext-auth. The underlying ID-JAG specification is tracked at the IETF OAuth working group.
