The agent auth wave: auth.md, ID-JAG, AAuth, CIMD, and why OAuth is finally growing up in 2026

In November 2024, "how do AI agents authenticate to services on behalf of users?" was a question with no good answer. Bearer tokens, hardcoded PATs, and copy-paste-the-API-key-into-config were the working set. Eighteen months later, there are at least five serious, well-funded, in-flight standards efforts trying to fix this. Some have shipped. Most are at IETF-draft maturity. All of them are starting to converge on a coherent shape.

This is the survey post I would have wanted to read three months ago. The map of what's happening, who's driving it, where the pieces fit, and what's still missing. I'll keep the editorializing for the last section.

The catalogue

Five threads, with the publication dates that put them on the map.

Plus the vendor implementations stitching pieces together: Auth0's Auth for MCP went GA on May 6, 2026. WorkOS AuthKit has both CIMD and now auth.md. Stytch shipped MCP-specific OAuth helpers. The standards are landing, and the providers are racing to wrap them.

I covered auth.md in depth last week and the MCP spec evolution in the auth-approaches post. This post zooms out.

The timeline that got us here

The arc is shorter than people remember. Twelve months from "no standards" to "five overlapping standards."

• May 2025. AAuth draft 00 filed at IETF (Pat White). MCP Demo Day at Cloudflare launches the first wave of remote MCP servers (Asana, Atlassian, Block, Intercom, Linear, PayPal, Sentry, Stripe, Webflow), most using DCR. Anthropic announces MCP authorization spec direction.
• June 2025 (2025-06-18). MCP spec revision separates resource server from authorization server, makes RFC 9728 Protected Resource Metadata mandatory.
• October 2025. AAuth draft 01 published. Cross App Access work intensifies. Notion's MCP endpoint ships as the cleanest DCR reference.
• November 2025 (2025-11-25). MCP spec adopts CIMD as preferred registration mechanism; demotes DCR from SHOULD to MAY. SEP-991 lands. Aaron Parecki publishes the canonical analysis.
• January 2026. Okta launches xaa.dev, a playground for Cross App Access. Stytch publishes its MCP OAuth guide.
• February 2026. Okta press cycle for XAA. Industry supporters announced: Automation Anywhere, AWS, Boomi, Box, Glean, Google Cloud, Grammarly, Miro, Salesforce, WRITER.
• April 2026. ID-JAG draft 03 published at IETF.
• May 6, 2026. Auth0 "Auth for MCP" goes GA, including CIMD support and On-Behalf-Of token exchange.
• May 25, 2026. WorkOS launches auth.md.

Twelve months, five threads, dozens of vendor announcements. The pace is faster than OAuth 2.0's standardization arc (2007-2012).

The five threads, one paragraph each

The MCP authorization spec

The most concrete output. A real specification, not a draft, with normative MUST/SHOULD/MAY language, and a deployed ecosystem of implementations to test against. It defines what an MCP server has to do to be auth-compliant: PRM discovery, OAuth 2.1 with PKCE, Resource Indicators (RFC 8707) on every token, and now CIMD as the preferred client registration mechanism. The spec was authored by Anthropic with heavy community input; the 2025-11-25 revision was a coordinated push between Anthropic, WorkOS, Okta, and the IETF OAuth working group.

Cross App Access (XAA) and ID-JAG

The enterprise-IdP-mediated story. The technical primitive is the Identity Assertion Authorization Grant (ID-JAG), an IETF draft profiling RFC 7523's JWT-based grant for agent-on-behalf-of-user scenarios. The agent's identity provider (Okta, in the reference case) mints a JWT asserting that the agent is acting for a verified user with specified scopes; the resource server validates the signature against the IdP's JWKS and issues an access token. The MCP spec just added XAA as an Enterprise-Managed Authorization extension, with the official TypeScript and Java SDKs being updated to support it. Aaron Parecki at Okta is the visible driver.

Client ID Metadata Documents (CIMD)

