Your AI agent doesn't have an ID. It borrows yours.

Here’s a small, uncomfortable fact about the AI agents everyone is rushing to deploy.

When your agent books a flight, files a ticket, queries a database, or calls another service on your behalf, it usually authenticates by borrowing a secret that belongs to you - an API key, an OAuth token, a session cookie. It has no identity of its own. To the service on the other end, there is no “the agent.” There is only you, or the application that wrapped you, holding a key that could just as easily have been copied by anyone.

For a chatbot that answers questions, that’s fine. For an autonomous system that plans, chains together services it has never seen before, spends money, and keeps working while you’re asleep, it’s a genuine problem - one that touches security, accountability, and governance all at once.

A new Internet-Draft called AAuth (Agent Authorization) is one of the more serious attempts to fix it. It’s worth understanding not because it’s guaranteed to become the standard - it isn’t, and I’ll be honest about that throughout - but because it names the problem unusually clearly and proposes a concrete, buildable answer.

This post walks through what AAuth is, the specific cracks it’s trying to fill, and how it works, in language aimed at anyone technical-adjacent. Where I’m summarizing the specification I’ll say so; where I’m interpreting or editorializing, I’ll flag it.

A note on sources and freshness. Everything here is grounded in the AAuth Protocol Internet-Draft (draft-hardt-oauth-aauth-protocol) and the author’s own explainer at aauth.dev. I’m writing against draft revision -09, which I read directly, cross-checked against the public IETF datatracker in mid-2026. This is a fast-moving individual draft - details, endpoint names, and even the exact revision number will have changed by the time you read this. Treat specifics as “true as of -09, verify against the live spec,” not gospel.

TL;DR

The problem: AI agents have no independent identity. They authenticate by holding copyable secrets (API keys, bearer tokens) that belong to a user or app. Anything copyable eventually leaks, and a stolen secret works for whoever holds it.
The core idea: Give every agent its own cryptographic identity - an identifier like aauth:local@domain bound to a private signing key. The agent signs every request instead of carrying a password. Steal the token, and it’s useless without the key.
Who’s behind it: Dick Hardt, the editor of OAuth 2.0 itself, who concluded OAuth doesn’t fit AI agents after building authorization for an MCP server.
The shape: Four “access modes” that climb from replace your API keys up to full cross-company policy federation. You adopt only as far as you need. Plus a genuinely new idea - missions - that lets you govern an agent by its declared intent, in plain language.
The honest status: An early, rapidly iterating individual IETF draft - not an adopted standard, and not the only proposal in this space. Whether it wins is unknown. The problems it names are real regardless.

Part 1 - The quiet problem: agents borrow your keys

Software used to be written. A developer decided, at build time, exactly which services an application would call and what permissions it needed. You registered the app once at each service’s developer portal, got a client ID and a secret, wired them in, and shipped. The list of integrations was fixed and known in advance.

AI agents don’t work like that. They discover what they need at runtime. They assemble a chain of tool calls one step at a time, deciding the next move as a task unfolds. They run long tasks that cross between different companies and clouds. And they routinely need a decision - a “yes, go ahead” - in the middle of a task, long after the human who started them has walked away.

The authentication machinery underneath was built for the old world. When you drop an autonomous agent onto it, the seams start to show. Let’s look at exactly where.

Part 2 - Why the tools we already have don’t fit

AAuth’s framing of the problem is sharp enough that it’s worth going through the specific cracks. None of these are exotic - they’re all things any engineer who has wired up an agent has bumped into.

1. Identities don’t travel between services. In OAuth and OpenID Connect - the standards behind almost every “Sign in with…” button - a client has no identity of its own. A client ID issued by Google is meaningless at GitHub. The client only “exists” in the context of each server it has pre-registered with. That made sense when a human developer could visit each portal once. It falls apart when an agent needs to touch a dozen services it has never registered with.

2. Copied secrets leak. Always. API keys are the purest version of the old model: a shared secret that a service issues and you copy into wherever your code runs, then present as a bearer credential. The draft puts the core truth bluntly - any secret that has to be copied to where a workload runs will, eventually, get copied somewhere it shouldn’t. And a bearer credential works for whoever holds it. Steal it, and you are the client.

3. Consent arrives late - and “waiting” isn’t a supported state. An agent frequently needs a human’s approval partway through a task (“this purchase is over your limit - okay?”). But approvals happen on human timelines, which might be minutes or hours. Today’s protocols tend to treat “pending, waiting for a human” as an error rather than a normal, first-class part of the flow.

4. Scopes describe access, not intent. A permission - a “scope” like mail.read - is standing access. It looks exactly the same whether the agent is summarizing your inbox or quietly scraping it. For an autonomous system making its own choices, why it’s acting right now matters as much as what it’s allowed to touch, and scopes simply can’t express that.

