Decks › Agentic IAM ·
Agent identity
Who's calling?
Identity for the age of agents. Why autonomous agents are a new kind of principal, and why that means rethinking our auth protocols.
The question
You hand an AI agent one job: "book my Sydney conference trip under $2,000." It plans the flights and hotels and calls a travel Booking API to make it happen.
Who is calling, on whose behalf, and can they prove it? Hold that for the next 40 minutes; by the end you will have three answers.
Roadmap
Three things to take home.
What agent identity is
Not a human, not quite a workload. A new kind of principal with its own identity.
Why today's patterns fall short
OAuth bakes in assumptions that quietly stop being true the moment an agent is the caller.
The shape of the answers
How the industry is responding, with AAuth as one concrete, instructive example.
First a quick refresher on the world OAuth was built for.
Part one · the familiar ground
The world we built auth for.
Before agents, who was even calling? A person, and the software they signed in to. Let us re-teach that ground quickly, because every assumption starts here.
The world we built auth for
OAuth's home turf: the app acts as you.
A human signs in and consents once, and the app gets a token that represents them, their scopes, their standing. The app is a client: a vehicle for the token, not a party in its own right.
Authorization-code flow: the user consents, the app carries the token.
The world we built auth for · no human
No human at all: one back-end calls another.
Take the human out of that flow and you get OAuth's other half, the pattern we have refined for fifteen years: Service A calls Service B through a gateway that checks a token. With the client-credentials grant the service speaks for itself; proper workload identity (SPIFFE) does it better, with no shared secret to leak.
- The service proves who it is with a client id and secret (or a certificate).
- That identity was registered ahead of time, by a developer, at each server.
- The token it gets is a bearer token: hold it, and you can use it.
It is tempting to file an agent right here just another service-to-service call. It is not that simple, and the next act is about why.
What's baked in ⚑
Six quiet assumptions. Watch them.
Every one was the right call in 2012. We will knock each one down in a few slides, once an agent is the caller.
Pre-registered client
The caller is known ahead of time, registered at each server.
Bearer tokens
Hold the token, use the token. Nothing binds it to who carries it.
Scopes as permission
A scope is a standing grant, not the intent of one call.
Redirect and consent
A human at a browser is there to click approve.
TLS does the securing
No signatures. The channel is the security, not the message.
Build-time integrations
The app knows its APIs before it runs.
A short history · how we got here
But first, a little history.
Two of those assumptions, dropped signatures and bearer tokens, were deliberate trade-offs back in 2012. Worth two minutes to see why.
A short history
Plot twist: OAuth 1.0 signed every request.
Proof-of-possession is not a new idea. In 1.0, each request carried a signature proving you held the key. A stolen token was not enough.
A short history
2.0 traded signatures for TLS and bearer tokens.
Signing was painful, browser crypto was weak, and certificates were costly. So 2.0 dropped signatures and leaned on the secure channel instead.
Sign the message
Security at the application layer. Every request proves possession. Powerful, but fiddly to implement.
Secure the channel
Security moves to the transport layer (TLS). The token becomes a bearer credential. Simpler to adopt, weaker by default.
"OAuth 2.0 is a bad protocol. WS-* bad." Eran Hammer, lead editor, on resigning from the spec · 2012
A short history
Intercept the booking API's access token, or find it in a log, and you can book flights and charge the card on the user's account. Fine for a fixed backend; the core liability for an agent that carries tokens across services ⚑
A short history
A framework needs profiles. A protocol does not.
OAuth 2.0 is a base that only becomes usable once you bolt on extensions and pin the choices with a profile.
- OpenID Connect, the identity layer almost everyone uses, is itself a profile on top of OAuth.
- "We use OAuth2" is never enough. You must also name the flow, PKCE, the endpoints, the profile.
- A framework is hard to conformance-test. A protocol is not.
- Guardrail: OAuth is conformance-tested, but only its profiles (OIDC, FAPI). You test the profile, not bare OAuth.
Part two · the new caller
Now an agent is calling.
Everything so far assumed software a person registered ahead of time. Agents break that assumption on nearly every axis.
Enter agents
From an app to an agent, the actor changes.
An app is a client that carries your token. An agent is an actor with its own identity. Agents are not clients.
App · OAuth client
"load my dashboard." The token represents you; the app is just a vehicle. One principal, a bearer token, a pre-registered client. This is today's OAuth.
Task agent
"summarize my emails." A tightly bounded job, on your behalf, with its own identity. Two questions: can you do this, and did you consent to the agent doing it?
Autonomous agent
"book my Sydney trip." It plans its own steps and spawns sub-agents. Now an open-ended goal needs an agreed bound, and authority must survive the whole chain.
Each rung adds a problem the old model cannot answer. The rest of the talk is the answers.
Enter agents
An agent is not a pre-programmed app.
It decides what to do, and what to call, in the moment. The developer wrote the goal, not the path.
- Autonomous: it acts toward a goal without a coded script.
- Reasons about context: it interprets, plans, and adapts.
- Picks its tools at runtime: the next call is chosen as the task unfolds.
- Long-running: tasks can span minutes, hours, or days.
- Spawns sub-agents: it delegates pieces of the work to others.
Enter agents
Not a microservice with an LLM.
It is tempting to file an agent under Service A calls Service B. But a model, not code, decides what it does, and that quietly breaks four assumptions the service world was built on.
Intent
A service encodes intent in code you can test. An agent interprets a goal at runtime, so the same prompt can act differently each run.
Paths
A service's branches are baked in. An agent explores tools and APIs to find a path, sometimes one no one coded.
Dependencies
A service integrates with known APIs. An agent discovers tools and authority live; its reach is unknown until it reaches.
Delegation
A service runs with its own account. An agent carries a human's authority down a chain, attributed to every hop.
Framing after Christian Posta · "The Differences Between Microservices and AI Agents"
The reframing
Delegation is not impersonation.
This is the jump from client to actor. Hand the agent your token and it only acts as you. Give it its own identity and it acts on your behalf, with you still in the picture.
Acts as you
It reuses the user's own access token, just like an OAuth client. Every booking is logged as the user, and the agent inherits everything the user can do, not just travel.
Acts on your behalf
It calls with its own identity (on-behalf-of). Both principals are visible, so you can trace, scope, and revoke the agent on its own.
And your token is not even enough the agent often needs authority you do not have, like charging a corporate card you cannot. As its own principal, it brings its own.
The reframing
Human? Workload? Or a new layer?
Not human
Give it a human identity and it gets the standing of a person without any of the built-in constraints.
Not quite a workload
It runs somewhere, so workload identity fits at first. But agents are bursty, ephemeral, and pause and resume across clusters.
A new layer
It behaves like an actor. Agent identity sits on top of workload identity, and can collapse into it inside one trust domain, until it cannot.
Keep this it sets up the whole industry comparison later.
The reframing ⚑ callback
Every flag just fell.
| What we assumed ⚑ | What's true once an agent calls |
|---|---|
| Pre-registered client | Resources are discovered at runtime; client ids do not travel |
| Bearer tokens | Copied secrets leak somewhere they shouldn't |
| Scopes as permission | A scope is not the intent of a single call |
| Redirect and consent | Decisions happen mid-task, with no human at a browser |
| TLS does the securing | The channel is safe, but who is calling is still unproven |
| Build-time integrations | Tool chains assemble live, one call at a time |
Where it breaks · five ways
Now, watch it break.
Same booking agent, five concrete failures. Each one is an assumption from Part one collapsing under a single real call.
Where it breaks · 1 of 5
It crosses orgs. The trust doesn't.
Booking the trip touches your company's travel API, the airline's, then a payment processor: three different trust domains. Nothing about the agent carries trust from one into the next.
Pre-arranged trust
A client can self-publish its identity now (Client ID Metadata Document) and Cross-App Access can bridge domains, but each server still chooses which identities to trust, usually a pre-arranged list, for an app in a consent flow.
Trusted on first contact
An autonomous agent accepted the first time it reaches a resource in a domain you do not control, carrying who it is and whose authority, with no pre-arranged list and no human at a browser.
Park this self-publishing identity is the right instinct, and OAuth is reaching for it; AAuth takes it all the way, to the agent as a cross-domain actor.
Where it breaks · 2 of 5
Something broke. Who did it?
You said three words. A chain of decisions followed, and one of them charged the card.
With only the user's token, you are blamed for a decision you never made, by a system you did not directly control.
Where it breaks · 3 of 5
The token rides a chain today's OAuth doesn't enforce.
Hours later, several hops deep, agent → booking API → payment processor, across providers, and no one at a browser to approve anything.
- OAuth can record the chain (RFC 8693
actclaims), but the spec says prior actors are informational only, never enforced. - Making it enforceable takes yet another draft (verifiable actor-chains, attenuation tokens), so today a token hops deep and hours old is still accepted, no live check, no human in the loop.
OAuth's own standard admits it does not enforce the multi-hop chain
Where it breaks · 4 of 5
Same scope. Very different call.
A scope is standing permission. It cannot tell a helpful call from a harmful one, and a hijacked agent stays perfectly in scope.
Park this letting the resource decide at call time is exactly how AAuth answers it later.
Where it breaks · 5 of 5
A valid identity can take an invalid action.
Zero Trust worked when identity, device, and session were a good-enough proxy for what a caller would do. For agents, identity stops being a proxy for authority.
Centred on identity
Who is this? · Is the device healthy? · Does the session look normal?
Centred on delegated authority
Under whose authority? · What was approved? · What are the delegation bounds? · What is the lineage across sub-agents? · Is it still valid at the commit point?
"Identity is still necessary, but it is no longer enough. Zero Trust for agents has to center on delegated authority."Karl McGuinness · on Harish Peri's Zero Trust thread
Part three · the responses
So how is the industry answering?
Two fronts. The standards bodies are extending OAuth, a draft for every break. The platforms are building agent-identity layers of their own. We'll take each, then judge them by one lens.
How the industry is responding · the standards
There's an IETF spec for each. That's exactly the problem.
PAR and RAR already shipped as RFCs; everything else, even self-published client identity (Client ID Metadata Document), is still a draft.
Still no authoritative way for an agent to carry its identity and delegation across domains. Agents need a protocol of their own.The thesis · say it here, and again at the close
How the industry is responding · the platforms
Sometimes the workload is the agent.
We called an agent not quite a workload. Inside one trust domain it can be one, and Uber wrote up how: each agent is a Kubernetes workload anchored to SPIRE, in an Agent Registry, with one token service. Three invariants make it hold.
One-to-one mapping
One agent ↔ one workload. The token service checks the registry that this agent may run on this workload.
A registry
A single source of truth for which agent is which, the Agent Registry above.
Identity continuity
Stable across schedule, pause, and resume, anchored in that SPIRE credential.
The catch all three hold for Uber inside one trust domain. Let the agent roam cross-domain or lose the shared registry, and identity has to become a layer of its own.
Worked example · Uber, "Solving the Identity Crisis for AI Agents"
How the industry is responding
Collapse into workload identity, until you can't.
Google Agent Substrate + kagent
Distinct actors on a Kubernetes substrate, but holds the three invariants, so it can still collapse.
AWS AgentCore
Stable agent ARN above a churning microVM. AWS owns the stack.
Entra Agent ID
A specialized Entra service principal. Single vendor, one domain.
AAuth
Cloud-agnostic. Bootstraps from workload identity, no central plane.
Framing after Christian Posta · "What 'is' Agent Identity? Human? Workload? A new Layer?"
How the industry is responding
Entra Agent ID: an agent inside Entra.
A specialized Entra service principal, with rich enterprise identity and on-behalf-of flows already in place.
- A layer above the running workload, not the workload itself.
- Single vendor (Microsoft), inside one trust domain.
- A workload identity (e.g. a K8s service account) is exchanged for the agent's token, but the agent stays its own principal.
How the industry is responding
Agent Substrate: runtime actor identity.
Google's actor-sandboxing layer. Actors run in hardened microVM workers, with a registry that keeps their identity stable.
- Actors are multiplexed into pre-warmed worker pods at runtime.
- Identity stays continuous across pause, resume, and reschedule.
- Mainly a runtime and workload identity layer, and still collapsible.
How the industry is responding
AAuth: a cross-domain auth protocol.
From Dick Hardt, an author of OAuth 2.0. A layer above that bootstraps from workload identity rather than replacing it.
- Self-published identity for the agent as an actor,
aauth:local@domain, no pre-registration. - Works across trust boundaries, with no single central control plane.
- Designed to coexist with OAuth, not replace it.
The tell everything before AAuth assumed one control plane in one trust domain.
How the industry is responding
Overlapping, but different slices.
| Approach | What layer | Trust scope | The slice it solves |
|---|---|---|---|
| Agent Substrate | Runtime identity | Single domain | Identity continuity at runtime |
| Entra Agent ID | Identity provider | Single vendor | Enterprise agent identity and OBO |
| AAuth | Auth protocol | Cross-domain | Who, on whose behalf, across boundaries |
They are not competitors so much as different cuts of the problem. The one difference that matters: everything except AAuth assumes one control plane in one trust domain.
Part four · a closer look
How AAuth works. Then we run it live.
Four ideas first: its own identity, proof on every request, a server that gets a say, and a broker that speaks for you. Then a demo.
A closer look at AAuth
Every agent gets its own identity.
A cryptographic identifier per instance, bound to a key, published at a URL the agent controls. No portal, no shared secret.
Callback ⚑ these are the client ids that actually travel.
A closer look at AAuth
Every request is signed.
HTTP Message Signatures on every call. A stolen token is useless without the private key. The agent proves possession each time.
Callback ⚑ this removes the stolen-access-token problem.
A closer look at AAuth
The resource gets a say.
In OAuth the resource server is a passive token reader. In AAuth it signs a resource token describing exactly what it needs.
Because the resource signs the request, an attacker cannot swap in a different resource. It also prevents the confused-deputy problem and gives the resource a voice in every authorization.
A closer look at AAuth
The Person Server: the user's broker.
The user chooses it. The agent only ever talks to its Person Server, which holds the agent-to-person binding and brokers consent outward.
Three-party flow: the booking API asks, the Person Server brokers consent.
Live demo · switch to the terminal
Demo: AAuth in the .NET SDK.
Watch three things, the same three from the start.
- Who is calling. The agent has its own identity. No API key, no pre-registration.
- On whose behalf. A protected call pauses for consent through the Person Server.
- Can they prove it. Every request is signed. There is nothing to steal.
Beyond the demo · governance
A mission is context, not authorization.
A natural-language, user-approved, hash-bound statement of intent, like book my Sydney trip under $2,000, propose before booking, checked against a running mission log.
"A mission is not an authorization. It is just an agreed-upon context."Dick Hardt
- The agent identity sets the ceiling; the mission narrows it at runtime.
- Scopes and policy still authorize. The mission is an additional contextual gate.
- Per-call context can narrow what an agent does, never widen it.
Beyond the demo · governance
The resource decides at call time.
Some operations are granted outright; others are conditional and get re-checked against the actual parameters of the specific call.
Callback this is the answer to break four: intent versus scope, and prompt injection.
Beyond the demo · adoption
A sibling protocol, not a replacement.
You adopt it one mode at a time, and it wraps what you already run. Your read-only flight-search API keeps its OAuth; only the booking-and-charge path needs the full flow.
- A drop-in for API keys (identity mode) and for OAuth (resource-managed mode).
- It wraps existing OAuth and OIDC; the four modes are additive.
- Existing OAuth clients stay put; AAuth onboards a new class of agentic actors.
"OAuth works great where it is deployed. Why break what is working?"Dick Hardt
Wrapping up
An honest status check.
Hold the enthusiasm at the right level. This is a direction, not a finished standard.
- An early-stage, exploratory IETF draft, moving quickly.
- An open debate: is durable mission governance a protocol primitive, or a layer above?
- It coexists with OAuth, by design, rather than replacing it.
- A handful of exploratory SDKs, including the .NET one you just saw.
Wrapping up
That is how the booking agent earns the call: its own identity, a bounded mission the user approved, and a booking API that can still say "confirm this charge."
The protocol, the explainer, and the .NET SDK used in the demo.