The simplest of the five conceptually but with the most far-reaching consequences. Instead of clients registering with each authorization server (which doesn't scale to a world where any agent might want to talk to any service), the client hosts a JSON metadata document at an HTTPS URL, and that URL is the client_id. Authorization servers fetch and validate on demand, cache per HTTP semantics, and trust the domain ownership as the identity anchor. Adopted by MCP as the preferred registration approach when no prior relationship exists. Implementations live in WorkOS AuthKit, Auth0, Authlete, and (experimentally) Keycloak.

auth.md

The newest and most opinionated of the five. A markdown file an application publishes at https://yourservice.com/auth.md telling agents how to self-register. Two flows: an "agent verified" path that uses an ID-JAG-style assertion from the agent's provider, and a "user claimed" OTP path for when no provider attestation exists. Launched May 25, 2026 by WorkOS, MIT licensed, deliberately stitched together from existing OAuth primitives (RFC 9728 + ID-JAG + OIDC backchannel logout) rather than reinventing.

AAuth (Agentic Authorization OAuth 2.1 Extension)

The outlier. Where the other four assume a confidential agent in a normal HTTP environment, AAuth (draft-rosenberg-oauth-aauth-01) targets agents in voice and messaging channels where the user can't open a browser to consent. Polling, Server-Sent Events, and WebSocket are the consent transports. Filed by Jonathan Rosenberg and Pat White; less adopted than the others, but solves a real problem the others don't (the PSTN-resident agent, the SMS-driven workflow).

What unifies them

Reading the five together, the same patterns show up in each:

1. The agent is treated as a distinct OAuth principal, not as a proxy for the user. Every effort assumes the agent has its own identity that the system can attest to, distinct from the user it's acting for. ID-JAG makes this explicit with iss (provider) and sub (user) claims. auth.md's agent-verified flow uses the same primitive. AAuth's "confidential agent client" concept is the same idea. The era of "the agent is just code running with the user's token" is ending.

2. Audience restriction is treated as load-bearing. Every spec mandates that tokens are bound to a specific resource server via RFC 8707 Resource Indicators. The threat model is explicit: in a world where an agent might call ten services in one task, a token for service A must not be replayable against service B. This was the missing piece in pre-2025 OAuth deployments.

3. Client registration is moving off the registration database. CIMD's URL-as-client_id model is the conceptual move. The deployed-OAuth assumption that every client/server pair maintains state breaks down at MCP scale (millions of short-lived agents talking to thousands of services). CIMD replaces that state with HTTP fetch + cache.

4. The trust anchor is shifting to identity providers and domain ownership. Where pre-2025 OAuth often trusted a manually-issued client_secret, the 2026 approaches trust either an enterprise IdP's signature (XAA) or a publicly-resolvable domain's TLS (CIMD, auth.md). Both reduce static secrets in the loop.

5. Discovery is becoming a first-class concern. RFC 9728 Protected Resource Metadata is the discovery layer in MCP, auth.md, and most vendor products. Discovery-first auth is what lets an agent walk up to a service it's never seen and figure out how to authenticate.

This is what "OAuth growing up" looks like in practice. Not a new auth protocol; a maturation of the existing one to handle a class of client (autonomous agents) that didn't exist when OAuth 2.0 was designed.

What is still missing

The standards work has been impressive. The gaps are still real.

Client-side credential lifecycle

Every spec assumes the bearer token, once issued, lives somewhere safely. None of them specify where. The verified flow returns an access_token; the agent code then has to:

• Store it somewhere encrypted (because the agent's process is hostile, as the agent-security writeups have made clear).
• Refresh it when it expires (which happens hourly for most modern issuers, e.g. Notion's 1-hour tokens with refresh-token rotation).
• Re-mint the upstream assertion (ID-JAG) when the verified flow's no-refresh-tokens design requires it.
• Inject it on outbound API calls without ever exposing it to the agent's environment, stack traces, or subprocess inheritance.

This is what agent-side credential brokers (authsome, Agent Vault, Clawvisor, OneCLI, others) handle today. None of the five standards efforts address this layer; they all assume someone else solves it. Disclosure: I work on authsome; the broader category is in the agent credential brokers post.

Multi-account per user

A single human user has multiple identities on the same provider (personal GitHub + work GitHub; personal Google + work Google). The spec story for "this credential is the work one and this one is the personal one and the agent should pick per task" doesn't exist. CIMD has a single client_id per agent. ID-JAG's sub is one user. auth.md's flow registers one credential per (user, agent) pair.

The workarounds today are all agent-side: a broker that namespaces credentials by "connection" (work vs personal) and lets the agent pick per call. This is structural; no spec change is plausible in the near term.

Cross-provider session

The user authorizes the agent against three services (GitHub, Linear, Slack). The agent's workflow needs to coordinate calls across all three with consistent identity. Today, the agent holds three independent tokens. There is no "session" concept that spans providers. AAuth's polling/SSE consent model is the closest thing to addressing this, and it's an outlier.

Revocation propagation

OIDC Backchannel Logout exists. Few authorization servers actually push logout tokens on user-initiated revocation. Many MCP servers don't subscribe to them anyway. The result: a user revokes an agent's access in their IdP dashboard, the agent's token works for another 59 minutes until it organically expires. The plumbing is specified; the wires are mostly not connected.

Audit, end-to-end

Every spec talks about audit events. Few specify the schema, the storage, or the cross-system correlation. The user wants to know "what did this agent do across all my services?" That's a per-provider query today, with no standard for joining the logs.

What this means

Three implications worth naming.

For services exposing agent-callable APIs: The cost of doing OAuth right has dropped. The Cloudflare OAuth Provider Library, Auth0 Auth for MCP, WorkOS AuthKit, and Stytch's MCP helpers all handle the spec compliance, including the CIMD pieces, so the team's work shifts to scope design and downstream auth. The expectation in 2026 is that any new agent-exposed API ships with PRM discovery and OAuth 2.1; the "internal-only, paste-an-API-key" pattern is increasingly out of step.

For agent builders: The verified-flow story (ID-JAG, auth.md) is the future and isn't widely deployable today because most agent providers haven't shipped ID-JAG endpoints yet. Plan for the user-claimed OTP path for the next 12 months, with the verified flow as a forward-compatibility hook. When OpenAI, Anthropic, or Cursor do ship ID-JAG, the integration is small (about 30 lines, per the agent-side pseudo-code in the auth.md post).

For security teams: The "agent is a distinct principal" framing is the load-bearing change. If your audit logs still attribute agent actions to the user, you're going to lose the ability to investigate the agent-specific blast radius (what the agent did vs what the user did) right when investigation is most needed. Update the schema now.

What 2027 probably looks like

Three predictions I would defend (and three I'd be cautious about).

Likely:

• CIMD adoption catches up to vendor support. The authorization servers have shipped; MCP clients are slower. By mid-2027, most actively-maintained MCP clients support CIMD natively.
• At least one major agent provider ships ID-JAG. Cursor is the lowest-friction candidate (smaller surface area than OpenAI or Anthropic). Anthropic is the highest-impact. When the first one ships, the rest follow within 6 months.
• auth.md hits its chicken-and-egg moment one way or the other. Either three or four high-traffic services publish working auth.md files (current public ones do not yet), or the spec quietly stalls. The Cloudflare/Firecrawl "launch partnership" needs to produce actual implementations to keep momentum.

Less likely but worth watching:

• AAuth becoming widely deployed. The use case (voice/SMS-resident agents) is real but smaller than the MCP-server class, and the spec is the least adopted of the five today.
• A consolidated "agent identity" standard that spans MCP, A2A, and direct LLM API calls. Each ecosystem is currently building its own version.
• A consumer-grade "agent permissions UI" emerging at the OS level (Apple, Microsoft) that abstracts these flows for users. Possible, but the OS vendors have been quieter on agent auth than the standards bodies.

The shorter version

In one year, OAuth's "agents are just clients" assumption was replaced by "agents are a class of principal that needs its own discovery, registration, attestation, and revocation primitives." Five separate efforts (MCP authorization spec, Cross App Access / ID-JAG, CIMD, auth.md, AAuth) are converging on the shape. The shape is coherent: audience-restricted tokens, identity-provider-mediated assertions, URL-as-identity client registration, and discovery-first server metadata.

What's missing is the layer below the bearer token: where does the credential live once issued, how does the agent use it without leaking it, how do you handle the same human's multiple identities. That layer is the agent-side broker pattern, and it's where the existing OAuth standards work hands off to a different ecosystem.

The full picture for an agent in 2027 looks like: discover the service via auth.md or PRM, register via CIMD, get an audience-restricted token via XAA or auth.md's verified flow, stash it in a vault on the user's machine, inject it on outbound calls without exposing it to the agent process, audit every use. Today, the first three of those are mostly available; the last three are still rough.

If you remember one thing from this post: this is what "OAuth growing up" looks like in real time. Not new auth, mature auth.

Priyansh Khodiyar

Maintainer

Works on authsome and the agentr.dev tooling.