ID-JAG, XAA, and MCP Auth: A Plain-English Guide to AI Agent Authentication

Three emerging standards now decide whether an AI agent is allowed to touch your data. Here is what each one does, in plain language, and where its job ends.

An AI agent inside your company can now log into applications, read data, and complete tasks for an employee. Before it touches anything, AI agent authentication has to answer one question: is this agent allowed to do that? For most of the past two years, that question was answered badly. Each application ran its own “Allow access?” prompt, or the agent authenticated with a static API key pasted into a config file, and IT rarely saw either. The result was standing privilege no one tracked and consent no one reviewed.

Three emerging standards fix that by moving AI agent authentication out of individual apps and into the identity system your company already runs: ID-JAG, Cross App Access (XAA), and MCP auth. This guide explains each one, how they fit together, and the part of the problem they do not solve.

Why AI agent authentication became a governance problem

AI agent authentication broke because it was never designed for software that acts on its own. When an employee connects an AI tool to an app, the identity provider can confirm the human, but often cannot see what the agent is actually requesting. A prompt reading “Allow access to your files” hides whether that means one document or the entire drive.

Two habits made it worse. Agents authenticated with static API keys, long-lived secrets sitting in code, and employees clicked through per-app consent screens their admin never saw. Okta describes the outcome plainly: most agent connections still rely on high-risk static API keys and consent screens invisible to the IT admin, leaving permanent standing privileges and security gaps.

The governance problem is not that agents act. It is that no central owner could see or revoke what an agent was allowed to reach. ID-JAG, XAA, and MCP auth each close one part of that gap.

ID-JAG: the signed permission note

ID-JAG is a digitally signed note from your identity provider that states an agent works for a specific person and is approved for a specific app. Its full name is the Identity Assertion JWT Authorization Grant, and it is an active Internet-Draft in the IETF's OAuth Working Group, intended for the Standards Track and not yet a finalized RFC.

The everyday version is a hall pass signed by the principal. A teacher does not phone the front office every time a student walks by; they check the signature and wave the student through. ID-JAG works the same way. Instead of every application running its own consent prompt, your identity provider, Okta or Microsoft Entra for example, issues a signed assertion, and the downstream app trusts that assertion rather than asking again.

Mechanically, ID-JAG lets an application exchange an identity assertion for an access token to a third-party API, coordinating through an identity provider that the target already trusts for single sign-on. For a security team, the value is concentration: because the identity provider issues the note, it can also revoke it in one place.

In one sentence: ID-JAG lets your identity provider vouch for an agent, so every app does not need its own consent popup, and IT can revoke access centrally.

Cross App Access (XAA): the note put to work

Cross App Access, or XAA, is how ID-JAG actually gets used between real products. An admin enables an agent or app connection once, employees and their agents inherit access from the roles they already hold, and every connection can be seen, audited, and switched off centrally. XAA is an open, vendor-neutral protocol that Okta introduced in June 2025 and now leads, built as an extension of OAuth.

The analogy is an office keycard system. Rather than every meeting room keeping its own guest list, the front desk issues one badge that opens exactly the rooms you are cleared for, and security can cancel it instantly.

XAA has moved from proposal to early infrastructure. Okta's June 2026 expansion listed more than 25 early adopters, including Anthropic, Slack, Zoom, and Atlassian, spanning the AI tools that request data, the apps that hold it, and the platforms that route agent traffic. The IETF draft behind ID-JAG names this pattern directly: it refers to the approach informally as Cross-App Access.

In one sentence: XAA connects your AI tools to your apps centrally, with one audit trail and instant revocation, instead of per-user popups.

MCP auth: the permission check on the AI's plug

MCP auth is the authorization layer that checks an AI assistant is allowed to use a tool before it connects. MCP, the Model Context Protocol, is an open standard from Anthropic that its own documentation compares to a USB-C port for AI applications: a standard way for assistants like Claude to plug into tools and data such as a calendar, a database, or a code repository. MCP auth is the check on that port.

The check is built on OAuth 2.1, the same family of authorization technology behind consumer “sign in with” flows. In the protocol, a protected MCP server acts as an OAuth 2.1 resource server and the AI client acts as an OAuth 2.1 client, so no protected tool runs without a valid, scoped token.

The specification gained an enterprise-managed authorization extension in November 2025. Instead of each employee clicking “allow” per connector, the company's identity provider grants access for whole teams at once, using ID-JAG notes. Anthropic shipped the first implementation of that extension on 18 June 2026, in beta for Claude Team and Enterprise plans, with Okta as the first identity provider. Okta's Director of Identity Standards, Aaron Parecki, said embedding Cross App Access into MCP as the Enterprise-Managed Authorization extension would “turn identity into a centralized governance plane.”

The analogy is a hotel key system. The USB-style plug (MCP) is the door-lock hardware, standard on every door. MCP auth is the check that your key card actually opens that room. Enterprise-managed authorization is the front desk programming every staff card at once, rather than each person asking the manager door by door.

