---
title: "AI Agent Identity: Stop Classifying the Agent, Start Describing the Action"
description: "Identity reviews for agents stall on whether the thing is a person or a workload. The question has no answer, and a better one already has standards behind it."
author: "Renn Calloway"
category: "Defensive Architecture & Security Controls"
date: 2026-10-19T17:40:07.892Z
canonical: "https://agenticcyber.co/blog/ai-agent-identity-an-agent-is-neither-a-user-nor-a-service"
---

# AI Agent Identity: Stop Classifying the Agent, Start Describing the Action

![man, stop, statue](https://cdn.pixabay.com/photo/2020/11/01/09/40/man-5703248_1280.jpg?w=1200&q=75)

> Identity reviews for agents stall on whether the thing is a person or a workload. The question has no answer, and a better one already has standards behind it.

Identity reviews for a new agent tend to open with a classification problem. Human-style account, or machine account? Everyone in the room has a view, the discussion runs for forty minutes, and the design document ends up recording whichever answer the loudest architect preferred. The classification was never the decision that mattered.

Aembit has published a thoughtful piece naming the underlying difficulty: agents sit outside both existing models, so the company argues for a third category it calls agentic identity. The diagnosis is right. The remedy, a fresh label, is where our view diverges, because the engineering difficulty does not sit at the level of categories at all. Below: why the binary keeps surviving design review, three ways it fails once traffic is real, and the arrangement we would build in its place. Everything after the third heading is operational.

## Why the User-or-Service Question Keeps Getting Asked

The binary survives because each half corresponds to tooling an identity team already runs. One half assumes a predictable person with a durable account and a joiner-mover-leaver process behind it. The other assumes fixed code whose grants a reviewer provisions once and revisits at audit time. Both assumptions carry weight, and an agent honours neither of them. Aembit's own framing describes this software as dynamic and non-deterministic, and suggests matching the access an agent needs to the function it performs.

Credit where it is due: Apurva Davé, writing for Aembit, concedes in the same post that the idea is ["not yet a fully formed concept"](https://aembit.io/blog/what-kind-of-identity-should-your-ai-agent-have/). The field is better off for people saying that out loud instead of selling certainty.

Where a choice made per agent falls apart is across time. One deployment is several different things over the course of a day. First thing in the morning it works through a named employee's request. Mid-afternoon it executes on a schedule with nobody watching. An hour later it picks up a task that a second piece of software handed to it. A category fixed once, during design, describes none of those three situations accurately, and every authorisation decision downstream turns on telling them apart.

## The Three Failures That Follow the Wrong Question

Three patterns recur wherever a team picks a type and considers identity closed.

- **Inherited reach.** The agent borrows a person's credential and acquires everything that person can touch. An employee entitled to read the full customer base now has software entitled to read it, and that software takes direction from prose rather than from the employee.

- **Calls nobody can attribute.** A shared machine account presents itself downstream. The receiving system records the account, which tells an investigator nothing about which agent ran, which task it was serving, or which person set it off.

- **Mode changes nobody documented.** A single credential serves both the attended and the unattended route. Reviewers scrutinise the attended one, since that is what the specification describes, and the unattended route reaches production without the same attention.

A closely related trap sits in the Model Context Protocol's security guidance, which treats a server honouring a credential minted for some other resource as a broken audience boundary and a loss of accountability at the same time. Our write-up of [the confused deputy condition in MCP authorisation](/mcp-server-authorization-token-audience-confused-deputy) walks that case through end to end.

## Identity Belongs to the Action, Not the Actor

Give up on categorising the agent. Attach an identity to each chain of actions instead, and require that identity to carry two facts at once: which piece of software is running, and whose authority stands behind it at this moment.

OAuth already supplies the vocabulary, which is the strongest argument against minting a new one. [RFC 8693 separates delegation from impersonation](https://www.rfc-editor.org/rfc/rfc8693.html): under delegation semantics a principal retains an identity of its own, distinct from the party on whose behalf it is working, whereas impersonation transfers the target's rights wholesale and erases the distinction. The same specification defines an actor claim, which is how a token carries the fact that delegation happened rather than leaving a reader to infer it.

Delegation is the safer default here, and the one worth insisting on while a design is still on a whiteboard, because the issued token names two parties and a downstream log line can therefore name two parties as well. That also restates the agentic identity proposal in terms an engineer can test against a running system. What it describes is not a new species of account. It is a credential naming the software, naming the principal where one exists, scoped to the task in hand, and expiring alongside it.

The practical consequence is that your authorisation server, not your identity taxonomy, becomes the component that decides whether this is achievable. Exchange support varies between products and between versions of the same product, which makes it a question to settle early rather than a detail to discover during integration.

## What to Build, in Order

- **A workload identity per agent, never shared.** Not across agents, not across environments, not with a human. Every attribution claim you make later rests on this one.

- **Delegation rather than impersonation wherever a person is present.** Trade the person's credential for a narrower one that records the software as the acting party, and confirm the exchange works in your environment before any design depends on it.

- **Match scope to the task rather than the job title.** Summarising a single ticket calls for read access to one queue, not the requester's entire entitlement set. Our piece on [why least privilege gets harder with agents](/least-privilege-harder-with-ai-agents) covers the modelling problem behind that.

- **A separate identity for unattended runs.** A scheduled execution gets its own credential and its own review, rather than a boolean on the attended one.

- **Record the whole chain per call.** Software, actor, principal, task, tool. Absent those fields, the trail a compliance function will eventually request simply is not there to produce, and our [audit evidence guide](/agentic-ai-audit-log-evidence-requirements) enumerates which fields count as evidence.

- **Short lifetimes, plus a test proving expiry fires.** Expiry compresses the period in which a stolen credential remains useful. It constrains nothing about reach during that period, so scope carries the whole of that load.

None of this amounts to a guarantee. A tightly scoped credential can still be spent badly within the bounds of its own scope, and the relevant standards work is actively moving underneath everyone. Read the list as risk reduction with a ceiling you can describe.

## Five Things to Check This Week

- Enumerate every agent and, beside each, every credential it can present today. Flag anything presented by more than one thing.

- Find the agents that alternate between attended and unattended work. Split their credentials before anything else on this list.

- Pick a downstream system and ask whether its logs can name the agent and the person behind one specific call last week. If not, that is the first fix.

- Take the agent with the highest impact and swap its borrowed human credential for a delegated one scoped to the task.

- Where the machine-credential side is new ground for the team, start from our [non-human identity primer](/non-human-identity-security-for-ai-agents).

Our position, stated plainly: the naming argument matters far less than the engineering fact sitting beneath it. For this class of software, identity describes an action rather than the thing performing it. Build on that basis and whatever the industry eventually calls the category becomes somebody else's problem to settle.

One practical test tells you whether a team has internalised this. Pick a call that happened last Tuesday and ask which agent made it, which person it served, and which task it belonged to. A team that has to join three systems by timestamp to answer has an identity model built around categories. A team that reads one log line has an identity model built around actions, and it will cost that team far less the first time something goes wrong at an awkward hour.

Worth saying plainly for anyone about to sit through this debate again: the choice of word is not a security control. A team can adopt the term agentic identity, publish a definition, update the architecture diagram, and change nothing about what a credential reaches or what a log line records. A different team can refuse the term entirely and still ship per-agent workload identities with delegated task-scoped tokens and a readable chain. Only the second team has reduced any risk, and the vocabulary question is settled, in practice, by whoever writes the authorisation code.

## Two IETF Drafts, One Useful and One Contradictory

While the glossaries argued about what to call this, the standards community went ahead and specified it, and what came out supports the action-shaped reading rather than the new-category one. The WIMSE working group's architecture document, [draft-ietf-wimse-arch-08 of 6 July 2026, treats an AI intermediary as a special case of a delegated workload](https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/) rather than as a new species of principal. The relevant section carries a requirement worth pinning above the desk: autonomous actions MUST be clearly distinguished from delegated ones, with separate workload identities or separate token scopes offered as the mechanism. That is the fourth item in the build list above, arriving as a normative sentence in a working group draft instead of as our preference.

The same document adds a second requirement for chains: every hop must scope and re-bind the security context so a downstream service can evaluate provenance. If one of your agents hands work to another, that sentence tells you a single durable token travelling the length of the chain is not a design decision, it is an unfilled gap.

The companion draft is more revealing. [Draft-sweeney-wimse-credential-delegation-00, dated 28 July 2026, profiles token exchange, DPoP, rich authorization requests and CIBA](https://www.ietf.org/archive/id/draft-sweeney-wimse-credential-delegation-00.html) into a delegation protocol for agents, and it is specific exactly where this field usually waves its hands: it recommends a delegation token lifetime of fifteen minutes with a one hour ceiling, and it requires that the opaque credential handle carried in the token never be the credential itself, with the raw credential kept out of any agent-facing response. Those are two concrete parameters you can take into a design review this week.

The contradiction inside it is worth reporting rather than smoothing over. The introduction says the document defines no new token formats, no new OAuth grant types and no changes to authorization server behaviour. The IANA section of [that same draft](https://www.ietf.org/archive/id/draft-sweeney-wimse-credential-delegation-00.html) then requests a new grant type URI and five new JWT claim names, and an earlier section specifies a delegation token format of its own. Both statements sit in one document, and it is an individual submission rather than working group output, so read it as a serious proposal that has not yet reconciled its own framing. It also shows the gravity this field exerts: even an author committed to reusing what exists finishes by registering new claims.

The platform vendors have landed in an awkward middle on the same question. Microsoft's Entra documentation makes an agent identity a service principal, then concedes that some systems will not accept one, so it permits a second account of user type bound one to one with it, which it calls [an agent's user account](https://learn.microsoft.com/en-us/entra/agent-id/agent-identities). That is the user-or-service binary surviving as an implementation detail after being rejected as a design question. Worth knowing about before it turns up in your directory with nobody able to say which of the two objects a given log line refers to.

## Skip the New Word. Ship the Actor Claim.

Our call, unchanged by reading the drafts: do not wait for the category argument to settle, and do not treat adopting a vendor's label as though adopting it were a control. Implement delegation semantics on the standards already published. Token exchange is an RFC, the actor claim exists, and your authorisation server either supports exchange or it does not. That one question determines more about your eventual posture than any amount of agreement about nouns, and it is answerable this afternoon. The WIMSE architecture draft arrives at the same place from the opposite direction by classifying the agent as a delegated workload, which is to say it declines to invent the category either.

An agent that originates its own objectives would break this model. The action-shaped model assumes every consequential thing an agent does traces back to some principal, a person or another workload. An agent that genuinely originates its own objectives, holding a budget with no upstream request behind any particular action, has no principal to delegate from. For that case a bare workload identity says nothing about intent, the delegation chain collapses to a single party, and the people arguing for a distinct kind of identity are describing a real problem rather than selling a word. We have not met one of those in production. Almost everything running today is set off by a ticket, a schedule or another service, and for that overwhelming majority the action is the right unit and the label is a distraction.

## Questions about identity for AI agents

### Human account or machine account for an agent?

Neither on its own. Give the software its own workload identity, then carry a person's authority through delegation when it acts for one, and keep unattended runs on a credential of their own.

### How do delegation and impersonation differ in practice?

Delegation leaves the software holding an identity of its own while the credential records who it serves. Impersonation transfers the person's rights outright, and from that point the logs can no longer tell the two apart.

### Is agentic identity an established standard?

A vendor has proposed the term; no standards body has ratified it. The components underneath, namely token exchange and workload identity, are standardised and implementable today. Check the current drafts before building a dependency on any new label.

### Do short-lived credentials close the problem?

No. Lifetime compresses the window in which a stolen credential still works. Scope governs the damage a valid credential can cause, attribution governs whether you can reconstruct events afterwards, and all three are required together.

## FAQ

### Human account or machine account for an agent?

Neither on its own. Give the software its own workload identity, carry a person's authority through delegation when it acts for one, and keep unattended runs on a credential of their own.

### How do delegation and impersonation differ in practice?

Under delegation the software keeps its own identity and the token records that it acts for somebody. Under impersonation it receives the person's rights outright, and the logs lose the distinction.

### Is agentic identity an established standard?

It is a vendor-proposed term, not a ratified standard. The components under it, token exchange and workload identity, are standardised. Check current drafts before depending on any new label.

### Do short-lived credentials close the problem?

No. They compress the window a stolen credential stays useful. Scope decides how much damage a valid credential can do and attribution decides whether you can reconstruct events, so all three are needed.


---
Source: https://agenticcyber.co/blog/ai-agent-identity-an-agent-is-neither-a-user-nor-a-service