Skip to main content
Existing auth assumes a human is the root of trust. Agents reach services either by impersonating one (browser automation against signup forms) or by being delegated scope from a pre-existing human account (OAuth). Both break down as agents become the primary actor. AFAuth takes the opposite stance. An agent signs up on its own behalf, identified by a cryptographic keypair it controls. If a human ever wants ownership, the agent invites them; the binding only takes effect once the human authenticates from the invited address. The agent continues to operate the account afterwards — but ownership-changing operations become privileged to the human.

​
How it works, in one minute

  1. Generate an identity. The agent makes an Ed25519 keypair; its did:key is its identity — verifiable offline, no registry, no DNS.
  2. Link to a human, once. The agent proves a real person stands behind it at the trust attestor — carrying no PII. (Skippable for services that don’t require it.)
  3. Sign the first request. A request signed per RFC 9421 implicitly creates the account in UNCLAIMED state — there’s no separate signup call.
  4. Operate freely. Every later request is just signed; the agent is a first-class principal from request one.
  5. Hand ownership to a human, optionally. The agent invites a person; ownership commits only once they authenticate from the invited address.

How it works, end to end

The full mental model — the cast of roles and who talks to whom, the signed-request anatomy, the account lifecycle, the two human bindings, and end-to-end code.

​
Four front doors

Run a coding agent

Already run Claude Code or Codex? Install the afauth CLI so your agent can sign up for services on its own.

Build an agent

Generate a keypair, link your agent to a human, sign your first request, and (optionally) invite a human to claim the account.

Accept AFAuth on your service

Mount the discovery document, verify signed requests, and host the claim page.

Ship AFAuth in your CLI

Distribute a CLI or client? Embed the agent role so it provisions your users with their own key — no portal account to automate.
These front doors meet at the trust attestor (trust.afauth.org). New services default to attested_only (spam-resistant), so an agent links to a human once at the trust attestor and presents a short-lived, PII-free JWT on each signed request. Agent-side: Link your agent to a human; service-side: Accept afauth-trust.

​
Where to next

​
Where the protocol lives

AFAuth is documented across three coordinated web properties. This site is the how-to. The protocol home and the service directory are siblings:
SiteRole
afauth.orgProtocol home — what AFAuth is, the manifesto, install paths
docs.afauth.org (this site)How-to — quickstarts, SDK reference, concepts, the §-by-§ spec walkthrough
registry.afauth.orgService directory — opt-in registry of AFAuth-enabled services, mirrorable and non-normative

​
What’s normative, what’s reference

AFAuth is a protocol, not a product. The specification, reference implementations, and tools live in separate repos:
ArtifactRepoRole
SpecificationAFAuthHQ/specNormative protocol text, JSON schemas, test vectors, conformance harness
TypeScript SDKAFAuthHQ/typescript-sdk@afauthhq/agent, @afauthhq/server, @afauthhq/worker, @afauthhq/core
CLIAFAuthHQ/cliafauth — single-binary reference agent runtime (Go)
Alternative implementations are welcome. The protocol is small and language-agnostic.

​
Status

Spec v0.1 — stable. The reference TypeScript SDK (npm), Go CLI (Homebrew + install.sh + go install), trust attestor, and registry all pass the conformance harness against the v0.1 vectors. See the changelog for what ships in each release, and versioning & stability for the compatibility rules.