In one sentence: MCP is how AI assistants connect to tools; MCP auth is the permission check on that connection, now plugged into the identity rules you already run.

How ID-JAG, XAA, and MCP auth fit together

The three standards are one system seen from three angles: the plug, the proof, and the rollout. MCP is the standard connection between an AI and a tool. MCP auth is the rule that the plug only works with proof of permission. ID-JAG is the format of that proof, a signed note from your identity provider. XAA is the real-world rollout, the products and identity providers actually exchanging those notes.

Put in sequence: an agent plugs in through MCP, MCP auth demands proof, the identity provider issues an ID-JAG note, and XAA is the ecosystem making that exchange work day to day.

The three standards at a glance:

What AI agent authentication does not cover

Identity answers whether an agent can connect. It does not govern what the agent does once it is inside. ID-JAG, XAA, and MCP auth make the front door auditable: the right agent, acting for the right person, reaching only approved apps, with access an admin can revoke centrally. That is a large improvement over static keys and invisible consent. It is also where their job ends.

An authorized agent can still take a wrong action inside an approved app: combine data it should not have joined, trigger an operation at the wrong scale, or drift from the task it was given. Watching for that at runtime is governance, not authentication.

This is the layer OpenBox, an AI agent governance platform, is built for. Once an agent is connected, it scores the agent's trust, applies policy to each operation, and returns one of four governance decisions, ALLOW, REQUIRE_APPROVAL, BLOCK, or HALT, while writing a tamper-evident record of what happened. Identity decides who gets in; AI agent authentication is only the first control. Governance decides what an agent can do once inside, and enterprises running agents in production need both. For the full picture, see OpenBox's complete guide to AI agent governance for enterprise teams.

Frequently asked questions

What is the difference between ID-JAG and XAA?

ID-JAG is the format of the permission note: a signed assertion from your identity provider. XAA (Cross App Access) is the open protocol that puts that note to work across real products, letting admins enable an agent connection once and audit or revoke it centrally. ID-JAG is the proof; XAA is the rollout.

Is MCP auth the same as MCP?

No. MCP (Model Context Protocol) is the standard connection that lets an AI assistant plug into tools and data. MCP auth is the authorization check on that connection, built on OAuth 2.1, that requires proof an agent is allowed to use a tool before it connects. One is the plug; the other is the permission check.

Does enterprise-managed authorization take control away from employees?

Control shifts to the organization's IT and security team, not to the AI. Administrators decide which connectors each group can use through the identity provider, and users receive exactly that access automatically on first login. It removes per-user consent prompts; it does not grant an agent access the organization has not approved.

Do these standards require Okta?

No. ID-JAG is a vendor-neutral IETF draft, and MCP's enterprise-managed authorization is an open extension any identity provider can implement. Okta was the first supported identity provider and leads XAA, but Anthropic's documentation states support for additional identity providers is coming.

When can enterprises use this?

Anthropic shipped enterprise-managed authorization on 18 June 2026 in beta for Claude Team and Enterprise plans, with Okta as the first identity provider. Okta has said its Workforce customers can reach supported XAA applications through the Okta Integration Network starting August 2026. Availability arrives in stages.

Sources

IETF OAuth Working Group. Identity Assertion JWT Authorization Grant (draft-ietf-oauth-identity-assertion-authz-grant). datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/. Accessed 8 July 2026.

Okta. “Okta advances the industry standard for secure AI agent connections with expanding Cross App Access ecosystem.” 23 June 2026. okta.com/newsroom/press-releases/okta-announces-cross-app-access-partners/. Accessed 8 July 2026.

Anthropic (Claude). “Centrally manage authorization for MCP connectors.” 18 June 2026. claude.com/blog/enterprise-managed-auth. Accessed 8 July 2026.

Model Context Protocol. “What is the Model Context Protocol (MCP)?” modelcontextprotocol.io/docs/getting-started/intro. Accessed 8 July 2026.

Model Context Protocol. “Authorization” specification. modelcontextprotocol.io/specification/draft/basic/authorization. Accessed 8 July 2026.

Okta. “Okta introduces Cross App Access to help secure AI agents in the enterprise.” 23 June 2025. okta.com/newsroom/press-releases/okta-introduces-cross-app-access-to-help-secure-ai-agents-in-the/. Accessed 8 July 2026.

Okta. “Cross App Access extends MCP to bring enterprise-grade security to AI agent interactions.” 25 November 2025. okta.com/newsroom/articles/cross-app-access-extends-mcp-to-bring-enterprise-grade-security-to-ai-agents/. Accessed 8 July 2026.

OpenBox (docs.openbox.ai). Governance Decisions and Attestation & Cryptographic Proof. docs.openbox.ai/llms.txt. Accessed 8 July 2026.