Auth is the last mile of agent autonomy

The Access layer in Deep Scan (Layer 3) grades every auth surface an agent might negotiate. None is wrong; each solves part of the problem and leaves a human standing in for the rest. Walk them in order and the shape of the gap gets clear.

• Static API keys. Universal, but the key represents the account not the user; scope is all-or-nothing; revoking one kills every agent using it; a leaked key is indistinguishable from a prompt-injection payload. We test: developer-portal, agent-auth-docs.
• OAuth 2.0 / 2.1 with PKCE. Mature, scoped, audience-restrictable (RFC 8707) - but it assumes a browser and a consent screen, and the consent screen is the wall most autonomous agents can’t cross. We test: oauth-support, oauth-protected-resource (RFC 9728), scoped-permissions, mcp-pkce-s256, and auth-flow-simulation (a deep check that runs the full OAuth dance against live endpoints).
• Client credentials (M2M). Short-lived, scoped, audit-friendly - but the token represents the service, not the user. Wrong primitive the moment an agent acts on user data.
• Token exchange (RFC 8693). The right primitive for scope reduction: start with a user-delegated token, exchange it for a narrower, task-scoped token before the agent calls a tool, and record the chain in nested act claims. It is also where multi-hop delegation breaks. When Agent A spawns B which calls C which touches Service D, the spec is explicit that those nested prior-actor claims are informational only - downstream services decide on the top-level actor alone. Every hop has to round-trip the authorization server to re-mint a token, so the whole workflow is coupled to that server’s availability, and a single compromised token inherits everything downstream. The IETF draft on attenuating delegation chains is the direction here: every hop should hold equal or lesser authority than the one before it.
• Client registration: DCR, now CIMD. Dynamic Client Registration (RFC 7591) removed the human-creates-the-app step, but an open /register is a trust-bootstrap problem, and production deployments gate it with initial-access tokens that put the human back at the door. The MCP authorization spec deprecated DCR in its November 2025 revision in favour of Client ID Metadata Documents: the client identifies itself with an HTTPS URL it controls, the server fetches the metadata from that URL, no per-server registration call. DCR stays as a backwards fallback.
• Web Bot Auth (RFC 9421). Cryptographic proof of which agent sent a request - an Ed25519 key, a signed request, a published key directory. Cloudflare wired it into Verified Bots; AWS WAF, Akamai, and Vercel followed; Visa TAP and Mastercard Agent Pay lean on it as the front door for agentic commerce; the IETF chartered a working group for it in early 2026. But it proves the agent’s identity, not the user’s. Different problem. We test: web-bot-auth-directory.
• ID-JAG / Cross-App Access. The Identity Assertion JWT Authorization Grant lets a client exchange an identity assertion (an OIDC ID token or refresh token) for delegated access to a third-party API in another trust domain - no separate consent step at the resource server, because the resource already trusts the IdP through SSO. It is the most promising no-touch path, and also the most constrained: it only works where the agent’s IdP and the service already trust each other, which is an enterprise SSO assumption, not an open-web one.

The pattern: every option either proves the agent without user delegation, or delegates with a human in the consent loop, or works only inside a pre-arranged trust domain. None lets an arbitrary agent walk up with only the user’s email, prove who the user is, and walk away with a scoped credential.

One real alternative is to skip auth entirely. x402 (Coinbase’s protocol) revives the 402 Payment Required status code: the agent calls a resource, the server responds with a payment header, the agent attaches a stablecoin payment and retries, the resource comes back. No account, no signup, no token. The payment is the credential. The bet has real infrastructure behind it now - AWS Bedrock AgentCore shipped a Payments preview built with Coinbase and Stripe that handles the 402 negotiation inside the agent’s loop, with a Bazaar of 10,000+ pay-per-use endpoints. We grade this with x402-support, plus its sibling protocols (mpp-support, acp-support, acp-delegate-payment, ucp-support).

x402 is an honest answer for stateless, transactional calls: pay-per-fetch, pay-per-inference, pay-per-search. It is the right primitive for a class of interactions that does not need an account on the other end. But it is not an answer for relational ones - any product where an agent needs an ongoing scoped relationship with the user (writing to a CRM, holding a booking, mutating a doc, issuing per-user audit trails) still needs real auth. Most useful agent work is in the second bucket, and the merchant side of x402 also assumes a stablecoin acceptance most services don’t have yet.

