Decide which agents may act as you.
A Person Server is the part of AAuth that speaks for the human. It says which AI agents may act for you, at which services, on what terms — and it keeps the record. psd is one you run yourself: a single Rust binary, passkeys, SQLite.
Pairs with an Agent Provider such as agentprovider.dev — the two halves of “this agent, acting for this person”.
Three parties. One question: may this agent act as you here?
AAuth separates who vouches for the software from who vouches for the human. Resources verify both — against published keys, never a callback.
Vouches for the software
“This is agent X, and here is its key.”
Issues short-lived aa-agent+jwt identities bound to a key the agent holds. Run one, or use agentprovider.dev.
Vouches for the human
“Agent X acts for this person at this service, and here is what they allow.”
Holds the agent ↔ person binding, runs consent, issues aa-person+jwt and aa-auth+jwt, keeps the record, and revokes.
Verifies and serves
“Signed by a key I can check; the person said yes.”
An API, an MCP server, a calendar. It checks the agent's signature and the Person Server's token against their published JWKS.
sub; two of them cannot correlate you.The person who decides. The operator who runs it.
psd is one binary, but the person logging in with a passkey and the operator terminating TLS want different pages.
Using your Person Server
What you are being asked, what approving means, and how to take it back.
- Enrol with a passkey from a one-time link
- Read a consent screen: agent, provider, service, terms
- See every agent connected to you; revoke one in a click
- Missions: approve a task once, end it any time
Install & deploy
Build it, pick a permanent issuer, put TLS in front, add the first person.
keygen·example-config·serve·person add- Configuration reference, every field explained
- Reverse proxy rules: preserve
Host, no path rewrites - Headless approvals, audit log, key rotation, backups
An agent asks. You decide. The service checks.
Everything on the wire is signed. Nothing long-lived is issued. Every step is recorded where you can read it.
The agent asks
It signs POST /person with the key its Agent Provider vouched for and names the service. Unknown or unconsented → 202, and the person is asked.
The person decides
A consent screen shows the agent, its provider, the service and its terms. Passkey, approve or deny — once, or per scope, or for a mission with a lifetime.
The service verifies
The agent receives a person token (≤ 1 h) bound to its own key and presents it, signed, to the service — which checks it against psd's published JWKS. Revoke any time.
Try it without running anything.
Build and test agents, providers and resources against a live Person Server — no local setup. Pairs with the Agent Provider sandbox for the full “this agent, acting for this person” flow.
# the live Person Server — discovery document relying parties fetch $ curl -s https://sandbox.personserver.dev/.well-known/aauth-person.json # the keys every verifier checks person and auth tokens against $ curl -s https://sandbox.personserver.dev/.well-known/jwks.json
Development only. Sandbox tokens have no production value. Test people are issued on request (passkeys, no passwords); state may be reset on redeploy. No SLA.
Run it in a few minutes.
One binary, one keys file, one SQLite database. The issuer is permanent — pick the hostname before first run.
# build (Rust 1.85+; no C toolchain beyond what SQLite needs) $ git clone https://github.com/PersonServer/source-code psd && cd psd $ cargo build --release # signing keys + the pairwise secret, once — back this file up $ ./target/release/psd keygen --keys psd-keys.json # a config to edit: issuer, keys_file, storage.path $ ./target/release/psd example-config > psd.json # serve, then add the first person — prints a one-time enrolment link $ ./target/release/psd serve --config psd.json $ ./target/release/psd person add --name "Alice" --config psd.json
Tracks a draft. AAuth is an IETF Internet-Draft, not yet a released standard. psd follows draft-hardt-oauth-aauth-protocol-11 and announces this at startup; pin a commit and expect wire changes as the specification matures.
Small, load-bearing, yours.
The Person Server is where the human's authority enters the system. psd keeps that surface small and does the parts the specification makes hard.
Passkeys first
No passwords anywhere. Enrol from a one-time link, log in with a discoverable credential, add more passkeys from the dashboard. Pure-Rust WebAuthn.
Consent that says what it means
The screen names the agent, its provider (verified), the device it claims (marked unverified), and the service's own name and terms — fetched at request time, rendered through a whitelist.
Key-bound tokens
Every person and auth token carries cnf for the agent's Ed25519 key. A leaked token is inert without the private key; every request is signed (RFC 9421).
Pairwise identifiers
The sub a service sees is derived per (person, service). Two services cannot join their records to learn it is the same person.
Revocation that reaches
Revoke an agent on the dashboard and its auth tokens are revoked at every service that received one — signed by psd as itself. Agent Providers can revoke into psd the same way.
Missions
An agent proposes a task with its tools and services; the person approves it once, with a lifetime. Every token under it is capped by that lifetime; ending it revokes them.
A record you can read
Every issuance, denial, revocation and mission event is an audit line (stderr + optional file) and a row the dashboard shows the person under Activity.
Hardened egress
psd fetches metadata from URLs an attacker chose. HTTPS only, no redirects, no private addresses, pinned IPs, size and time caps — on every outbound request.
Your branding, your pages
Every screen is a server-rendered template embedded in the binary. Point ui.templates_dir at a directory to override any of them by file name.
Read on.
Guides for both audiences, the operator references, and the protocol notes behind the code.
A Person Server, distilled
Parties, the four tokens, the deferred flow, missions, federation — and what psd deliberately does not do.
Read for peopleUsing your Person Server
Enrolling, reading a consent screen, the dashboard, revoking, missions.
Open guide for operatorsInstall & deploy
Build, keys, issuer, TLS and proxy rules, first person, systemd, backups, upgrades.
Open guide referenceConfiguration
Every field, its default, and the protocol rule behind it. Environment overrides.
Read referenceHTTP API
Discovery, /person, /pending, /token, /revoke, /mission, and the error vocabulary.
Hosted sandbox
A live Person Server at sandbox.personserver.dev to build and test against — test people on request, no local setup.
agentprovider.dev
The Agent Provider: cryptographic identity for agents, a hosted sandbox to test against, and the shared protocol library psd builds on.
Visitpsd is the person's side. The rest of the exchange:
AAuth splits the job across parties run by different people, and none registers with the others. These are the pieces built alongside psd — each labelled by whose side of the exchange it serves.
apd — Agent Provider
Issues the short-lived, key-bound aa-agent+jwt identities psd verifies. Self-hostable, same shape as psd; a hosted sandbox with open enrollment to test against.
agentd — agent runtime
A minimal, MCP-native runtime that enrols with an Agent Provider, holds its own Ed25519 key and signs every request — the kind of agent that shows up on psd's consent screen.
agentd.dev the resource's sidemcpg — MCP gateway
One governed endpoint in front of your MCP servers: verifies the per-request agent signature, applies per-person permissions, keeps the audit trail. The service psd's tokens are presented to.
mcpg.dev