June 2026

AAuth and the shape of agent authority

AAuth is exciting because it gives agent authority a shape you can inspect. That sentence is compact, but it hides a lot. So this post starts from the beginning: identity, authentication, OAuth, agents, and why Sidecat cares.

The simple version is this: when software acts for a person, other software needs to know who the action is about, how that claim was checked, what the software was allowed to do, and what evidence remains afterward. AAuth is a young protocol effort for the network part of that story. Sidecat is a young system for the local work-and-evidence part.

The fit is unusually good. AAuth can help a remote service understand an agent request. Sidecat can keep the work, consent, evidence, and receipts recoverable after the chat window, model call, or agent process is gone.

Identity is the name; authentication is the proof

Before OAuth or AAuth, it helps to separate two words that often get mushed together.

A driver's license is a helpful offline analogy. The name on the card is identity. The hologram, issuing state, photo, and barcode are part of the authentication story. They do not make you Josh; they help someone check that the person standing there matches the claim.

Authorization is the next question: "what is this identity allowed to do?" You can prove who you are and still be forbidden from deleting a database, pushing to a repository, or reading someone else's medical record. A lot of security confusion comes from treating identity, authentication, and authorization as one blob.

OAuth in plain English

OAuth is one of the main ways web software handles delegated access. You have probably used it many times without thinking about it. A site says "connect your Google Calendar" or "sign in with GitHub." You click through a consent screen. The app receives a token. The app can now call a service on your behalf, within the permissions that token represents.

The important thing is that the app does not need your password. You do not hand the photo-printing website your whole Google account. You grant it a narrower token that the calendar or photo service understands.

sequenceDiagram
    actor You
    participant App as App you are using
    participant Service as Service with your data

    You->>App: I want this app to use my data
    App->>Service: please ask the user
    Service->>You: do you approve this access?
    You->>Service: yes, for these permissions
    Service-->>App: access token
    App->>Service: request with token
    Service-->>App: allowed data or action

OAuth is not magic. The receiving service still needs to check the token, the app, the requested scope, and the current policy. But OAuth made a huge idea practical: a user can authorize one piece of software to do a bounded thing at another service without sharing the user's password.

Agents make the story stranger

Agents complicate this because an agent is not a normal app. A normal app usually has a fairly stable shape: a calendar app, a photo app, a build system. An agent may plan, browse, write code, ask another agent for help, call a model provider, summarize a document, and then trigger a tool. It may do all of that in one task.

So the old question "does this app have a token?" is too small. The more interesting questions are:

• Which person or person server approved this work?
• What mission is the agent acting under?
• Which agent identity is presenting the request?
• Which key signed this specific request?
• Which resource is being asked to do what?
• What record will survive so someone can review the action later?

This is why AAuth feels important. It is aimed at the agent-shaped version of delegated authority. The work is not just "let this app read my calendar." It is closer to "let this agent work on this mission, with this identity, using this request key, against this resource, under these checks."

Why the world needs something like AAuth

We are moving into a world where software will not always wait for a human to press every button. An agent may book travel, triage email, patch a server, negotiate with another service, file a report, open a pull request, or ask a specialist model for help. That work may cross devices, accounts, cloud services, local daemons, private data stores, and other agents.

In that world, "the agent has my API key" is a scary answer. It is too broad. It says the agent can act as you wherever that credential works, but it says very little about the particular job you meant it to do. It also makes review hard. If something strange happens later, the logs may say a credential was used, but not why the action was part of a mission, whether the right agent signed it, or whether the request was changed on the way to the resource.

AAuth matters because it points at a more precise contract. The question becomes less "does this process have a secret?" and more "is this signed request bound to the person-approved mission, the agent identity, the right key, the intended resource, and the current verifier policy?"

This is not only a security story. It is also a usability story. If agentic systems are going to do useful work for ordinary people, humans need consent screens and review tools that talk in human-shaped terms: "approve this mission," "let this agent use these tools," "show me what happened," "stop this delegation," "why was this request allowed?"

AAuth does not solve that whole product experience by itself. Protocols usually do not. But it gives implementers a shared way to carry the authority-relevant facts across the network so user-facing systems can build on them.

What AAuth adds to the picture

AAuth gives names and wire objects to the agent authority story. The exact draft language is still moving, but the shape is already useful.

• A Person Server can help approve a mission.
• The approved mission can be named by an AAuth-Mission reference.
• An agent token can identify the agent and bind it to key material.
• The agent can sign an HTTP request so the request itself is protected.
• A resource or authorization server can verify that the token, key, mission, and request line up.

sequenceDiagram
    actor Human
    participant PS as Person Server
    participant Agent
    participant Resource
    participant AS as Authorization Server

    Human->>PS: approve a mission
    PS-->>Agent: mission reference
    Agent->>Resource: signed request + agent token + mission
    Resource->>AS: verify or request token context
    AS-->>Resource: decision
    Resource-->>Agent: response, challenge, or rejection

