Sidecat AAuth feedback from a working system
On June 17, 2026, Sidecat showed up in a public Internet-Draft with Intended Status: Standards Track. Not as a launch announcement, and not as a polished product claim. It showed up in the document history for draft-hardt-oauth-aauth-protocol-06, where implementation and interoperability clarifications are tied to feedback from Joshua Gay and Sidecat.
That matters because the feedback did not come from a whiteboard. It came from trying to make a real agent system do the work: issue keys, sign requests, carry a mission, verify tokens, decide what evidence counts, and notice where a spec leaves too much room for two implementations to disagree.
The Sidecat system produced usable protocol feedback. The team, the workflows, the agent review loops, the pressure from implementation/interoperability thinking, and the way Sidecat forces authority/evidence boundaries into the open all created feedback good enough to be reflected in a public standards-track draft.
That matters because it is evidence for the system's thesis:
- Sidecat is not only organizing local work.
- It is helping create sharper external technical judgment.
- It is turning agent work into reviewable, transmissible protocol feedback.
- It is already affecting a nearby standards-track conversation.
What AAuth is, in plain language
AAuth is a proposed authorization protocol for agents. The short version: it gives agents their own identity, lets a person or organization govern what the agent is trying to do, and gives resources a way to verify that a request was made by the right agent under the right authorization context.
That is different from the old pattern of handing an agent an API key and hoping the prompt keeps it safe. A bearer token says, roughly, "whoever holds this can act." AAuth leans toward proof: the request is signed, the key belongs to a particular agent identity, and the token or mission can be checked against the context in which the agent is acting. The token by itself is not the whole story; the signed request and the authority context travel with it.
Why we are implementing it
Sidecat is about making serious AI-assisted work recoverable, reviewable, and governed. That means agents need more than memory and tools. They need identity. They need a way to ask for authority without holding ambient credentials. They need records that explain why a request was appropriate, who approved it, what it was allowed to touch, and how another party can verify that later.
AAuth is interesting to us because it names the wire-level version of that problem. Sidecat can keep the local work item, evidence, receipts, and review history. AAuth can help an agent carry identity and authority across HTTP boundaries in a shape other systems can understand.
This is still early. Sidecat is not claiming a complete AAuth
implementation. What exists today is narrower: Sidecat's
sidehardt path can issue and verify AAuth-shaped agent
tokens, sign and verify HTTP Message Signatures, work with mission
references, and exercise JWKS discovery paths. The resource-side
authorization story is still being built. That distinction is important.
A working slice is not the same thing as a finished protocol stack.
Where the feedback landed
The draft history names the kinds of things our implementation pressure
surfaced: how mission references are dereferenced, how
approver and s256 are shaped, how agent keying
material works, what unknown requirement values mean, how
AAuth-Access tokens are parsed, how capabilities stay
forward-compatible, when JWKS refresh happens, how token verification is
split from request-context binding, and where freshness and replay policy
belong.
That is exactly the kind of feedback Sidecat should produce. Not "we like this." Not "this feels aligned." Implementation feedback: the place where two honest implementers might read the same words and build two incompatible systems.
Missions are the bridge between intent and authority
One of the most exciting parts of AAuth is the idea of a mission. A mission is not just a scope string. It is a description of what the agent intends to accomplish, reviewed and approved by the person server, then bound by a hash so everyone can tell which approved text the agent is acting under.
That maps cleanly to how Sidecat thinks. Sidecat already treats serious work as more than a command. There is a target, a reason, evidence, gates, receipts, and a history of what happened. A mission gives that work an authorization shape that can cross process and network boundaries. It is the difference between "this agent has a token" and "this agent is acting under this approved purpose."
A local identity server with a public name
In the same stretch of work, we took a small but meaningful step toward our own AAuth
identity surface. We set aauth.sidecat.org to resolve to
127.0.0.1. Then we used domain control and Certbot/Let's
Encrypt to get a certificate for that name.
That sounds strange the first time you hear it: a public DNS name that points back to the local machine. But it is the useful kind of strange. It prepares a local Sidecat identity server to speak HTTPS using a name that belongs to Sidecat. The service can become local, private, and laptop-shaped, while the keys and signatures it will produce can still be tied back to a real domain name and a standard HTTPS identity story.
When that local issuer is running, if a local agent signs a request, or if an object it signs later leaves the laptop, we do not want the outside world to see an orphaned local key with no story. We want it to be able to say: this came from an agent identity under a domain-controlled issuer; here is where the metadata will live; here is where the public keys will be discoverable; here is the protocol shape for checking it. That is why conformance matters. A conforming identity server is not just "our server." It is an implementation other systems can reason about without learning Sidecat's private conventions.
Identity and authority travel together
The exciting part is not only that an agent can have an identity. It is that identity and authority can be carried together without collapsing into one ambient secret.
A bearer token asks the world to trust possession. A signed, scoped, mission-aware request asks the world to verify a relationship: this agent key, this issuer, this approved context, this request, this point in time. That gives people and systems more places to say yes, no, not yet, expired, wrong key, wrong mission, wrong resource, or show me more.
That is important for agent systems, obviously. But it is also bigger than agents. It is a step toward identity management and authentication that can handle software acting on behalf of people without pretending every piece of software is just a human with a password. The future is full of agents. The good version of that future needs identity, authority, and evidence to be inspectable separately, then verified together.
Sidecat exists to make that kind of work possible. In this case, the system did exactly what it is supposed to do: it turned working pressure into useful feedback, and that feedback moved into the public record.