AAuth, agents, and the identity operating model

Dick Hardt shipped the second revision of AAuth this spring. I read it on a Sunday, which probably tells you everything about my weekend. It's a thoughtful protocol, and it's worth the time of anyone who's serious about how AI agents are going to operate inside real companies. What I want to write about, though, is the bigger shift it points to. Reading it crystallized something we've been circling at YeshID for a while.

What AAuth actually does

A short, fair description, because the design deserves one.

AAuth defines how an agent identifies itself with a URL and a self-published key, proves possession of that key on every request with HTTP Message Signatures, and gets scoped, time-bound authorization to take specific actions at a specific resource. The protocol is end-to-end about permissions, not just credentials. The agent's request to the auth server carries a required scope. The resource's challenge carries a required scope. The issued auth token carries the authorized scope. The resource can demand step-up authorization when a request needs more than the current token grants. Consent can be a short negotiation in a clarification chat rather than a binary yes or no. Auth servers in different domains can federate so an agent can reach across organizational boundaries without knowing the plumbing. And there is one principle in the draft I'd single out for praise, because it is correct and most of the industry is getting it wrong: every agent has a legal person behind it. In Hardt's words, there are no truly autonomous agents. There is always an accountable party. That is the right instinct and it aligns with how we think about non-human identity.

Read the draft. It's a careful piece of work on the request layer of agent-to-resource authorization.

Where I want to go next

A protocol like AAuth answers a precise question very well: what should this agent be permitted to do at this resource right now, and how is that permission expressed, bound, and proven. That is the request layer.

The strategic identity problem lives at a different layer, and that's the layer I think the industry keeps under-naming.

Here is the framing we've settled on. The identity market is being sliced the wrong way. IAM, IGA, SSPM, NHI, PAM, agent security. Each name is a product boundary. None of them is the customer's problem. The customer's problem is effective access:

Who or what can actually do what across the company, through which chain of users, groups, apps, accounts, credentials, grants, service accounts, automations, and agents.

That is the question modern identity has to answer. AAuth makes it easier to be precise about what is being granted at any single door. It is not trying to answer the question of what someone or something has already accumulated across the dozens of doors they walk through in a quarter.

Consider a small, ordinary case. Alex leaves the company. The IdP disables Alex's account. Necessary, not enough. Alex had created an OpenAI API key. That key powers a GitHub-monitoring bot. The bot reads GitHub using my token. It posts summaries into Slack through an OAuth grant authorized by David. A Notion-Slack integration syncs those messages into a product wiki. The workflow is active, useful, and risky. Deleting the key can break business-critical monitoring. Leaving it in place preserves a departed employee's credential inside production automation. No single product owns the full picture. The IdP disabled Alex. An NHI tool can find the key. An agent-security product can see the bot. An SSPM tool can flag the integration. An IGA tool can ask someone to review it. The thing that has to happen is not a finding. It is an operation across the entire path: identify the workflow, confirm legitimacy, assign a real owner, replace Alex's human-owned key with a governed service identity, rotate credentials, scope down David's grant, revoke residual access, verify the bot still works, update the graph, and preserve evidence.

That is access operations, not access review. And it is the layer that needs a control plane.

From access reviews to access operations

Access reviews ask "does this person still need this access?" That question still matters. It's too narrow to be the control plane. The better question is: what should the access state of the company be, and what actions are required to keep it correct continuously?

Access reviews are periodic. Access operations are continuous. Access reviews are retrospective. Access operations are corrective. Access reviews depend on human memory. Access operations use graph context, policy, ownership, usage, lifecycle state, and remediation history. Access reviews ask managers to approve entitlements they often do not fully understand. Access operations identify drift, determine the right fix, execute safely, verify the outcome, and escalate only the cases that need judgment.

Agents make this harder, not easier. Humans accumulate access at human speed. Agents accumulate and exercise it at machine speed, across domains, with delegation, and with the express design goal of discovering authorization needs at runtime. A clean protocol for getting tokens does not change that. If anything, doing the request layer well makes the state-management layer matter more, because agents will be opening more doors, more often, in more places, with more legitimate reasons.

The effective access graph

The graph is the map. Humans, app-local accounts, groups, roles, entitlements, service accounts, API keys, OAuth grants, bots, agents, integrations, workflows, resources, policies, approvals, lifecycle events, ownership, usage, dependencies, remediation history. One model. Real relationships: account belongs to group, group grants app role, user created API key, key is used by bot, bot reads repository, bot posts to Slack, Slack app has OAuth grant, grant was authorized by user, service account lacks owner, account belongs to terminated employee, credential powers production workflow, access violates policy, exception expires next week.

Without that graph, identity teams reconcile dashboards, spreadsheets, tickets, admin consoles, SIEM alerts, Slack messages, and tribal knowledge. That model does not scale. It collapses in the agent era.

With the graph, the next operator becomes obvious. Not a chatbot. Not a dashboard summary. Not an AI wrapper on access reviews. An identity agent that investigates access paths, reasons over policy, plans remediation, asks for approval when needed, executes changes, verifies outcomes, preserves evidence, and continuously moves the company toward correct access state.

That is the operating model identity has been missing.

The two layers

The reason I think AAuth is worth reading even if you never implement it is that it sharpens the layer it sits at. It says, with care: here is how an agent identifies itself, here is how it asks for permission, here is how that permission is bound, scoped, proven, and negotiated. Good.

Wrap around that protocol and you still need an operating model. Something that knows what should be true about access across the entire company, sees what is actually true across humans and non-humans, and continuously closes the gap. Something that can answer the harder question: not did this agent get the right token for this resource, but is the company's access state correct right now.

Identity is messy. A cleaner request-time protocol does not change that. Effective access is the new system of record, and the operator that maintains it is the new operating layer. Both are needed. The protocol is a careful answer to one question. The operating model is what makes it safe to live with the answer.