5. Tool chains assemble live. The sequence of calls an agent makes isn’t written into its code. It picks the next tool as it goes, and the chain shifts with every task. Authorization models that assume a fixed, declared set of integrations have nothing to grab onto.

6. Work crosses trust boundaries. Enterprise “workload identity” systems like SPIFFE and WIMSE are genuinely good - a workload can prove who it is without shared secrets. But they operate within a single organization’s trust domain. They don’t help an agent that needs to reach across organizational borders, or a developer’s tool running outside any enterprise platform at all.

Put those six together and a pattern emerges: the thing that’s missing is an identity for the client itself - one that it carries with it, that any party can verify, and that survives crossing between services and companies.

Part 3 - The one idea worth remembering

If you take away a single sentence from this whole post, make it this one:

Give every agent its own cryptographic identity, and have it sign every request instead of carrying a password.

That’s AAuth’s foundation. Concretely:

Each agent gets an identifier of the form aauth:local@domain - think of it like an email address for the agent, where domain belongs to whoever issued it.
That identifier is bound to a private signing key that lives with the agent and never leaves it.
The agent’s public key is published at a well-known URL, so any party can look it up and verify a signature - no pre-registration, no shared secret, no dependency on a particular central server.
On every request, the agent produces a cryptographic signature over that request. The receiving service checks it against the published public key.

The security payoff is the part worth sitting with. A bearer token (an API key, a cookie) is dangerous because possession equals authority - whoever holds the bytes wins. A signed request is different: even if an attacker intercepts the token, it’s worthless without the private key, which never travelled. Cryptographers call this proof-of-possession. In plain terms: the agent doesn’t just claim to be who it says - it proves it, on every single call.

That’s it. Everything else in AAuth - modes, tokens, missions, federation - is built incrementally on top of that one move.

Part 4 - Who’s proposing this, and why that matters

It would be easy to dismiss “yet another auth protocol.” What makes AAuth worth a second look is who wrote it and why.

AAuth comes from Dick Hardt - and here’s the detail that should raise an eyebrow: Hardt was the editor of OAuth 2.0 itself (the person listed as “Ed.” on RFC 6749, the framework the modern web runs its logins on). He’s also a co-author of the in-progress OAuth 2.1.

By his own account on aauth.dev, the origin story is this: after implementing authorization for an MCP server - the “Model Context Protocol” used to connect AI models to tools - he concluded that OAuth simply isn’t a good fit for that world, and started working with others in the identity community who’d hit the same walls. AAuth is what came out of it.

His one-line thesis is the cleanest summary of the whole effort:

“The web gave servers identity. It’s time clients got the same.”

Dick Hardt, aauth.dev

You don’t have to agree that AAuth is the answer to take the diagnosis seriously. When the person who edited OAuth 2.0 says OAuth 2.0 isn’t enough for agents, that’s a signal worth weighing - though, in fairness, it’s also exactly the kind of claim an author is motivated to make about their own new proposal. Judge the design on its merits.

Part 5 - The four access modes: a ladder, not a leap

The single smartest design decision in AAuth, in my reading, is that it’s incremental. You don’t have to swallow the whole thing. It defines four “resource access modes” that climb from trivially simple to fully featured, and - crucially - every party can adopt independently, with no coordinated migration. A service that doesn’t understand AAuth just ignores the signatures and keeps working.

Here are the four rungs, in plain language:

Rung 1 - Identity-based access. Replaces API keys. The agent signs its request; the service verifies who it is and applies its own access rules. There’s no authorization dance and no extra tokens - just cryptographic identity in place of a shared secret. This is the “drop-in for API keys” mode, and it involves only the agent and the resource.

Rung 2 - Resource-managed access (two-party). Replaces OAuth. The service keeps whatever authorization it already has - consent screens, existing OAuth tokens, sessions - and simply wraps it. It hands back its own token, but bound to the agent’s signature so it can’t be stolen and replayed as a standalone bearer token. Still just the agent and the resource; still no new central party.

Rung 3 - Person-server access (three-party). Now a new character enters: a person server that speaks for you. It’s a server you choose (not one imposed by anyone else) that can prove who you are to a resource, handle consent on your behalf, and keep an audit trail - and it works across many services without each of them having to set you up in advance.

Rung 4 - Federated access (four-party). The most capable mode. The resource has its own policy engine (an “access server”), and your person server negotiates with it directly. This is what enables agents to cross organizational borders under real policy control.

The important property: each step is optional and additive. A service that adopts only Rung 1 still gets real value (leak-proof identity instead of API keys). It never has to climb higher than its needs require. That’s a very different adoption story from “rip everything out and migrate.”

Part 6 - The cast of characters (and the three tokens)

