On June 18, 2026, the Model Context Protocol team marked the Enterprise-Managed Authorization (EMA) extension as stable, and Anthropic shipped it across Claude, Claude Code, and Cowork the same day. It is being read as zero-touch OAuth for people typing into Claude Code. The bigger story - the one almost no one is telling - is what it unlocks for autonomous agents, and the identity they're finally allowed to have.
I want to be clear up front: this is a genuinely good release, and we support it at NewCore. But read the coverage - Anthropic's, the MCP team's, Okta's, the early adopters' - and you'll notice it all tells the same story. A person logs into Claude. Their connectors light up. No consent screens. Zero-touch. It's a story about humans and the friction we hate.
While that story is correct, it focuses on the smaller half of what EMA does. The half that will matter more in two years is the half nobody is putting on the marquee: EMA is the cleanest on-ramp we've gotten yet for giving autonomous agents a real, governed identity. Let me explain why, because the mechanism is genuinely non-obvious.
A 60-second recap of EMA
EMA makes the organization's identity provider the authoritative decision-maker for MCP access. An admin enables a server once; users inherit it through the groups and roles they already have; the connector is just there on first login.
Under the hood, the client doesn't redirect you through a per-server consent screen anymore. During SSO it gets an Identity Assertion JWT Authorization Grant - an ID-JAG - from the IdP via OAuth token exchange, then presents that grant to the MCP server's authorization server in exchange for an access token. The IdP evaluates policy (group, role, conditional access) before it mints the grant, and it can narrow the scopes on the way through. Revocation and audit live in one place, and because checking with the IdP is cheap, admins can run short token lifetimes so deprovisioned access dies in minutes rather than lingering on a stale token.
ID-JAG is the same primitive Okta brands as Cross-App Access (XAA); it's a profile of RFC 7523 built on RFC 8693 token exchange, authored at the IETF by people from Okta and Ping Identity. Okta is the first IdP; Anthropic and VS Code are early clients; Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase are among the first servers, with Slack close behind. On the IdP side, Okta shipped first - and it won't be alone. NewCore implements the same ID-JAG issuance, plus the agent-identity models the rest of this post is about. That's the table stakes. Now the part I actually care about.
Why everyone is telling the human story
The entire market has converged on one framing of agents: an agent acts on behalf of a user. Okta's Cross-App Access material is built around that use case. Glean put it plainly - their agents act strictly on behalf of the user, with no extra privileges. Descope, in an otherwise excellent explainer, goes further and describes an agent having its own identity, untied to the requesting user, as a visibility problem to be avoided. Even the IETF's own ID-JAG draft, which includes a dedicated "AI Agent using External Tools" use case, models the agent as an OAuth client acting on behalf of a human subject. Foreshadowing the issue to come, Descope goes further to raise the issue of an agent having its own identity, untied to the requesting user, as a visibility problem to be avoided.
None of that is wrong. For an interactive agent - me asking Claude to pull a launch summary from Asana and Figma - borrowing my identity is exactly right. The agent should see what I can see and nothing more, and the log should say I'm the one who asked.
But the framing above makes two critical assumptions. First, that there is always a human in the session. Second, that the human's identity is the right one to act under. For a long-running agent on Bedrock, an automation sitting on a Mac mini, or an agent on its own EC2 box grinding through a multi-hour task at 3 a.m., both of those assumptions break. And the moment they break, the human-anchored model stops describing reality.
The two things EMA actually changes for agents
First - no consent page means an agent can keep going. Before EMA, every new MCP server an agent wanted to touch meant an interactive OAuth consent redirect - a browser, a human, a click. That is fatal to autonomy. An agent shouldn't pause a pipeline at 3 a.m. to wait for someone to approve a consent screen. EMA deletes that redirect entirely: the spec is explicit that the client must not send the user to the resource server's authorization endpoint, and that no fresh user consent is collected at the exchange step. Within the policy the IdP has already approved, an agent can acquire access to additional MCP servers mid-task, with no human in the loop. Autonomy stops being consent-bounded and becomes policy-bounded. That's a categorical change, not a convenience. But it does reinforce the need for governance.
Second - (critical) the subject of the grant does not have to be a human. Here's the part that has significant implications, especially as we see the rise of the autonomous agents. An ID-JAG's sub claim is just an identifier the IdP is willing to vouch for and the downstream server can resolve. There is nothing in the token format that requires it to be a human. Today's EMA text and the IETF's canonical agent example both still put a human in sub and treat the agent as the client - but the same machinery lets the IdP mint a grant whose subject is the agent itself. A real, first-class, governed identity. A synthetic employee.
That single degree of freedom is the whole ballgame. It means the same protocol the industry is using to let agents borrow a human's identity can instead carry the agent's own identity - across trust domains, not just inside one tenant. Once you see it, you can't unsee it.
Three ways an agent can hold identity
It's worth being precise, because which of these you pick is an architecture decision with real consequences.
1. Agent as client, human as subject (delegated / on-behalf-of). sub is the human; client_id is the client the agent runs within. This is what EMA and XAA do today, and it's the right call for interactive, human-triggered work. The limits: the agent inherits the human's entire blast radius, there's no first-class record of the agent as a principal, and it simply cannot represent an agent with no human in session.
{
"iss": "https://example.auth.newcore.io/",
"sub": "U019488227",
"email": "user@example.com",
"aud": "https://auth.chat.example/",
"client_id": "f53f191f9311af35",
"scope": "chat.read chat.history"
}2. Agent as a named actor on behalf of a human (the act claim). sub is the human; act is the agent. This is RFC 8693 actor semantics, and it's the elegant middle path: the token records who authorized this and who actually did it. The ID-JAG spec defines the act claim - but explicitly reserves normative processing of actor tokens for a future profile, and warns about the delegation risk of letting a client pair a real subject with a weaker actor to overstate authority. So this is directionally supported, not yet standardized. It's the model I most want the standards bodies to finish, because accountable delegation is exactly what auditors will ask for.
{
"iss": "https://example.auth.newcore.io/",
"sub": "U019488227",
"email": "user@example.com",
"aud": "https://auth.chat.example/",
"client_id": "f53f191f9311af35",
"act": {
"sub": "B007149387",
"email": "users_bot@example.com"
},
"scope": "chat.read chat.history"
}3. Agent as its own subject (the synthetic employee). sub is the agent. The agent is a principal in the directory with its own lifecycle, credentials, scopes, and audit trail. This is what a genuinely autonomous agent needs. Microsoft already ships a version of this within a single tenant - Entra Agent ID's "autonomous (non-OBO)" mode, where the agent acts with its own identity and permissions, complete with sponsors, blueprints, and conditional access. Palo Alto's Idira (now built on CyberArk) governs the same thing as a non-human identity. What none of them do yet is carry that identity across trust domains - and that's precisely the layer EMA and ID-JAG operate at. It's also exactly where we built NewCore: minting ID-JAGs whose subject is the agent itself, resolvable across trust domains, with the agent's own lifecycle, credentials, and policy behind it. The synthetic employee isn't a slide for us - it's an identity type in the directory.
{
"iss": "https://example.auth.newcore.io/",
"sub": "B007149387",
"email": "bernard.lowe@example.com",
"aud": "https://auth.chat.example/",
"client_id": "f53f191f9311af35",
"scope": "chat.read chat.history"
}There's an honest trade-off in model 3, and it's the one I get asked about most: giving an agent its own subject identity means it resolves to its own principal at each resource server - its own account, its own seat, possibly its own license - which costs more than letting it ride on a human's seat. My answer is that for anything autonomous, long-running, or high-stakes, that cost is a bargain. You're buying real attribution, independent least-privilege, independent revocation, and an audit log that doesn't lie to you about who acted. A synthetic employee that costs a seat but can be reasoned about beats a free agent hiding inside a human's grant every single time.
NewCore treats all three as first-class: you choose, per agent, whether it acts as a delegated client, a named actor on a human's behalf, or its own principal - governed from one policy plane
What "agent identity done right" looks like on EMA's rails
The marketing pieces skip the parts of the spec that make this actually safe. They're the parts I find most encouraging:
Confidential clients only. ID-JAG is meant for clients that can hold a real credential and authenticate; public clients are told to fall back to interactive consent. Far from a limitation, this fits a governed autonomous agent - one running on dedicated infrastructure with a managed credential - and rules out the hand-wavy "agent as an anonymous public app."
Sender-constrained tokens. The grant and the resulting access token can be bound to a key the agent holds (DPoP / cnf thumbprint), so a stolen token is dead weight without the private key. For an agent sitting on its own box, that's exactly the property you want.
Short-lived grants, central revocation. ID-JAGs are minted with lifetimes measured in minutes and re-requested as needed. When you kill the agent's identity at the IdP, its access across every connected server expires almost immediately.
Step-up for sensitive actions. The IdP can demand a higher assurance bar before issuing a grant. Microsoft's own example - an agent reaching for payroll data at 3 a.m. triggering a human-in-the-loop challenge - is this exact mechanism. Autonomy and a hard stop on the dangerous stuff are not mutually exclusive.
Every one of those five is a bar we hold ourselves to at NewCore - confidential-client credentials, DPoP-bound grants, per-task RAR scoping, minute-scale revocation, step-up on sensitive actions - because a platform for synthetic employees that skips any of them isn't safe to run.
This is what I mean by identity done right: the autonomy of a service account with the governance, scoping, and revocability we'd demand of a human. The old way - a static API key wired into an agent forever - gave you the autonomy and none of the governance. EMA's machinery finally lets us have both.
The scale argument now comes with receipts
We have seen numerous projections that enterprises will run 10x to 100x more agent identities than human ones. Palo Alto and CyberArk's 2026 identity report puts the machine-and-AI-to-human ratio at about 109 to 1; RSA puts non-human identities ahead by 17 to 1 today and climbing. Gartner forecasts that AI agents will outnumber human sellers 10:1 by 2028 and that the average Fortune 500 company will have more than 150,000 AI agents. Microsoft's latest Digital Defense reporting flagged a roughly 300% jump in incidents tied to non-human identity abuse. And in one survey, fewer than one in five security teams said they were highly confident their current IAM could manage agent identities at all. That confidence gap is the whole reason NewCore exists: an identity system that manages agents with the same rigor it manages people, not employee tooling with agents bolted on.
Read those numbers together and the point makes itself. The blast radius of getting agent identity wrong is enormous. The volume of agent-driven identity events already dwarfs the human kind, and most organizations are walking into it with tooling built for employees. This is not a future problem. It is a now problem that gets worse every quarter.
Where this leaves us
EMA did the right thing: it moved authorization out of a thousand individual consent screens and into a governed, policy-driven identity layer. That's a real milestone and we're glad to support it.
But the conversation has stopped at humans, and the protocol is capable of so much more. The identity platform for the agentic era has to treat all three models as first-class - human, agent-as-actor, and agent-as-its-own-subject - and it has to do it across trust domains, with confidential-client credentials, sender-constrained and task-scoped tokens, real-time inventory of every agent, and revocation that keeps up with machine speed. The vendors who've nailed agent-as-subject have done it inside their own tenant; the vendors who've nailed cross-domain authorization have done it for humans. The interesting, hard, valuable work is in the union of the two.
That union is what NewCore is built for - an identity platform built in the agentic era, for the agentic era, governing humans and agents in the same plane from the start. EMA is the on-ramp. The destination is a world where your agents don't borrow someone else's identity to get their work done. They have their own - and you can see exactly what each one did.