The access model built for agents: EMA, ID-JAG, and XAA

TL;DR: AI agents are running on standing, over-scoped access. The risk doesn't require an adversary. An agent can do exactly what it was authorized to do after interpreting a narrow instruction broadly. EMA and ID-JAG can replace the standing grant with a credential scoped to one task that expires when the task ends. Enabling it depends on your IdP vendor and every MCP server vendor you touch, which makes it a procurement question this quarter. Cyera Identity (formerly Oasis Security) evaluates intent against policy before any token is requested through Agentic Access Management (AAM). It governs agent access with EMA where possible, and provides an alternative if the far end hasn't shipped the standard yet.

What Does Over-Scoped Agent Access Actually Cost You?

You spent a decade eliminating standing privilege for your workforce. Agents reintroduced it in eighteen months, and this time the holder cannot be trained, warned, or asked what it was thinking.

The instruction you give an agent is narrow. The token it carries is not. That gap is where the risk lives, and it does not require an attacker to become expensive.

• An agent asked to close stale tickets in one project holds read:jira-work and write:jira-work. It interprets "stale" more broadly than you meant and closes an active security escalation in a project nobody asked it to touch.
• An agent asked to summarize one team's work reads every project the token can reach, because nothing told it where the boundary was. That summary lands somewhere the source data was never cleared for.
• An agent retries a failed action. The refresh token is still valid for months, so the retry succeeds at 3am with no human attached to it.

Every one of these is a correctly authenticated, fully authorized action. Your logs will show nothing wrong. Adversarial input makes all of it worse, but you do not need adversarial input to get here. You only need an agent that is slightly wrong about what you meant, holding a credential that was never bound to what you asked.

You cannot close that gap by writing better instructions. A probabilistic system is not bounded by prompt engineering. It is bounded by a narrower credential.

Why AI Agents Need a Different Access Model Than OAuth

OAuth consent was designed for a person granting a third-party app access to their own data, and at that job it is genuinely good. The person doing the granting is the person whose data is on the line. The scope list is right there in front of them. And they are deciding once, about a tool they will go on using themselves.

An AI agent breaks all of that at once. It is acting for someone who is not watching, at machine speed, and most of what it does is never reviewed action by action. What it needs is access scoped to the single thing it is doing right now, for only as long as that takes, decided by policy rather than by someone clicking approve.

The consent model has no primitive for any of that. Four properties of an ordinary grant show where the gap sits, and each one maps to a consequence you have already read above.

• Duration. A consent grant returns a refresh token carrying offline_access, valid for months of repeated use. An agent needs access only for the length of a single task. Multiply the difference by every agent your teams stand up this quarter.
• Scope granularity. Jira offers read:jira-work, write:jira-work, read:jira-user. Those scopes cover everything the user can reach across their whole workspace. An agent triaging a single project has no way to request less, so the blast radius of a misinterpretation is your entire workspace.
• Visibility. Consent grants are stored client-side. Identity teams cannot enumerate them or attribute an agent's actions to them, which is precisely the question you will need answered during an investigation.
• Revocation. The only lever is disconnecting the integration entirely. A single agent's access cannot be narrowed or withdrawn on its own.

That is what the standards work is chipping away at. Some of those gaps are closer to closed than others.

What Are EMA, ID-JAG, XAA, and Token Exchange?

The shift is from asking each user to authorize each connection, to your enterprise brokering access centrally and issuing a credential that is scoped to one task and expires with it.

Four acronyms, and they are not four options you pick between. There is one pattern, one spec that implements it, one application of that spec to MCP, and the primitive doing the work underneath.

• XAA (Cross-App Access) is the pattern. Your enterprise already has a trust relationship with an identity provider. Use it to broker access between applications instead of asking each user to re-authorize each pair.
• ID-JAG (Identity Assertion JWT Authorization Grant) is the spec. It is an active IETF OAuth Working Group draft, currently at revision 06. A user's existing SSO identity is exchanged at the IdP for a signed, short-lived, audience-bound assertion that names exactly who is acting, on whose behalf, and against which downstream service. It builds on existing OAuth plumbing rather than inventing any.
• EMA (Enterprise Managed Authorization) is how the spec gets applied to MCP. An admin centrally authorizes approved clients once, instead of every user self-authorizing every server. When a user signs in, the MCP server is already connected. No consent screen. EMA became a stable MCP extension on June 18, 2026. Okta is the first supported identity provider, Anthropic's Claude and Visual Studio Code are among the clients, and Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase are among the servers that support it. Support is uneven: Atlassian describes its Rovo MCP implementation as private beta, and Keycloak's ID-JAG support is experimental and limited to accepting assertions. Adoption status checked November 10, 2026. See the MCP Enterprise-Managed Authorization implementation table for current support.
• Token Exchange (RFC 8693) is the mechanism at each boundary: trading one token for a narrower one bound to a different audience. It is the part that makes per-task scoping possible at all. Token Exchange alone can be enough to grant agents tokens inside a single trust domain (i.e. everything that uses your IdP as the authorization server). However, most of the value for agent connectivity comes from integrating across trust domains to applications you federated with your IdP (e.g. over SAML or OIDC) which requires ID-JAG.