To read anything else about AAuth, it helps to know the players. The specification is careful about roles, and once you have them, the flows make sense.

Person - a human or an organization: the legal party on whose behalf the agent acts, and who is ultimately accountable for what it does.
Agent - the HTTP client acting for the person, identified by that aauth:local@domain URI.
Agent Provider (AP) - the server that vouches for the agent’s identity by issuing it an “agent token.” Think of it as the passport office for agents.
Resource - the service being accessed (an API, a data store). It may enforce its own policy or delegate that to an access server.
Person Server (PS) - the server that represents you to everything else: manages missions, handles consent, asserts your identity, brokers authorization. You pick it, and you can move to a different one whenever you like.
Access Server (AS) - a policy engine that evaluates requests and issues access on a resource’s behalf, in the four-party mode.

And three kinds of token, each a signed JWT tied to whoever issued it:

Agent token - establishes who the agent is (issued by the agent provider).
Resource token - describes what access is being requested (issued by the resource).
Auth token - actually grants access, carrying identity claims and/or authorized scopes (issued by a person server or access server).

You don’t need to memorize this. The mental model is enough: an agent has a verifiable identity, it asks a resource what it needs, and a party you trust turns that into a grant - all signed, all bound to keys, no copyable bearer secrets in the mix.

One privacy detail worth calling out, because it’s a nice touch: the person server can hand each resource a different, pairwise identifier for the same user. So two services you use can’t quietly compare notes and realize you’re the same person. Identity without automatic cross-site correlation.

Part 7 - Missions: the genuinely new idea

If Rungs 1-4 are AAuth catching authentication up to the agent era, missions are where it tries to get ahead of it. This is the part I find most interesting, and it’s the piece that most directly answers “scopes describe access, not intent.”

A mission is a short, human-readable description - written in plain language - of what the agent is actually trying to accomplish. The agent proposes it; you (through your person server) review, maybe ask a clarifying question or two, and approve it once. From that point on, the approved mission is fixed - it can’t be quietly edited out from under you, because it’s pinned by a cryptographic hash of its contents.

Here’s why that’s powerful. Instead of every request being judged only against a static permission list, each action can be weighed against the mission:

“Does this next step actually fit the mission I agreed to?”

That question can be answered by a human or by an AI acting as the decision-maker - and it can catch things a fixed rulebook never could. mail.read can’t tell “summarize my inbox” apart from “scrape my inbox,” but a mission can: one is on-mission, the other isn’t.

Around missions, the person server offers a few concrete governance tools:

A mission log - an ordered record of every interaction in the mission, so the whole thing can be reconstructed later for audit or investigation.
A permission step for sensitive actions the agent wants to take that aren’t governed by any remote resource (tool calls, file writes, sending a message).
An interaction channel to reach you mid-task - relay a question, forward a payment approval, or propose that the mission is complete.
A clarification chat - during consent, you can ask the agent questions, and it can explain itself or adjust its request before you approve.

My editorial read: missions are the most ambitious and least battle-tested part of the design. They’re also the most honest about what agent governance actually requires - because a lot of the decisions we want to make about autonomous agents genuinely can’t be reduced to machine-evaluable rules written in advance. Whether “a plain-language mission plus a hash” is a strong enough container for that is exactly the kind of thing that needs real-world implementation to settle. (It’s telling that “missions” were added as a first-class object partway through the draft’s life, and remain actively debated in the community - a sign this is live design, not settled fact.)

Part 8 - What actually makes it safer (and where it’s honest about limits)

A protocol’s security story is only as good as its willingness to name its own weak points. AAuth’s does reasonably well on that front. The genuine improvements:

No bearer tokens anywhere. Every credential is bound to a signing key and is useless without it. This is the single biggest change from the status quo.
Proof-of-possession on every request. A stolen token can’t be replayed by someone who doesn’t hold the key.
Confused-deputy protection. Resource tokens are bound to a specific resource’s identity, which blocks a class of attacks where one service is tricked into acting for another.
Layered revocation. Multiple parties - the agent provider, your person server, the access server - can each independently deny renewal or revoke access. Short token lifetimes shrink the window between “revoke” and “expired.”
Accountability by construction. The spec insists each agent is bound to exactly one accountable person. Every action an agent takes traces back to a single party - which is precisely what enterprise audit and incident response need.

And the limits it’s upfront about - which I appreciate, because a spec that only lists its strengths is a spec to be suspicious of:

