Give Every Agent Its Own Identity

Give the actor a name of its own

An agent needs an identity that represents the agent, not the person who started it. The identity should remain distinct from the human operator even when a run requires that person’s approval.

Audit records must name the actual actor

An agent acting under a human’s credentials makes the audit log useless for attributing its actions. Every entry names someone who was not at the keyboard when the action happened. During review, the record cannot distinguish an operator’s direct change from a change selected and executed by the agent.

Keep the initiating human and the acting agent as separate fields. The first records who authorized or launched the run; the second records which agent made the request. Collapsing both into the human identity discards that distinction.

The OWASP Secrets Management Cheat Sheet, accessed 26 August 2026, says an audit should record who or what used, requested or updated a secret. A human name attached to an automated request does not meet that test in a useful way.

Permissions should match the agent’s work

A distinct identity per agent lets permissions be scoped to what that agent does rather than to everything its operator can do. If an agent only reads deployment status and opens issues, its identity does not need every repository, production or administrative permission held by the engineer who launched it.

This boundary matters because an agent can take several actions without a human at the keyboard. The archived OWASP Top 10 for Large Language Model Applications v1.1, accessed 26 August 2026, describes unchecked authority to act as “Excessive Agency.” Identity is where the selected agent tool permission model becomes enforceable: the downstream service receives credentials carrying only the permissions assigned to that agent.

Borrowed credentials defeat that boundary. The agent receives the operator’s reach even when its job needs only a small part of it.

Revocation must not disable the operator

A separate identity makes revocation possible at the right boundary. Disabling an agent should invalidate that agent’s access without disabling the person who ran it.

This distinction matters when the agent is retired, its credentials are exposed or its behavior must be stopped during an incident. With shared human credentials, responders face the wrong choice: leave the agent’s access usable or interrupt the operator’s legitimate work. Separate credentials let them remove the automated actor while preserving the human identity.

Revocation also belongs in the same lifecycle as provisioning and rotating agent secrets. Rotation changes credentials while retaining the identity; retirement disables the identity when the agent should no longer act.

Attribution must survive downstream calls

The agent identity has to travel through every service that acts on its request. If the first service authenticates the agent and then calls a database, queue or vendor API with one shared token, the attribution trail stops there. The downstream audit record sees only the shared token, not the agent that caused the action.

Carry an agent identifier alongside the request and record it at each boundary that performs work. Keep the run or trace identifier as a separate value: it joins operations from one execution, while the agent identity names the actor responsible for those operations.

The OpenTelemetry documentation for traces, accessed 26 August 2026, explains that context propagation lets spans created in different services be correlated into one trace. The same boundary lesson applies to attribution: context that is not propagated cannot appear in the downstream record. A complete trace does not repair missing identity if every downstream action still authenticates as the same shared principal.

The cost is administrative

The cost of a distinct agent identity is one more identity to provision, rotate and retire. That work is why teams skip the boundary, especially when an agent begins as a local experiment under one engineer’s credentials.

The same omission is then missed during an incident: responders revoke the exposed token but may not know which agent used it, where that identity propagated or whether another shared credential still permits the same actions. Identity ownership therefore needs to follow the agent across its deployment topology, with provisioning at deployment and retirement when the agent is removed.

The next facts to check are concrete: which system issues the identity, which permissions it carries, which downstream services preserve it, who rotates its credentials and what event retires it. If any answer is “the operator’s account,” the separation is incomplete.