How Cyera Identity Supports EMA and ID-JAG Token Exchange

Cyera Identity AAM operates at the broker layer of the token exchange, between the client and the IdP. AAM evaluates the agent's intent against your access policy, then initiates the exchange. The IdP applies its own policy on top. Two independent decisions, both recorded.

1. The user authenticates to the enterprise IdP once, through normal SSO.
2. The agent invokes a tool through Cyera Identity AAM.
3. AAM reads what the agent is trying to do and evaluates it against policy: allow, deny, or step up for approval. This happens before any token is requested.
4. On allow, AAM exchanges the identity assertion at the IdP for an audience-bound ID-JAG, and requests only the scopes the evaluated action needs. The resource authorization server validates it and issues a short-lived access token.
5. The agent can now invoke tools and AAM brokers the access with that downscoped token, which is not reusable for the next one.

Policy is evaluated before the token is requested, so the credential that gets minted can only ever cover what policy already allowed. Step three is the one people skim past, and it decides everything after it.

The result is access scoped to the task, not to the integration. When a person authorizes an app, they are granting whatever that integration might need across every future time they use it. That is the right shape for a tool you operate yourself. An agent asked to triage one project's tickets gets read access to that project, for that session, and nothing else.

One audit record per decision: which agent, acting for whom, asking to do what, what policy said back, which scopes it got, and when they expired. You are not reconstructing that across four vendors' logs. The per-server consent prompt disappears for the same reason: an agent working across dozens of servers cannot stop and wait for a person to read a scope list at every one of them.

Side by side, with the human case still doing its own job well:

Do You Need a Single Security Solution for All AI Agents?

A fair objection at this point is that routing every agent request through a broker creates a chokepoint. It does, and the honest answer is that you will not get a single one, so you should stop designing for it.

Large enterprises will find it increasingly more difficult to secure their AI footprint through one single gateway. Agents show up inside SaaS platforms you do not control, in internal services your teams build, on developer endpoints, and embedded in vendor products you bought for other reasons. Those deployments have genuinely different enforcement requirements. You will run multiple MCP gateways. You will connect multiple IdPs. You will own endpoint controls alongside them. That is not a transitional state, it is the end state.

What you can centralize is the identity control plane, and that is the part that actually determines whether you can govern any of it. Enforcement points can be plural. The assertion of who is acting, on whose behalf, against which resource, and the record of what policy decided, cannot be plural without becoming useless.

Which is exactly why the layer underneath has to be standard. If each solution has its own proprietary way, you have bought four products and four disconnected policy models, and you are back to reconstructing an agent's actions across four sets of logs during an incident. If they all speak EMA and ID-JAG, the enforcement points differ while identity, audience binding, and audit stay consistent across all of them.

EMA and ID-JAG are converging into the accepted answer across IdP vendors, MCP server vendors, and gateway vendors at the same time. That convergence is the reason to build your authorization infrastructure against these specs now, while the vendor list is still forming and your choices are still cheap.

You will own a diverse security infrastructure implementation. You should maintain one identity control plane.

This is also where the Cyera acquisition of Oasis Security matters. Cyera Identity connects identity governance with Cyera's data intelligence layer and Agent Guardian solution, so the same control plane that decides which agent may act can also see into what the agent is “thinking” as well as which data its actions touch. Governing agents, identities and data together is what lets you answer "was this agent allowed to reach that data?" from one record instead of three.

How to Enable EMA and ID-JAG for AI Agent Access

You cannot enable this alone. It is a dependency on your IdP vendor and on every MCP server vendor you touch, which makes it a procurement question this quarter rather than an architecture question next year.