The person server is a high-value target. It sees every authorization an agent makes. Compromise it and you’ve compromised a lot. The design leans on “you chose it and can leave it” plus the option to delegate authentication and policy elsewhere, but centralization risk is real and acknowledged.
Signatures prove authenticity at request time, not forever. Agent keys are short-lived and rotated, so once a key is retired you can’t re-verify an old signature by re-fetching the public key later. If you need durable, long-term non-repudiation (for compliance, say), you have to capture the evidence at the moment of verification - the draft spells out how, and is clear this trades some privacy for that durability.
All input is untrusted. Justifications, mission descriptions, clarification replies - all of it can come from an adversary and must be sanitized before it’s shown to a human. (This matters especially because so much of it is free-form Markdown that gets rendered.)

That last cluster is the mark of a design that’s been thought about seriously rather than sketched.

Part 9 - How it fits with OAuth (it doesn’t kill it)

A fair worry when a new protocol appears is: does adopting it mean tearing out what I have? For AAuth, the answer is no, by design.

It’s built to coexist with OAuth 2.0 and OpenID Connect, not replace them.
It reuses their vocabulary - the same scope values and identity claims - specifically to lower the cost of adoption for services that already speak OIDC.
It follows familiar patterns: publishing metadata at well-known URLs and signing keys via JWKS endpoints, the same way OAuth and OIDC discovery already work.
The whole thing rests on existing web standards, chiefly HTTP Message Signatures (RFC 9421) for the signing.

And the adoption model is deliberately un-dramatic: a service that recognizes AAuth signatures verifies them; one that doesn’t ignores them and keeps working. There’s no flag-day, no central coordinator, no requirement that everyone move at once. Each party climbs the ladder on its own schedule.

Part 10 - Where this actually stands (the honest part)

This is the section I’d want a reader to remember if they remember only one, because the temptation with a clean new protocol is to assume it’s further along than it is.

It is an individual IETF Internet-Draft - not an adopted standard. Anyone can publish an Internet-Draft; doing so confers no official standing. As of the revision I read, it targets the security area but has no working group formally behind it yet. There is real momentum around it - a family of related drafts (bootstrapping guidance, an events spec, an exploratory “rich resource requests” vocabulary), open-source SDKs in a few languages, a demo you can run against a live test resource, community Slack channels, and in-person meetups. But momentum is not ratification.

It is not the only proposal in this space. Other efforts are floating extensions to OAuth 2.0 to handle AI-agent authentication and authorization rather than a new protocol. The industry has very much not converged on an approach. Reasonable, expert people disagree about whether agents need a whole new protocol or whether OAuth can be stretched to fit.

Whether AAuth becomes the standard is genuinely unknown - and I’d be suspicious of anyone who tells you they know. New protocols face a brutal chicken-and-egg problem: resources won’t implement it until agents use it, and agents won’t use it until resources implement it. AAuth’s incremental, “ignore-it-if-you-don’t-support-it” design is a smart hedge against exactly that, but plenty of well-designed protocols never reach escape velocity.

None of that makes it a waste of time to understand. The problems AAuth names - no client identity, leaky secrets, mid-task consent, intent versus access, cross-domain trust - are real, and they’re going to have to be solved by something, whether that something is AAuth, an OAuth extension, or an idea not yet written down. Understanding the clearest articulation of the problem is useful no matter which answer wins.

Part 11 - How to look closer

If this made you curious, a few concrete next steps (all first-party sources):

Read the draft. The IETF datatracker page for the AAuth Protocol is the authoritative spec: datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol. It’s readable, with wire-level examples of every flow.
Start with the explainer. aauth.dev lays out the “what changed” case and has an interactive protocol explorer.
Try it hands-on. There’s a walkthrough that bootstraps a real agent identity and makes signed calls to a test resource, which you can drive from a CLI agent. It’s the fastest way to feel the difference between a signed request and a bearer token.
Watch the design argue with itself. The GitHub repo (github.com/dickhardt/AAuth) has the open issues and discussions - the best place to see which parts (missions especially) are still contested.

I’d genuinely encourage forming your own view rather than taking mine. I’ve tried to represent the design fairly and flag where I’m interpreting versus reporting, but I have opinions (I think the incremental-adoption story is the strongest part and the missions layer is the most interesting-but-unproven), and you should discount them accordingly.

The question underneath it all

Strip away the tokens and the RFC numbers and AAuth is really about a single question we’re going to have to answer as AI agents move from demos into real infrastructure:

Do we keep letting agents borrow our passwords - or do we give them identities of their own that we can actually govern?

AAuth is one serious, well-argued proposal for the second path, from someone with the credibility to make it. It might win. It might not. But the question isn’t going away, and it’s a good one to have thought about before the systems you depend on quietly answer it for you.

Written from a close reading of the AAuth Protocol Internet-Draft (revision -09) and the author’s explainer at aauth.dev, cross-checked against the public IETF datatracker in mid-2026. Because this is a fast-moving draft, verify any specific detail against the live specification before relying on it. Corrections welcome.

Found this useful? I write about agentic AI and open source.
More posts · GitHub