AAuth: cryptographic identity for AI agents

API keys are a poor fit for agents: they are long-lived, bearer-style, copied into environment variables, and revoked by incident response rather than by design. The AAuth drafts (IETF, tracked at draft-09) replace them with a three-role protocol: an Agent Provider issues identities, an agent proves possession by signing its requests, and a relying party verifies statelessly.

The mechanics compose from boring, proven parts:

• Identity is a stable name like aauth:local@your-domain, bound to an Ed25519 signing key by a short-lived agent token.
• Requests carry RFC 9421 HTTP Message Signatures — the relying party checks the signature against the provider's published JWKS. No introspection call, no shared secret, no session state.
• Enrollment is secret-free federation: a workload proves itself with what it already has — a Kubernetes service account, CI OIDC, PKI, SPIFFE — and walks away with an identity measured in minutes.

Three access modes cover the deployment spectrum, from a relying party that trusts one local provider to full cross-domain federation. Revocation is mostly a non-event — tokens expire on their own — and the blast radius of a leaked context shrinks to the token's lifetime.

In the lab's stack the roles are concrete: apd is the provider, agentd signs outbound calls to AAuth-protected MCP servers, and agentctl can provision a per-agent identity at schedule time. The digest's honest caveat: the drafts are moving, and the sandbox label on apd is there because the implementation deliberately moves with them.