Try to steal a token
Today agents call services with API keys and OAuth bearer tokens. Whoever holds the token can use it. Pick a mode and press the button.
Six parties
Tap any party to see what it does and who it talks to. Not every party takes part in every flow.
Four documents and a session pass
Every AAuth token is short-lived and signed by whoever issued it. The color stripe shows who issues each one.
cnf or agent_jkt claim). If a request isn’t signed with that key, the token is void. That’s why stealing it is pointless.
Watch it work, step by step
Pick a mode and press “Next” (or use the arrow keys). The modes differ in what the service ends up knowing. One service can use different modes on different endpoints.
Swipe for more modes →
How much the service learns in each mode
The taller the bar, the more the service knows before it answers. Tap a bar to open that mode.
The agent doesn’t need to know the service in advance
The agent always does the same thing: send a request, read the AAuth-Requirement header (“here’s what I need from you”), satisfy it, and retry. The first request to a service is the registration.
You give the agent a task, the Person Server keeps an eye on it
A mission describes the task in plain language. The agent proposes it, you approve it. From then on the Person Server checks every action against the mission and logs everything. Missions are optional. Play the human.
Mission log
No mission- Empty so far
What else is built in
Sub-agents
A main agent can spawn helpers. Each gets its own passport marked with parent_agent. They never call the Person Server themselves: the parent gets their passes. Only one level deep.
Call chaining
A service that needs another service to answer becomes an agent itself, with its own passport. The person’s authority flows down the chain, and the Person Server sees every link.
No forever tokens
An agent passport lasts up to 24 hours, a person token up to an hour, an access request up to 5 minutes. There are no refresh tokens: when a pass expires, the agent asks the service again, and the service can say no.
Cascading revocation
Revoke a person token and the Person Server tells the service and the access server. The access server in turn cancels every pass it issued against that token.
Privacy
You get a different pseudonym (sub) at every site, so sites can’t link you to each other. In modes 3–5 the service doesn’t even see which agent product showed up, so it can’t admit “only agents from company X.”
An honest consent screen
The Person Server must visually separate the agent’s words (“I need this because…”) from what the service itself declared. The agent gains from being believed, so you should see who said what.
Adopt it piece by piece
Each party joins on its own. A service can start by checking signatures instead of API keys. Anyone who doesn’t know AAuth simply ignores the new headers, and everything old keeps working.
A whole family of drafts
Separate documents grow alongside the core protocol: Budgets (agent spending limits), Events (notifications to agents), R3 (permissions in MCP, OpenAPI, gRPC and GraphQL terms) and Bootstrap (how an agent gets its passport).
Why it beats OAuth for agents
AAuth doesn’t replace OAuth everywhere. A service can wrap its existing OAuth inside a session token, and a Person Server can sign people in with OpenID Connect.
| OAuth 2.0 and API keys | AAuth | |
|---|---|---|
| Client identity | ✕Every server issues its own client_id: an ID at Google means nothing at GitHub | ✓One ID, aauth:name@domain, that anyone can verify |
| Registration | ✕Up front at every server (or Dynamic Client Registration, as in MCP) | ✓Not needed: the first request is the registration |
| Stolen token | ✕Bearer token: whoever steals it gets in | ✓The token is bound to a key and every request is signed |
| Agent instances | ✕One client_id for the whole app | ✓Every running copy has its own ID, so you can revoke just one |
| Service identity | ✕The service doesn’t cryptographically prove who it is | ✓The service signs its access request (resource token) |
| Agent oversight | ✕None | ✓Missions, action permissions, audit, questions to the person |
| Who decides | ✕Always the resource owner’s server | ✓Your Person Server and the service’s access server work it out together |
| Renewal | Refresh tokens | No refresh: ask again each time, and the service gets a say |
Frequently asked questions
Can I use it today?
You can try it: there are SDKs for TypeScript, .NET, Python and Go, a Keycloak extension, a ready-made Person Server and demo playgrounds (AAuth Explorer, AAuth Web Agent). But it’s a draft, not a standard. Field names and even the number of modes change between versions, so it’s too early for production.
Does it replace OAuth?
No, it’s more of a layer for the world of agents. Regular apps with OAuth keep working as before. A service can wrap its OAuth token inside an AAuth session token, and a Person Server can sign people in with OpenID Connect.
What changes for an ordinary person?
You get one place that shows all your agents: which are connected, on which devices, what tasks they have and what they’ve already done. That’s also where you answer an agent’s question, allow or block an action, and revoke access. That place is your Person Server.
What if the agent’s secret key itself is stolen?
Then the agent provider stops issuing it passports and revokes the current one through the Person Server. A passport lasts at most a day, a person token at most an hour. There is one weak spot: a service that admits the agent on its passport alone (mode 1) never hears about the revocation, so there access ends only when the passport expires.
How does this relate to MCP?
MCP currently uses OAuth 2.1 with Dynamic Client Registration: the agent gets a new client_id at every server, and tokens are bearer tokens. The AAuth author points to MCP as a place where those limits already hurt. AAuth implementations for MCP already exist: a TypeScript SDK for MCP servers and an Envoy / agentgateway module that turns an MCP service into an AAuth resource.
Who will be my Person Server?
You choose it; nobody imposes it. It could be a service from your sign-in provider, your company (one server acting as agent provider, Person Server and Access Server for employees), or even a server of your own. The spec has a section on building a minimal Person Server.
Why five modes? Isn’t that too complicated?
Each service takes only what it needs and doesn’t have to adopt everything at once. Usually most endpoints run on the agent’s or the person’s identity, and only a few important actions (payments, writes, deletes) need full authorization.
Where the protocol stands
This is an individual Internet-Draft, not an adopted standard. Details change between versions: the person token only arrived in -11, taking the modes from four to five.