AI Agent Identity: What Changed and What You Can't Skip

Florian Forster
Florian Forster

Founder and CEO

AI Agent Identity: What Changed, What Didn't, and What You Can No Longer Skip

Agents didn't break authentication, authorization, and accounting. They ended the era of doing the third one badly.

Every AI agent security conversation starts with the wrong question: what will the agent do? That question has no stable answer, and chasing it produces the wrong control. What an agent may touch, its tools, its resources, its maximum authority, can and should be written down. What nobody can write down is the sequence: the whole point of using an agent is that it composes steps you didn't script. Pre-approving the entire sequence is therefore a dead end. Constraining the envelope it happens inside, and requiring human approval for the rare high-impact action, is not.

The question with a stable answer is older than AI. Network operators wrote it down in the nineties and called it AAA: authentication (who is acting), authorization (what they're allowed to touch), and accounting (the record of who did what, and what it consumed). Over the last decade the industry mostly stopped saying the third A, and the observability tooling that grew up next to it watches systems, not principals: it rarely records who did what under whose authority. Agents didn't change the framework. They repriced the leg we stopped paying for.

So no, AI agents didn't change identity, and that's better news than the vendor version of this story. You don't need a new discipline. You need the one that already exists, applied to a new kind of actor, without the shortcuts we got away with when every actor was either a person or a cron job.

What is AI agent identity, and does an agent need its own?

AI agent identity is a first-class identity for an autonomous software agent: its own credential, its own lifecycle, its own audit trail, plus a recorded line of authority saying who or what authorized this agent, to do what, within which scope, for how long. When the agent acts for a user, that record is a delegation chain. When it runs on standing authority of its own, the grant itself is the record. Either way, the identity is distinct from the user who triggered the agent and not shared with anything else. It can perfectly well be implemented as a service account, as long as that account is dedicated to this one agent; what it can never be is a credential several workloads pass around. (The industry files agents under non-human identities, or NHI. What agents add to that bucket is the requirement that every grant of authority is traceable to a specific task and authorizing principal, which standard service-account practice doesn't give you.)

"Who is making this request" always had three answers, not two. A person. A machine process with a fixed job: the service account, the cron job, the CI runner. And a piece of software acting on a person's behalf under a scoped, revocable grant, the pattern OAuth has modeled since 2007. We built identity properly for the first two and treated the third as an integration detail: a consent screen at setup, a refresh token in a database, no further questions.

An AI agent is that third category with the throttle removed. It acts inside a session, often triggered by a person, keeps going after the person stops watching, and touches systems the person never explicitly named. (Not every agent acts for a person. Some run on their own organizational mandate, and some act for other agents. The identity requirement is the same; this post focuses on the on-behalf-of case because it's the one most companies hit first.) None of this requires a new authentication model. It requires actually using the one that exists: giving the agent its own identity instead of borrowing whatever was lying around.

Because the borrowed version has a name, and the name is the argument: impersonation. When an agent rides an employee's session or OAuth grant, every log line names a human for actions a process took. An audit trail that names the user when an agent acted is a lie, and the recorded delegation is what keeps it honest. RFC 8693 §1.3 draws exactly this line: impersonation makes the caller indistinguishable from the user, while delegation keeps both identities in the token, sub for the user, the act claim for the agent acting on their behalf.

Both patterns exist in the RFC for a reason, so let's be precise: "delegation, never impersonation" is our design position for agents, not a law of the protocol. The test behind the position is simple. Can the resource and the audit trail identify both the represented user and the acting agent, at the granularity you need? A user-subject token may name the calling app in client_id or azp, but an app id is not a specific agent or the grant it acted under, and most resource logs never record it anyway. Where a downstream API only understands user identity, preserve attribution at the layer you control: the gateway that holds the delegation.

If a request can't be traced to a specific agent identity, distinct from the human who kicked it off, you've lost the thread before anything has gone wrong.

How do you scope an AI agent's access? Token exchange, explained

Least privilege isn't new either. What's new is the blast radius of skipping it: seconds, not weeks.

It was never actually safe to leave humans over-permissioned. Stolen credentials sat at or near the top of the breach statistics for a decade, until the 2026 DBIR saw vulnerability exploitation overtake them as the leading way in. They didn't stop mattering; they stopped being first. A stolen credential doesn't take lunch breaks. That's why just-in-time access and privileged access management exist. But standing over-broad access used to be latent risk: someone had to steal it first. With an agent, nobody steals anything. We hand the access over on purpose, at setup, and the agent exercises the full grant at full speed as ordinary operation. Admin credentials don't carry intent. They carry permission. The agent doesn't malfunction when it uses them. It does exactly what it was allowed to do. The worst case became the default case.

Every agent setup answers two questions, whether or not anyone asked them out loud: whose identity does the agent act under, and where does its scope come from?

Actor identityScope sourceWhat you getVerdict
The user'sInherited wholesaleImpersonation. Audit trail names the employee for the agent's actions.Never
The user'sNarrowedStill impersonation, just scoped. It's still the user's identity acting.Never
The agent's ownWhatever was easiest to grantA dedicated account with a broad grant. Attribution fixed, blast radius not.Halfway
The agent's ownGranted at the point of delegationDelegation. sub = user, act = agent, scope = the subset actually granted.Do this

There's a fifth pattern that doesn't fit the table because nobody would design it, yet it's the most common one in the wild: pasting a personal access token into the agent's environment. The credential is the human's, the scope is whatever the token was cut with, often everything the human can reach, and the audit trail says a person did it. If that's your setup today, you're in good company, and it's the first thing to migrate off.

The mechanism for the bottom-right cell is the delegation pattern of OAuth 2.0 Token Exchange (RFC 8693, published January 2020). Used that way, the agent presents the user's token as the subject and its own token as the actor, and the authorization server issues a new token that carries both identities and only the scope the policy grants. Be precise about what the RFC itself promises, though: the actor token is optional, narrowing is a policy decision, and whether the result is a composite token is the server's call. The RFC supplies the verbs. Your authorization server's policy is what actually makes a delegation, which is exactly why this is an identity-layer decision and not a client-side trick.

None of it is rare or exotic: the standard has been published since January 2020 and the grant type is shipping in Zitadel today. The gap is partly support, because a working delegation also needs an authorization server that emits both identities and resource servers that read and log them, and that chain is uneven everywhere, our own current gaps included (see the disclosure below). And it's partly adoption, because even where the pieces exist, almost nobody routes agents through them. Handing an agent your session takes one line of configuration. Exchanging it for something narrower takes an afternoon, plus the one thing no protocol can generate: a written-down scope. "It needs to read some contracts" is not a scope. It's a justification for a scope someone hasn't written down yet.

Two clarifications that save pain later:

Scope to the task, not the calendar. "Read access to these three repositories, for this run, expiring when it finishes" beats "for a day." Notice that a sentence like that is more than an OAuth scope string: it names resources, actions, and a time bound. Expressing it takes audience restriction (RFC 8707 resource indicators), richer authorization data (RFC 9396), or a stored delegation the server checks on use. Plain scopes are where you start, not where this ends. Short-lived is normal here: the token-lifecycle design for Zitadel's next generation defaults access tokens to five minutes, with single-use rotating refresh tokens behind them.

Token exchange happens at issuance, not per request. It sets the ceiling on what a token can do. It doesn't judge each call against each resource as it happens. A valid, correctly scoped token is necessary, but it's still not sufficient. The per-request decision layer is what OpenID's AuthZEN working group standardizes; its Authorization API 1.0 went final in January 2026, and adoption everywhere is young. We'll take that layer apart in its own post.

(One more leg we're deliberately not covering here: how a tool the agent has never met decides to trust it at all. That's the client-registration story. The Model Context Protocol's November 2025 spec now recommends Client ID Metadata Documents for it, keeping Dynamic Client Registration as a backwards-compatibility fallback, and it deserves its own post too.)

How do you audit what an AI agent did, and how do you revoke it?

Here's where the record needs correcting, including by identity vendors: accounting was never optional. PCI DSS Requirement 10 has demanded access logging for two decades. HIPAA's audit controls (45 CFR §164.312(b)) and ISO 27001's logging control say the same. Identity platforms, Zitadel included, have shipped audit trails and SIEM streaming for years.

Accounting was the leg you could get away with doing badly: logs scattered per service, retained ninety days, and read for the first time when an auditor, or an incident, asks. A person with too much access who never used it wrong cost you nothing, and a slow forensic reconstruction still counted as recovery.

An agent removes the slack that made that tolerable. It doesn't pause between actions. It doesn't get tired, distracted, or cautious near the option it shouldn't take. By the time a person notices, the agent can be a hundred actions past the one that mattered. That makes two things non-negotiable:

1. Attribution to the agent, specifically. Not "the service account did something," but which agent, on whose authorization, doing what, to which resource, when, with what result. That sentence should be a schema, not a slogan. Here's the shape every action lands in, from the audit primitive we're designing in the open for Zitadel's next generation:

event_type       = request.api           # the action: an API call
occurred_at      = 2026-08-26T09:14:07Z  # when
actor_type       = agent
actor_id         = agent:report-bot
delegation_type  = exchanged             # RFC 8693 token exchange
delegation_id    = delegation-123
grantor          = user:alice            # who authorized the delegation
client_id        = agent_copilot
token_id         = tok_9d41x             # which credential was used
entity_type      = project
entity_id        = project:42
request_id       = req_01k3f8            # correlation across systems
payload.template = GET /projects/{id}/export
payload.status   = 200                   # allowed, and it succeeded

One row answers what was attempted, when, by whom, on whose behalf, through which mechanism, with which credential, to what, and how it ended. A refused request is the same row with a 403 in it, which is usually the row you want first. The design (ADR 048) treats every delegation shape as first-class: token exchange, an OIDC act claim, even the shared-PAT pattern. That way the setups you're migrating from stay visible while you do.

One honest boundary: this row is the identity plane plus Zitadel's own API surface. An identity provider can see authentication, token issuance, exchange, and revocation. It cannot see that an agent opened a specific file in a third-party system. Those actions have to be logged where they happen, by the connector or the resource itself, and joined back to the identity events through the delegation and token ids carried on every row. That join is the actual work of agent auditing, and it's why those ids are first-class columns rather than log-line trivia.

2. Revocation in one action, with a known window. One-action revocation is not a property tokens give you. It's a property you build. The delegation has to exist as a server-side object that sessions, refresh tokens, and exchanges are checked against, so that revoking it once cuts them all off on their next check. RFC 7009 leaves exactly this cascade to server policy, and token exchange creates no automatic link between input and output tokens. If nobody wired that linkage, one revoke revokes one token.

The window that remains is the already-issued, self-contained token at a resource that validates it entirely offline: fast, no round trip, and blind to revocation until the token expires. You can shrink that window three ways. Keep lifetimes in minutes, so the worst case is one token's life. Where minutes are still too long, distribute revocation state to the resource, through introspection or a deny list pushed and cached locally. And sender-constrain tokens where you can (RFC 9700, the OAuth security best practice, recommends it), so a stolen token is useless without the agent's key. That limits theft, though it revokes nothing by itself. Revocation also only reaches what the identity layer issued: a standing OAuth grant your agent holds directly at a third party gets revoked there, which is one more reason to route agent access through short-lived tokens you issue instead.

Anyone promising instant, universal revocation has either built and tested that linkage at every enforcement point, or isn't telling you about the window.

Without attribution and revocation, you don't have accountable agents. You have an agent you're hoping behaves, and a promise to yourself that you'll investigate if something looks wrong. (Accountability isn't all of agent security. Prompt-injection defense, sandboxing, and rate limits are their own disciplines. It's the part the rest report into.)

Should you connect an AI agent to your company's Google Drive?

Here's the version of all three legs that shows up first for most companies, not hypothetical, just boring and real: do you connect an AI agent to the company Drive? Say yes, and three questions follow, and none of them are new.

Whose identity does it act under when it opens a file? The default answer, the one most companies land on without deciding, is the employee's own OAuth grant with a broad scope like drive.readonly. The agent then isn't scoped to the task. It's scoped to the employee's entire access footprint: every shared drive, every folder a colleague shared in 2021, every file they forgot they could reach. That's what the grant it's borrowing actually contains.

What's it actually scoped to? Here's the part most posts skip: OAuth scopes alone cannot express the policy this task needs. Drive's scopes are coarse (drive, drive.readonly) or per-file (drive.file, which pins access to files the user picked or your app created). There is no "these three folders" scope. And for Drive, Google is the authorization server: no outside identity provider can narrow a grant Google issued. What's left are two workable designs, and the difference between them is the difference between an OAuth scope (what a token may do) and a resource ACL (what a principal may reach).

Design one stays inside Google: give the agent its own Google identity and share exactly the three folders with it, using Drive's normal permission model. Folder permissions apply to what's inside and can carry an expiration. Google now enforces reach, which is real enforcement. What it can't express is "for this task," and it doesn't record the delegation.

Design two puts a connector you control in the path: the agent keeps its own identity and no standing Google access, and the connector holds the employee's delegated authority, checks every call against the recorded grant ("these three folders, this run"), and writes each access to your audit trail with the agent as actor and the employee as grantor. One honesty note: a purpose only becomes enforceable once it's translated into resources, actions, and a time bound. A purpose string in a grant record is context for the audit trail, not a control.

The strongest setup combines them. Google's ACLs bound what's reachable at all, your connector bounds what this run may do now, and the audit trail joins the two. End to end it looks like this: the employee approves a delegation; the identity layer stores it and issues the agent a short-lived token naming both identities; the agent calls the connector; the connector checks the call against the stored grant and forwards only what passes, using its own narrowly-permissioned Drive access; the action lands in the audit trail with agent, grantor, and delegation id; and revoking the delegation cuts off the next call.

And if it goes wrong, do you find out from your logs, or from the person whose file turned up somewhere it shouldn't? Once you know, can you cut access in one action? If the answer involves revoking a Google grant, an API key, and a session token in three different consoles while the agent keeps running, you have an integration, not a kill switch.

If those three answers aren't clean, the problem isn't Google Drive and it isn't AI. It's that authentication, authorization, and accounting were never fully built out for anything acting on your behalf. That was survivable while the actor was a careful, slow, occasionally-absent human. It isn't survivable now that it's a fast one that never stops.

AI agent identity checklist: five things to verify before you connect an agent

  1. Own identity. The agent authenticates as itself: its own workload credential, managed for it alone (a private key, mTLS, or workload federation; never a password, never a secret shared between agents), its own lifecycle, distinct from every user and every other agent. No borrowed sessions, no shared service accounts.
  2. Recorded authority. Somewhere queryable, it says: this principal granted this agent this scope, at this time, until this expiry. For on-behalf-of work, both identities must reach your policy and audit systems, typically as sub and act in the token. Delegation, never impersonation.
  3. A written scope, bound to the task. A deliberate subset of the grantor's access, granted for the run and expiring with it, not "whatever the account had," not "for a day."
  4. Attributed accounting, on both planes. Identity events from your authorization server, action logs from the connector or resource, joined by delegation and token ids, queryable when you need answers, streamable to your SIEM, not merely retained.
  5. One-action revocation with a known window. One revoke ends the delegation and everything checked against it on the next call. In-flight self-contained tokens are bounded by a minutes-long TTL, sender-constrained where possible. Know the window. Keep it small.

Nothing on that list is exotic. It's the discipline identity systems have always claimed to provide for people, applied honestly to something that doesn't get tired, doesn't hesitate, and doesn't stop on its own. The companies that get hurt by agent access this year won't be facing a genuinely new threat. They'll be the ones who could already answer "who, what, and can you prove it" for their employees, and never had to answer it for anything else, until something started acting fast enough that not answering became expensive.

Where Zitadel stands

What you can use today: Zitadel ships RFC 8693 token exchange: composite tokens with the act claim identifying the actor, gated behind an explicit permission, with scope and audience reduction, and identity-plane audit events you can stream to your SIEM through the events API. Full disclosure, since this post leans on the distinction: today's implementation doesn't separate delegation from impersonation. The docs call both impersonation, the audit trail records token issuance and a "User impersonated" event rather than each downstream action, and RFC 8707 resource indicators aren't supported yet.

What we're building next, in the open: the gap between that and this post is exactly what Zitadel's next generation is for. Agents as first-class principals: schema-defined identities with their own authentication methods. Delegations stored as revocable objects with an explicit grantor, scope, and expiry, never a copy of the grantor's permissions (proposed in ADR 033). And an audit primitive that puts the delegation chain on every row (ADR 048). To be clear about the boundary: enforcement on third-party actions stays with your connector and the resource; nextgen's job is the delegation object, the tokens, and the identity-plane record their logs join to. The design discussions are public: read along, start with the preview, or join the waitlist to try it as it ships.

Terms in this post

  • Agent identity: a first-class identity for an autonomous software agent, with its own credential, own lifecycle, own audit trail.
  • Delegation: an explicit, audited transfer of authority from one principal to another; the token carries both identities.
  • Impersonation: the agent is indistinguishable from the user; attribution is lost by design.
  • act claim: the JWT claim (RFC 8693) naming the actor working on the subject's behalf; nests to record chains.
  • Token exchange: trading one token for another at the authorization server (RFC 8693); with an actor token and a narrowing policy, the delegation pattern of this post.
  • Non-human identity (NHI): the umbrella for machine principals such as service accounts and workload identities; agents are NHIs whose grants must additionally be traceable to a task and an authorizing principal.

Frequently asked questions

Does an AI agent need its own identity? Yes. An agent that borrows a user's session produces an audit trail that misattributes its actions to a person, and one that shares a service account can't be individually scoped or revoked. Its own identity, plus a recorded grant (this principal authorized this agent for this scope), is what makes attribution, least privilege, and one-action revocation possible.

What is the difference between delegation and impersonation? Impersonation means the agent is indistinguishable from the user: the resource sees the user, and attribution is lost by design. Delegation keeps both identities in the token: RFC 8693 puts the user in sub and the agent in the act claim, so systems built to read the claim can see who acted and on whose authority. The claim is discretionary, so resource servers and logs have to be taught to use it. Both are legitimate patterns in the RFC; for agents, delegation is the one that keeps the audit trail honest.

Can you scope an AI agent's Google Drive access to specific folders with OAuth scopes? No. Google Drive's OAuth scopes are coarse (drive, drive.readonly) or per-file (drive.file); no folder-level scope exists, and Google is the authorization server for Drive, so no external identity provider can narrow its grants. Folder-level restriction comes from Drive's own permission model (share specific folders with a dedicated agent identity) or from a connector you control enforcing a delegated, task-scoped grant.

How do you revoke an AI agent's access? Revoke the delegation at the identity layer, provided it exists as a server-side object that sessions, refresh tokens, and exchanges are checked against; that linkage is something you build and test, not a default. An already-issued token can outlive the revoke only where the resource validates it entirely offline, so keep lifetimes in minutes, distribute revocation state where that's still too long, and sender-constrain tokens to limit theft. Grants held directly at third parties must be revoked there.

Is an AI agent a non-human identity (NHI)? Yes, and it can even authenticate through a dedicated service account. What's not enough is standard service-account treatment, because an agent's authority changes shape: sometimes a standing grant of its own, sometimes delegated by a user for one task, sometimes received from another agent. Each grant must be traceable, who authorized this agent, to do what, until when, and that is the part standard NHI practice doesn't capture.

Sources and further reading

Liked it? Share it!