Skip to content

aauth-go v0.3.0: agents with their own identity, a person to ask, and a way to pay

2026-10-26

AI agents increasingly act for people: they browse catalogs, place orders and change records. APIs need to know which agent is calling, who it is acting for, and whether that person agreed. AAuth answers all three, and aauth-go v0.3.0 makes it practical on both sides of the call.

Protect an API in a few lines

Declare what each operation needs. Browsing needs only the agent's identity, viewing an order needs to know the person, and placing an order needs the person's approval. ResourceGuard checks each request and asks the agent for whatever is missing:

mux.Handle("GET /pets", guard.Require(aauth.Access{Level: aauth.AccessAgent}, listPets))
mux.Handle("GET /orders/{id}", guard.Require(aauth.Access{Level: aauth.AccessPerson}, getOrder))
mux.Handle("POST /orders", guard.Require(aauth.Access{Level: aauth.AccessAuth, Scope: "write:orders"}, placeOrder))

Each handler learns which agent called and which person it acts for. See the resource guide.

Agents that ask before they act

When an operation needs approval, the agent gets a link for the person, waits while they approve at their own person server, then continues. Access is granted one scope at a time, only when it is needed, and only by the person. Agents declare that they can involve the person with AAuth-Capabilities, so an API never leaves an agent waiting for someone who will not be asked.

Agents that can pay

When an API answers 402 Payment Required, aauth-go hands the payment request to your payment handler, which pays through the protocol the API names, such as x402, and then retries the call. Agents can pay for access without custom code for each API. aauth-go has no payment rails of its own: you bring the payment protocol.

Ask for access up front

Agents can request a scope at an API's authorization endpoint before the first call (Transport.Authorize), so the person approves once at the start of a task instead of partway through it.

The whole system on a laptop, in one command

aauth-sandbox runs every AAuth server (agent provider, person server and access server) with demo APIs for all five access modes, on https://*.aauth.test, with its own certificates, consent pages and a trace of every message. Run it with go run or docker compose up, all in one container or one container per server.

  • Point Postman, curl or your own agent at it: a signing helper signs requests for clients that cannot.
  • Put your own API behind it with --upstream and test it against real tokens and real consent.
  • Swap in your own implementation of any server with --remote and test it against the rest.

The sandbox is for development, testing and demos. The production pieces are the libraries. See the sandbox guide.

Learn from tested code

Every step of the AAuth walkthroughs has runnable Go code for each role: agent, API, person server, access server and agent provider. The PIDL walkthrough viewer shows that code next to the HTTP messages it sends.

See it work: the Petstore

The Swagger Petstore, served as an AAuth-protected API behind the sandbox, with two agents:

Both send the same messages, which you can compare in the sandbox's trace.

Built to refuse what it was not given

A signed request works only at the server it was signed for. An agent provider can name only its own agents. A resource with an access server takes auth tokens only from it. And an agent cannot widen a request after the person approved it. The sandbox stays on your machine by default.

Get it

v0.3.0 keeps the draft -11 wire format, so it works with v0.2 agents and servers. Some server APIs change; the migration guide shows each one.

go get github.com/aauth-dev/aauth-go@v0.3.0

Read the release notes for every change.