> ## Documentation Index > Fetch the complete documentation index at: https://docs.afauth.org/llms.txt > Use this file to discover all available pages before exploring further. # Why AFAuth > Existing auth assumes a human is the root of trust. Agents need a different model. Today, AI agents reach internet services in one of two ways: 1. **Impersonating a human** — browser automation against signup forms, password vaults, magic-link interception. Brittle, against most services' Terms of Service, and indistinguishable from fraud from the service's perspective. 2. **Delegated scope from a human's account** — OAuth-style `actor_token` flows. Useful, but requires a human account to exist first and ties the agent's lifespan to that human's session. Both approaches assume a human user is the **root of trust**. That assumption breaks down when: * A long-running autonomous agent needs persistent state on a third-party service. * An agent interacts with a service before any human is involved. * A human may *eventually* claim an account — but isn't present at creation. * A service wants to support agent-first commerce without requiring upfront human registration. ## What AFAuth changes AFAuth inverts the assumption. An **agent signs up on its own behalf**, identified by a cryptographic keypair it controls. The agent is the principal; the human is optional and can be added later. | | Today | With AFAuth | | --------------------------- | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | Who creates the account | A human, ahead of time | The agent, at first contact | | What identifies the account | An email + password | A `did:key` derived from an Ed25519 keypair | | How the agent authenticates | A bearer token issued via OAuth | An RFC 9421 signature per request | | How a human gets ownership | They *are* the owner from day one | They claim the account later, if/when desired | | How abuse is bounded | Email/CAPTCHA at signup, tied to PII | A per-human pseudonym (`sub_h`) from an [attestation](/concepts/attestation) — rate-limit and ban per human, no PII collected | | Cross-service portability | None — re-register everywhere | Optional — the same DID works anywhere, or per-service keys for unlinkability | ## Self-sovereign without being spammable Accepting *any* Ed25519 keypair with no registry is what makes AFAuth open — and, on its own, what would make it spammable: a bad actor can mint 10,000 throwaway agents that look like 10,000 customers. AFAuth's [attestation](/concepts/attestation) layer (§10) closes that gap. A service can require each agent to present a short-lived JWT from a [trust attestor](/concepts/trust-attestor) proving a *verified human is on the hook*, keyed by a per-service pseudonym (`sub_h`) that carries **no PII**. Abuse is bounded per human, not per keypair — the `defineService` default groups a human's agents onto one account by their `sub_h` (§10.4.4: one account, many devices), so you rate-limit, quota, and ban per account (or `sub_h`) and a human's whole fleet shares one bucket. This is a default, not an add-on. A service that enables `attested_only` signup is unreachable to un-attested agents, which is why the default service factory (`defineService`) ships attestation **on**, and the default agent journey [links to a human](/guides/link-to-a-human) before its first signup. Spam-resistance is a pillar of the model, not an advanced option. ## What AFAuth doesn't change AFAuth is one layer of the agent-services stack. It addresses **identity** — currently the gap — and composes with everything around it. | Layer | Examples | AFAuth's role | | ---------------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | Capability / transport | MCP, A2A | The AFAuth DID can be carried in MCP's CIMD URL and A2A Agent Card identity fields | | Authorization | OAuth 2.0 `actor_token`, OIDC for AI Agents, FIDO AP2, Visa Trusted Agent | An AFAuth signature serves as the `actor_token` and as the cryptographic identity inside payment-authorization tokens | | **Identity** | **AFAuth** | Self-sovereign agent identity for the open web | AFAuth doesn't replace OAuth, MCP, or A2A — it plugs into them; [Migrate from OAuth or API keys](/guides/migrate-from-oauth) shows the incremental path for an existing service. Attestation is different: AFAuth defines its own §10 attestation hook and ships a default trust attestor (`afauth-trust`), so spam-resistance works out of the box, while still letting third-party platform and commerce attestors (Entra, Stripe, FIDO AP2) plug in alongside it. ## When NOT to use AFAuth * You already have a working OAuth-delegated agent flow and don't expect agents to operate without a pre-existing human account. AFAuth's value-add is small here. * You're inside a managed enterprise environment where every agent identity is provisioned centrally (e.g., Microsoft Entra Agent ID). You can still use AFAuth here, but the simpler model is to use the platform's agent identity directly — AFAuth's attestation hook (§10) lets you bridge. * You need inter-agent delegation. That's covered by separate protocols (Google A2A, OAuth `actor_token`); AFAuth provides the identity those protocols delegate from, not the delegation flow itself. ## Further reading * [Security model](/concepts/security-model) — what it protects against, what it assumes, what it leaves to services. * [Identity and keys](/concepts/identity-and-keys) — how AFAuth names accounts. * [The ceremony](/concepts/ceremony) — how an agent-owned account becomes human-owned. * [Spec §1](https://github.com/AFAuthHQ/spec/blob/main/spec/core.md#1-introduction) — the normative motivation.