For about a year, the honest answer to "how does my agent log into an MCP server" was: it shows you a consent screen, and you click allow. That flow — OAuth 2.1 with a per-server authorization prompt — was the right call for the world MCP was born into, where the canonical user was one developer wiring up one server on a laptop. It composes terribly for anyone else. On 2026-06-18 the project marked a fix stable: Enterprise-Managed Authorization, SEP-990, a way for the organization to grant an agent access to a server instead of asking each employee to.

The pitch writes itself as "fewer clicks." That framing undersells it, and it hides the one idea worth taking away.

Walk the standard flow at enterprise scale. A company has 500 employees and, say, 30 internal MCP servers — issue trackers, doc stores, deploy tooling, a data warehouse. Under per-server OAuth that's 15,000 consent interactions, each one a human squinting at a scope list they cannot evaluate and clicking the only button that lets them get on with their day. The security team, meanwhile, has no central control and no audit trail; work and personal accounts blur together because nothing forces a corporate identity. The blog post naming the problem lists exactly these three failures: onboarding burden, no consistent policy, and account mixing.

The consent screen was never really about the user. It was a stand-in for a trust relationship that didn't exist yet — so MCP asked the least-qualified party in the room to approve it, one click at a time.

That's the tell. A consent prompt is what you show when the client and the resource are strangers and someone has to vouch for the connection in the moment. In a consumer setting, the only party present is the user, so the user vouches. In an enterprise, there is a better-informed party who was there the whole time — the identity provider — and a person whose entire job is deciding who may touch what: the IdP admin. Per-server consent ignored both.

What ID-JAG actually moves#

Enterprise-Managed Authorization keeps the OAuth 2.1 plumbing and swaps out the approval step. The mechanism is the Identity Assertion JWT Authorization Grant (ID-JAG). During single sign-on, the client obtains a signed assertion from the IdP that cryptographically represents this user asking on behalf of this app. It presents that assertion to the MCP server's authorization server using a JWT-bearer–style exchange, and gets back an ordinary access token. No redirect to a consent page, no account picker. Okta ships the first implementation under the name Cross App Access (XAA); ID-JAG is the underlying grant being standardized at the IETF, so you'll meet both names — "XAA" in the vendor docs, "ID-JAG" in the spec.

The result the maintainers describe is "authorize once, inherit everywhere": an admin enables a server one time, and users get access "scoped to the groups and roles they already have." Launch support is real, not a paper spec — clients include Anthropic's Claude and Microsoft's VS Code; servers include Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase, with Slack integrating.

Why this is the shape of agent auth generally#

Strip away MCP specifics and you're left with a pattern that keeps recurring. Human-in-the-loop consent is a fine safety mechanism for a single decision. It falls apart the instant the decisions multiply — and agents multiply decisions for a living. An agent that touches thirty tools across a hundred-step run cannot pause for thirty consent screens, and a human clicking through them isn't providing oversight; they're providing rubber stamps.

The industry's answer, visible here and in how agents are being issued real workload identities, is to move the human up a level: from approving each connection to setting policy once, in the place where policy already lives. ID-JAG relocates the authorization decision from the end user — who cannot reason about OAuth scopes and shouldn't have to — to the IdP admin console, which already knows the org chart, the groups, and the audit requirements. The consent screen doesn't get faster. It gets deleted, because the decision it was pretending to capture was made somewhere better.

That's the non-obvious part. "Zero-touch" sounds like a convenience feature. It's actually an admission: at agent scale, per-action human approval was never the control it looked like, and the fix is to trust the identity provider to vouch cryptographically for who the user is — then let policy, not a tired click, decide what the agent may do.

There's a caveat worth keeping. Deleting the consent screen concentrates power in the IdP: whoever administers Okta now silently governs which agents reach which corporate data, so the admin console becomes the thing you audit, and the ID-JAG issuance path becomes the thing you harden. That's a better place to spend your paranoia than 15,000 consent clicks — but it is a place, and it's new.