Most agent fleets authenticate the way the first prototype did: an API key in an environment variable, shared by whatever runs in that container. It works, and it quietly removes the one thing every later control depends on. An agent acting under a shared key cannot be told apart from the next agent, cannot be revoked without breaking both, and cannot be investigated afterwards. Identity is not paperwork here; it is the join key everything else uses.
A static key answers one question, badly: does the caller know the secret. It says nothing about who the caller is, on whose behalf they are acting, what runtime they are running in, or whether anybody still expects them to exist. Those are the questions an incident review asks, and none of them are answerable from a key.
An identity for a workload, agent or otherwise, has to be four things at once. Nameable, so logs and decisions can refer to the same subject. Attributable, so there is a human or a team who owns it. Attestable, so the name is bound to a workload by something stronger than a config file. Revocable, so removing it is an action rather than a migration.
The uncomfortable part is that most fleets today have the first two at best, and often not even those. That is not a moral failing; it is what happens when a prototype becomes production without anyone deciding it had. The useful move is to notice which of the four you actually have, per agent, before the next control is layered on top.
Each one is separately answerable, and each is separately missing in most fleets.
One identifier per agent, stable across restarts and deployments, short enough to sit in every event and every log line. If a spend record, a policy verdict and an audit entry cannot be joined on it, they are three stories about three different agents.
A human or a team accountable for rotating it, answering for it and eventually deleting it. This is the auditor's first question and the one most inventories cannot answer, because the person who created the agent has since changed teams.
Anyone can claim a name. Attestation is the evidence behind it: an OIDC token, a SPIFFE SVID, an mTLS certificate, an enclave key, or honestly nothing at all. The last option is legitimate and common; what matters is that it is recorded rather than assumed.
An agent rarely acts for itself. It acts for a user, or for another agent that acts for a user. That chain is what makes an action attributable to a person, and it has to be ordered, acyclic and bounded, or it becomes a way to launder authority through three hops.
Identity says who is asking. It does not say yes. For the small set of actions that are expensive or hard to reverse, the useful pattern is a signature bound to that exact command and its arguments, not a session that authorised a class of things an hour ago.
An identity you cannot switch off is a credential with a personality. Revocation has to be a single action with a visible effect, and it has to cover the paths the identity opened: its tokens, its device access, and the delegation others hold to it.
The order matters more than the format. A fleet that names agents after they are already calling production systems spends the next quarter reconciling logs. Any stable identifier will do; what breaks is having none, or having three that nobody joins.
The temptation is to leave the field blank and imply something stronger than the truth. A field with an explicit none is far more useful: it lets you sort the fleet by how well each name is actually bound, and it turns a vague worry into a list you can work through. Most organisations start with none nearly everywhere, and that is fine as a starting point and dangerous as a permanent state on privileged agents.
"The agent is acting for the user" is a sentence. An ordered chain from the agent, through whatever spawned it, to the human at the root is a structure you can query, cap in length and check for cycles. It is also the only way to compute what an identity can really reach, because the answer is the union of everything along the chain rather than the grants on its own name.
Which agent provisioned this one is an org chart. Who it is acting for on this request is authority. Collapsing them into one field feels tidy and produces an inventory that cannot answer either question later.
Per-action confirmation on every call trains people to click through it within a week, which is worse than not having it. Reserve it for the destructive and expensive: a kill, a budget change, an approval grant, issuing or revoking access. Bind the signature to that exact command and its arguments, record which credential was touched, and let the ordinary path stay ordinary.
An agent that holds a token holds it in the prompt, the trace, the logs and whatever it repeats next. A handle the agent can pass around, with the real value attached at the last hop, keeps the secret out of the context window and gives revocation exactly one place to act on.
Almost every first inventory finds the same three things: service accounts unused for months, agents with no owner, and one credential appearing from many places at once. None of that is exotic and all of it is cheap to fix; the reason it persists is that nobody was counting.
Identity is the join key the other guides assume: AI agent governance for the full set of runtime controls, AI agent security for the failure modes an identity gap opens, and MCP security for the tools an agent reaches once it has one. The whole set is in the guides index.
With an identity, not a shared secret. The agent needs a stable name, a recorded owner, and evidence binding that name to the workload: an OIDC token, a SPIFFE SVID, an mTLS certificate or an enclave key. A key in an environment variable proves only that the caller knows the key, which is the one thing an incident review never needs to establish.
Attestation is the evidence that a name belongs to the workload using it. You do not need it everywhere on day one, and most organisations honestly start with none nearly everywhere. What matters is that the absence is recorded rather than implied, so privileged agents with nothing behind their name show up as a list instead of a feeling.
Because an agent's real reach is the union of everything along the chain it acts through, not the grants attached to its own name. A one-hop field cannot show that an agent with modest permissions arrives at admin two hops away. Keep the chain ordered root first, acyclic and capped, and keep it separate from the static parent that provisioned the agent.
No, and demanding it is how a control gets clicked through within a week. Reserve per-action confirmation for the destructive and expensive few: a kill, a budget change, an approval grant, issuing or revoking access. Bind the signature to that exact command and its arguments so approving one action never quietly approves the next.
Hand the agent a handle rather than a value, and attach the real credential at the last hop before the call leaves. Anything in the context window is quotable, loggable and memorable, so a token given to the model is a token in the trace and in whatever it repeats next. Brokering also gives revocation exactly one place to act.