The key idea is binding. A token signature by itself is not enough. A request signature by itself is not enough. The verifier needs to check that the token, key, mission, audience, issuer, and request all belong to the same story.

Missions are the part that feels new

The mission idea is the piece that makes AAuth feel native to agentic work. A human does not approve every byte of every later request. They approve a bounded purpose: this agent, doing this kind of work, under this context.

In the current AAuth shape, the request can carry an AAuth-Mission reference: an approver and a hash of the approved mission bytes. That lets a request carry a compact pointer to the consent context without putting the whole mission body on every resource request.

Sidecat already thinks in a similar way. Work is not just an action. It has an intent, a record, evidence, gates, decisions, and receipts. AAuth brings a related shape to network requests: the request can point back to the mission that made the action legitimate.

The chain of binding

Here is the cool part in one line. AAuth is trying to make this chain real on the wire:

Each step should constrain the next. The mission says what context the work is for. The token says which agent is presenting itself. The key proves possession for the request. The signature binds the request components. The verifier checks the local context instead of trusting a single field in isolation.

flowchart LR
    mission[AAuth-Mission reference]
    token[Agent or auth token]
    key[Request signing key]
    request[HTTP request components]
    verifier[Verifier]
    result[Accept, challenge, or reject]

    mission -- covered by signature --> request
    token -- binds cnf.jwk / agent_jkt --> key
    key -- verifies HTTP Message Signature --> request
    request -- method, path, authority, headers --> verifier
    token -- issuer, audience, expiry, delegation --> verifier
    mission -- approver + hash --> verifier
    verifier -- policy + binding result --> result

Why this fits Sidecat

Sidecat is local-first. It keeps work state, evidence, authority, and recovery in service-owned records so the important parts of the work do not live only in chat. It also treats external effects as something that must spend explicit authority. Commits, pushes, messages, deployments, and later networked agent actions should leave receipts.

AAuth gives Sidecat a possible language for the moment work leaves the local substrate. Sidecat can know why an agent is acting, what work item it is bound to, what evidence has been gathered, what operator approval exists, and what receipt should be recorded afterward. AAuth can carry a compact, signed request across the network so another service can verify the agent-facing parts.

That division is important. Sidecat does not need to make every outside service understand a Sidecat work record. AAuth does not need to become Sidecat's whole memory and evidence system. The useful fit is a handoff: local work becomes a mission-bearing request, and the result comes back into local custody.

flowchart TB
    subgraph Local["Sidecat local substrate"]
      work[work item]
      intent[operator intent]
      evidence[evidence]
      receipt[receipt]
    end

    subgraph Wire["AAuth wire path"]
      mission[AAuth-Mission]
      signed[signed request]
      remote[resource / authorization server]
    end

    intent -- shapes --> work
    work -- supplies context --> mission
    evidence -- supports --> mission
    mission -- carried by --> signed
    signed -- verified by --> remote
    remote -- response or challenge --> receipt
    receipt -- records outcome --> work

What we have implemented so far

In the Sidecat repository, the AAuth work lives mostly in internal/aauthcat, cmd/sidehardt, and the local Person Server paths in sidecatd. The implementation covers enough of the wire shape to make real implementer feedback possible:

• agent identity and token helpers;
• AAuth-Mission reference parsing, signing, and verification paths;
• HTTP Message Signature signing and verification;
• AAuth-Requirement, AAuth-Access, and capability header handling;
• issuer metadata and JWKS discovery with explicit host admission;
• parent-mediated sub-agent binding checks;
• R3 content-addressing helpers for exact byte identity;
• a draft-hash monitor so we can tell when the upstream documents move.

The unsettled parts are useful

AAuth and Sidecat are both still young. That should be said plainly. Some boundaries are not settled yet: exactly when a resource may dereference a mission blob, how much discovery policy belongs in the protocol, how replay caches should be shaped, which examples should be normative test vectors, and how the full multi-node version should feel in daily use.

Those are reasons to implement carefully, write down each judgment call, and turn ambiguity into tests. A young protocol improves when implementers bring back precise experience: this field was easy to misuse, this verifier sequence should be named, this cache behavior needs a sentence, this example should be parseable.

That is a good role for Sidecat. It can keep the local record of the implementation work while the AAuth objects exercise the network-facing authority story.

Where this goes next

The next interesting step is a multi-node setup. The single-laptop path lets us prove parsers, token checks, signatures, mission references, and smoke flows. A cluster starts asking the more interesting questions: what happens when the Person Server, agent, resource, authorization server, and verifier do not all live in the same trust bubble?

That is where Sidecat should become more than a local implementation notebook. It should record the user test, the mission, the request, the remote response, the verification result, and the receipt. AAuth can make the request intelligible to the outside service. Sidecat can make the whole run intelligible afterward.

The larger bet is simple: the agentic web will need more than powerful models and bigger toolboxes. It will need ways to answer, after the fact and during the act, who authorized this, under what mission, using which key, against which resource, with what evidence?

AAuth is exciting because it starts answering that question on the wire. Sidecat is exciting because it wants the answer to survive the session.