• Your IdP has to be able to exchange tokens as well as issue standard identity assertions that Cyera Identity AAM can exchange for scoped access tokens. If it does not support Token Exchange you cannot downscope access without human consent, and if it does not support ID-JAG issuance you cannot broker access across trust domains.
• Your MCP servers have to validate those tokens on incoming HTTP requests and enforce fine-grained permissions from them. If a server cannot accept the JWT bearer grant, it will keep falling back to its own consent flow.

Support is real, but it is uneven and it changes month to month. As of November 10, 2026, the MCP project's implementation table lists Okta, Ping Identity (PingFederate 13.1 and later), Descope, and several open-source servers as available, Auth0, Scalekit, and WorkOS as early access, and Keycloak as experimental. Verify current support against the vendor documentation directly, starting with the MCP implementation table, Okta, Atlassian, Keycloak, and Datadog.

Three questions worth putting to each vendor in writing:

1. Does your authorization server accept the ID-JAG assertion under the JWT bearer grant, today, in GA?
2. What scope granularity can you enforce from that assertion? Server-wide, or per-resource?
3. What is your target date for the EMA profile if it is not shipped?

The second question is where answers currently vary most, because fine-grained scope models are the least settled part of the ecosystem. We expect scope granularity to trend toward per-resource over the next year.

One more thing, stated carefully. Where a server does not yet support EMA, our position is that the policy model does not change. AAM still evaluates intent and mints scoped, short-lived access through whatever mechanisms that server does support. That holds in our testing. Holding up in our testing is not the same as holding up in your estate, against the internal MCP servers somebody stood up over a weekend. We would rather you validate that in your own environment than take our word for it. Either way, the protocol upgrade improves the credential. It does not introduce the governance.

Cyera Identity and the OpenID Foundation/Gartner MCP Security Interoperability Event

The OpenID Foundation's Artificial Intelligence Identity Management Community Group is running an MCP Security Interoperability event with Gartner, to find out whether any of these implementations actually work across vendors. Each participant commits to a role: MCP client, OpenID provider, OAuth authorization server, MCP gateway, or MCP server. Standards in scope are OAuth 2.1, OAuth Client ID Metadata Document (CIMD), and Enterprise Managed Authorization built on ID-JAG and ID-chaining.

Cyera Identity is a committed participant in the gateway and broker role. We are testing this against other vendors' implementations rather than demonstrating it on our own stack, which is the only way to find out whether the interoperability story survives contact with a real estate. If you are building an IdP, a gateway, or an MCP server against these specs, we want to test against you rather than around you. Especially if you think we have put the broker in the wrong place. We would rather hear that during testing than after.

Frequently Asked Questions

What is the difference between XAA, ID-JAG, and EMA?

They describe one pattern from three vantage points. XAA (Cross-App Access) is the pattern, and also Okta's product name for it: your enterprise identity provider brokers access between applications instead of asking each user to authorize each connection. ID-JAG (Identity Assertion JWT Authorization Grant) is the IETF draft specification that implements it, a signed, short-lived, audience-bound assertion from the IdP. EMA (Enterprise-Managed Authorization) is the stable MCP extension that applies ID-JAG to MCP servers, so an admin authorizes approved clients once and users skip per-server consent screens.

How does token exchange limit an AI agent's access?

Token exchange trades one token for a narrower one bound to a different audience. In this model, the user signs in once through SSO. The agent's request is evaluated against policy first. Only on allow is the identity assertion exchanged at the IdP for an audience-bound ID-JAG, which the resource's authorization server redeems for a short-lived access token covering only the scopes that action needs. The credential is scoped to one task and expires with it, instead of a months-long refresh token that covers everything the user can reach.

Cyera Identity AAM takes this one step further by also evaluating the agent intent before executing the token exchange. This allows you to add another layer of context to your agentic access policies that connect agent, identity and data in one platform.

What does an enterprise need to support EMA and ID-JAG?

Two things outside your control, plus one inside it. Your identity provider must issue ID-JAG assertions, and every MCP server's authorization server must accept them under the JWT bearer grant. Support varies by vendor and changes often, so confirm current status in each vendor's documentation and ask in writing about GA status, scope granularity (server-wide or per-resource), and the date for the EMA profile. Inside your control is the policy layer: evaluating intent before any token is requested, so the credential that gets minted can only cover what policy already allowed.

Cyera Identity Agentic Access Management governs what AI agents can do at runtime: per action, evaluated against intent, credentials minted just in time and expired afterward. Get a live demo of Cyera Identity. We will run through your use cases, surface quick wins, and leave you with an action plan.