Skip to main content
If you already run a coding agent — Claude Code, Codex, Cursor, or anything that can run shell commands — AFAuth gives it an identity. Install one small binary, link it to yourself once, and your agent can sign up for and use AFAuth-supporting services on its own — as itself, not by borrowing your passwords or pausing for you at every step. You set it up once. After that it’s hands-off: ask your agent to use a service, and it signs up and makes authenticated requests by itself.
Who this is for. You’re not building an agent or running a service — you just want the agent you already use to reach services. Building an agent product instead? See Build an agent. Running a service that should accept agents? See Accept AFAuth.

​
What you get

  • An identity your agent controls — a did:key, no shared passwords, no signup forms to automate.
  • Reach to spam-resistant services, because the agent is linked to a real human (you) — while exposing none of your personal information to those services.
  • Control that stays with you: you own the key, you can claim anything it signs up for, and you can revoke it anytime (more below).

​
Set it up once

1

Install the afauth CLI

brew install afauthhq/tap/afauth
Confirm it’s on your PATH — afauth --help lists the commands.
2

Give your agent an identity

afauth init
Generates an Ed25519 keypair at ~/.afauth/key.json. That key is your agent’s identity.
3

Link it to yourself

afauth trust link
This opens trust.afauth.org in your browser and asks you to confirm. You’re vouching that a real person — you — stands behind this agent, which is what lets spam-resistant services accept it. It shares no personal information with those services; they only ever see a per-service pseudonym.You do this once: the link stays valid as long as your agent keeps using it, lapsing only after ~90 days of no use. And only you can do it — it’s the human-on-the-hook step, the agent can’t fake it.
Most services run attested_only, so this step is required before your agent can sign up — after it, afauth signup mints the short-lived proof automatically. Full detail: Link your agent to a human.
4

Tell your agent the commands exist

Your agent drives afauth by running it in the shell — it just needs to know the commands are there and when to reach for them. Paste this into the instruction file your tool reads:
## AFAuth — signing up for services

This machine has the `afauth` CLI, already linked to the user. To sign up for or
call a service that supports AFAuth, use it instead of creating an account with an
email and password:

- `afauth discover <url>`   — check whether a service supports AFAuth
- `afauth signup <url>`     — sign up (auto-attests when the service requires it)
- `afauth call <url>`       — make a signed request (add --method / --data / --header)
- `afauth accounts list`    — list services already joined

Do NOT run `afauth trust link`, `afauth keys`, or `afauth invite` without asking
the user first — those touch the user's identity and account ownership. If a
command fails asking for trust or attestation, tell the user to run `afauth trust link`.
Your toolPaste it into
Claude CodeCLAUDE.md (project) or ~/.claude/CLAUDE.md (global)
CodexAGENTS.md
Cursora Project Rule under .cursor/rules/

​
Now your agent signs up on its own

Ask it in plain language:
“Sign up for Tavily and run a search for recent AFAuth coverage.”
It runs the steps itself — no forms, no shared credentials: 
afauth discover https://tavily.com    # confirms AFAuth support
afauth signup   https://tavily.com    # signs up; auto-mints the attestation
afauth call     https://tavily.com/...  # the signed, authenticated request
Every account it creates starts unclaimed and agent-operated — it keeps working with no further input from you, until you decide to take ownership.

​
What stays under your control

This is what makes letting an agent loose actually safe:
  • You own the key. Everything lives under ~/.afauth/; key.json is the sole credential. Back it up once — afauth keys export --out afauth-backup.json — and store it somewhere safe.
  • Abuse is bounded to you, not multiplied. Because the agent is linked to one human, a service rate-limits and bans per human — your whole fleet shares one bucket. A runaway or stolen agent can’t pose as thousands of fresh customers.
  • You can claim anything it created. Turn any account into a human-owned one whenever you like: afauth invite you@example.com --service <url>, then confirm from your inbox. See Invite and claim.
  • You can revoke it anytime. Drop the human link (afauth trust forget, or revoke at trust.afauth.org/account), rotate the key, or recover a compromised one.
  • The agent can’t sign ownership away. Its signature alone can never bind an account to anyone else — claiming always requires a human authenticating at the invited address. That’s the protocol’s security boundary.
AFAuth is identity, not a wallet. It proves who your agent is; it does not authorize spending or accept a service’s terms on your behalf beyond the signup itself. A service’s own billing, quotas, and terms of service still apply — review them before pointing an autonomous agent at anything that can charge you.

​
Where to next

The full CLI

Every afauth command, grouped by what it does.

Claim an account

Become the human owner of something your agent created.

How the human link works

What afauth trust link proves — and what it deliberately keeps private.

Why agents need their own identity

The case for agent-first auth, in one page.