Identity for AI Agents: A Technical Primer

TL;DR

An agent's core identity problem is that it's neither a human user nor a service account, and most IAM systems only have those two boxes to file it under. Force it into either one and something that should be attributable and revocable ends up being neither.

The agent inherits a person's session, chains calls across tools that were never introduced to each other, and every one of those calls looks, in a log, exactly like the shared identity behind it did all of it directly.

The instinct is to hand the agent the same OAuth scopes a human-facing app would get: read calendar, send email. That's enough to run and far too coarse to say afterward which specific action the agent took, and on whose authority.

We don't think this needs a new standard. Most of the pieces already exist: OAuth, MCP, an audit pipeline. What's missing is treating the agent itself as a distinct principal, narrower than the user it acts for, sitting in front of the tools rather than blended into them.

Overview

Enterprise software has run on two kinds of principal for two decades: a human who authenticates with credentials, and a machine that runs under a service account. Every permission, every log line, every revocation path assumes one of those two shapes. An agent is neither. It's software that acts, but it acts on a specific person's behalf, across tools that were never designed to recognize it as anything other than that person.

That mismatch isn't cosmetic. It's the reason "which agent did this, and under what authority" is often unanswerable in systems that were perfectly capable of answering "which user did this" for years. This primer covers what closes that gap: treating the agent as its own principal, scoping what it can do at the level of individual actions rather than whole applications, propagating that scope correctly through delegation, and tying MCP and OAuth into an architecture that can actually answer for what happened.

Why Agents Need Identity

A service account was never meant to carry this weight. It was built for a static piece of software running the same operation forever, and its permissions were sized once, at setup, for that one job. An agent doesn't have one job. It calls a variable set of tools depending on the request, interprets ambiguous instructions instead of executing a fixed routine, and can chain those calls into sequences nobody explicitly authorized step by step.

Without a distinct identity, every one of those actions is attributed to whatever shared account the agent runs under, which means an audit log can tell you the account acted and nothing about which agent, on whose behalf, doing what the person actually asked for. That's not a hypothetical gap. It's the direct consequence of putting software that improvises into an identity model built for software that doesn't.

We'd argue this is the actual reason agent security incidents read as confusing after the fact: not that nothing was logged, but that what was logged points at a service account instead of the specific agent and instruction that produced the action.

The Agent as a First-Class Principal

The fix starts with modeling the agent as its own principal: its own identifier, its own credentials, its own permissions, distinct from the person who deployed it. Those permissions shouldn't stand on their own, though. They're derived, narrowed from what the user is allowed to do down to the specific slice the agent actually needs.

A useful way to state it: an agent's authority is the intersection of what the user is permitted to do and what the agent has been separately scoped to do. Neither half is sufficient by itself. Anchoring authority to the user is what makes attribution and revocation possible in the first place. Layering the agent's own, narrower scope on top is what keeps a broadly permissioned user from handing an agent more reach than the specific task warrants.

Scopes and Delegation

Standard OAuth scopes operate at the level of an application: read calendar, send email. That granularity was fine when one scope corresponded to one integration doing one kind of thing. It's too coarse for an agent that might take dozens of distinct actions inside a single connected app over the course of one task. A usable agent identity system needs scopes written at the level of the action itself: read documents tagged a certain way, draft but not send a message, adjust a record under a defined threshold, each evaluated on its own at the moment the agent tries to use it.

Delegation adds a second dimension worth getting right early. Take a planning agent that hands a subtask to a worker agent to fetch and summarize a document. The worker should inherit a strictly narrower slice of permission than the planner held, never an equal or broader one, and the chain has to preserve the link back to the original user no matter how many hops it passes through. A delegation chain that can widen scope at any hop has already defeated the reason scoping existed.

MCP and OAuth: How They Fit

MCP is the emerging protocol for how an agent discovers and calls external tools. It standardizes the wire format: how a tool is described, how a call is shaped, how a result comes back. What it doesn't answer is the question that actually matters for security: who is this agent, and what have they been permitted to do. A companion post in this series works through that gap in more detail; here's the short version.

That's the identity layer's job, sitting in front of the MCP servers rather than folded into them. The pattern is straightforward: the agent authenticates to the identity layer, the layer resolves the user's permissions and checks them against the agent's own scope, it mints a short-lived token bound to that specific action, and only then does the call reach the tool. OAuth supplies the token mechanics underneath this: issuance, refresh, expiry. The identity layer is what decides whether a token gets minted at all, and what it's allowed to be used for.

Audit and Revocation

Identity that produces no record is unverifiable, which for practical purposes means it isn't identity at all. Every action that passes through the identity layer should leave an immutable trace: which agent, acting for which user, called which tool, with what input, and what came back. That record belongs somewhere durable and queryable, not scattered across each tool's own logs where nobody can reassemble the sequence later.

Revocation is what makes the identity worth having in a moment that matters: a user offboards, a credential turns up somewhere it shouldn't, an agent starts doing something its owner didn't expect. The identity layer needs a way to cut that agent off immediately, and a long-lived token that only expires on its own schedule isn't fast enough for that moment. The practical fix is checking current permissions on every call rather than trusting a token's face value for its full lifetime, so a change made at the identity layer takes effect on the very next request instead of whenever the token happens to lapse.

Reference Architecture

Put the pieces together and a production agent identity layer tends to have five parts working together.

Agent registry (per-agent identity, bound to user) --> Permissions layer (action-level scopes) --> Token broker (mints short-lived, scoped token) --> MCP server / tool Token broker also writes to --> Audit pipeline (immutable record) -->

Figure 1 — A request's path through the identity layer. Every hop narrows what the next one can do, and the audit pipeline records the path regardless of which hop the call ultimately reaches.

The five: an upstream identity provider integration that inherits human identity rather than reinventing it; an agent registry holding per-agent identities bound to a user, with a real lifecycle of deploy, rotate, and revoke; a permissions layer evaluating action-level, time-bound scopes on every call rather than once at setup; a token broker handling the OAuth mechanics, storage, and refresh for every downstream system; and an audit pipeline that's immutable and exportable to wherever the rest of the enterprise already looks for security events.

None of the five is exotic on its own. What's easy to get wrong is treating any one of them as sufficient by itself, a registry without a permissions layer just tells you the agent exists, and a permissions layer without a broker has nowhere to enforce what it decided.

Conclusion

The gap traditional IAM has with agents isn't that the underlying primitives are wrong. OAuth still works. An identity provider still works. The gap is that nothing in that stack was built with a principal that acts on someone else's behalf, chains across tools that don't know about each other, and needs its authority narrowed and checked on every single call rather than once at login.

We think the teams that get this right treat the agent as a first-class identity from the start, rather than patching attribution on after an incident makes the gap obvious. Per-agent identity, action-level scopes, delegation that only ever narrows, and an audit trail that can actually answer "who did this and why" are the pieces that make an agent something you can trust with real authority, instead of something you hope behaves.