And the deeper limit: x402 lets an agent transact with a product, but it has no way to do that on behalf of a human. The payment proves money, not identity; the service has no idea which user the agent is acting for, so it cannot scope, audit, or revoke per-user. Payments and delegated auth are parallel bets, not competitors - a product will need both, for different calls.

Read the live attempts side by side and they rhyme. An agent hits an API, gets a 401 with a WWW-Authenticate header pointing at protected- resource metadata (RFC 9728), follows that to the authorization server’s metadata (RFC 8414), reads a structured block describing how an agent registers, and posts a signed assertion to get a scoped credential in the same exchange. Discovery, then metadata, then a one-shot registration. That is the shape, whatever the wire format.

Several efforts are racing to fill that shape. ID-JAG and Cross-App Access cover the enterprise-SSO case. Discovery- file conventions - a markdown or JSON document an application publishes telling an agent how to authenticate, WorkOS’s auth.md being one such convention - cover the open-web case by composing existing standards (PRM for resource discovery, AS metadata for endpoints, an identity-assertion or OTP flow for the actual claim). The shared metadata block looks roughly like this:

{
  "agent_auth": {
    "skill": "https://service.com/auth.md",
    "register_uri": "https://auth.service.com/agent/auth",
    "claim_uri":    "https://auth.service.com/agent/auth/claim",
    "revocation_uri": "https://auth.service.com/agent/auth/revoke",
    "identity_types_supported": ["anonymous", "identity_assertion"],
    "identity_assertion": {
      "assertion_types_supported": [
        "urn:ietf:params:oauth:token-type:id-jag"
      ],
      "credential_types_supported": ["access_token", "api_key"]
    }
  }
}

We are not betting on which of these wins, and we would not advise anyone to. Adoption is thin, the underlying drafts are still moving, and the agent-verified path only works where the agent’s IdP and the service already trust each other - a social problem no protocol can solve. What we are confident about is the shape: a discoverable, no-touch handshake that hands an agent a scoped, revocable, per-user credential. Whoever a product adopts, v1.2 grades whether they implemented that shape correctly.

Six new bonus checks in the Access layer, scoring the self-serve handshake above wherever a product ships it. All are bonus - they only widen the denominator when a product earns them, so non-adopters are never penalised.

• auth-md-exists (2 pts) - a real markdown body at /auth.md, with a guard that rejects SPA catch-alls.
• auth-md-structure (2 pts, deep) - an LLM grades each canonical section on content quality and extracts the facts the document exposes (hosts, URIs, identity types, scopes), persisting them onto the scan.
• auth-md-walkthrough-simulation (2 pts, deep) - a GET-only agent walks /auth.md → PRM → AS metadata → registration template. Never POSTs.
• agent-auth-discovery-metadata (3 pts) - validates the full PRM ↔ AS ↔ agent_auth ↔ skill back-pointer chain.
• agent-auth-www-authenticate (1 pt) - a 401 carrying WWW-Authenticate: Bearer resource_metadata=... pointing at the PRM.
• agent-auth-endpoints-reachable (2 pts) - OPTIONS-probes URIs from the metadata block and from fenced http blocks in the prose.

These sit alongside the OAuth, PKCE, Web Bot Auth, and payment checks already in the layer. Together they grade the full credential surface, not one protocol.

v1.2 also rewires the scan pipeline. A 132-check scan now completes in ~15s, down from a ~120s user-reported baseline; scoring math is unchanged.

Auth is the last mile, and the products that close it first will be the ones agents reach for. The honest state of the art is a fragmented one: a handful of protocols each solving part of the problem, none settled, the standards still moving under everyone. That is exactly why we grade the surface instead of betting the scorecard on a single spec. When the winner is clear, the checks that reward it are already in place; until then, every credible path earns credit for being implemented well.

Run a fresh scan at /#scan. The full check catalog is at /methodology. Every check still maps to the same AgentReady requirement; the standard is open at agentready.org.