One Identity per Agent

One Identity per Agent is the step that turns an anonymous process holding a borrowed key into a principal you can grant, audit and revoke. It gives each agent role a name of its own, credentials that expire on their own, and an authority somebody deliberately wrote down.

Key takeaways

• An agent using the application's service account has no identity, so its actions are unattributable, its permissions were scoped for a different job, and it cannot be revoked without breaking the application.
• One identity per agent role, not per agent framework and not per team. The unit is the job the agent does, because that is the unit the permissions describe.
• Prefer workload identity issued at runtime over a long-lived secret in a vault. A secret that never expires is a secret you will find in a log.
• Acting alone and acting on a user's behalf are different grants. Collapsing them gives every user the union of what any user may do.
• Write the authority record: identity, permitted actions, data in scope, expiry, and the named person who approved it. That record is also the artifact an auditor asks for.

Read this after Chapter 4, which reduced what the agent may ask for, and before Chapter 6, which enforces the grant at the far end. Chapter 1's four properties of a principal are the checklist this chapter completes, and Chapter 12 is where the authority record becomes evidence.

An incident review is underway. Something deleted forty records overnight, and the audit log has the answer: the action was taken by svc-platform-api.

That account is used by the web application, two cron jobs, a data export and, since March, an agent. Five candidates, one name. Nothing distinguishes them.

The rest of the meeting is spent correlating timestamps. That is what having no identity costs, and it costs it during the worst hour of the week.

Borrowed credentials are the default

Nobody chooses to give an agent the application's service account. It arrives by construction, which is worse.

The agent was built as a feature inside an existing service, so it runs in that service's process, reads that process's environment, and picks up whatever credentials were already there. The code that calls the model and the code that serves HTTP requests are the same deployment, and a deployment has one set of secrets.

Three things follow, and all three are load-bearing. Attribution is impossible, because the log shows the account rather than the actor. The permission set is wrong by construction, since it was scoped for the application's job rather than the agent's. And revocation is unavailable. Turning off the credential turns off the product.

That last one decides incidents. When somebody asks whether the agent can be stopped without an outage, the answer for a borrowed credential is no, and that answer is discovered at the exact moment it is most expensive.

The unit is the role, not the process

One identity per agent sounds obvious until somebody asks what counts as one agent, and the answer is worth settling before the implementation.

The unit is the job. An agent that triages support tickets and an agent that reconciles invoices are two identities, because their permission sets have almost nothing in common. A shared framework, repository and pipeline change none of that.

Two identities are not required per running instance. Ten replicas of the triage agent share an identity, because they share an authority, and splitting them produces bookkeeping without producing a decision anyone will make differently.

The instructive test is the revocation question. If you would ever want to disable one of two things without disabling the other, they are two identities. If you would always disable both together, they are one.

Environments split the same way for the same reason. The staging triage agent and the production triage agent are separate identities, because the whole point is that one of them cannot touch production data.

Prefer identity issued at runtime over a secret at rest

Having decided who the agent is, the next question is how it proves it, and the two common answers are not equivalent.

The familiar answer is a long-lived secret stored in a vault and injected as an environment variable. It works, it is easy, and it has a structural weakness: the secret exists as a copyable string that is valid for months. It ends up in a process environment, a crash dump, a debug log and a developer's terminal history, and OWASP's sensitive information disclosure entry is a reminder that an agent holding such a string can also be persuaded to repeat it.

The better answer is workload identity, where the platform attests what the workload is and an authority issues a credential in response. The agent proves what it is. Not what it knows. Nothing durable is stored, so nothing durable can leak, and the credential is bound to a workload rather than to whoever holds the file.

Most cloud platforms and orchestrators provide some form of this, and the mechanism matters less than the property. Prefer credentials that are issued to a verified workload, scoped at issuance, and useless once copied elsewhere.

Where a static secret is genuinely unavoidable, treat it as a temporary exception with an owner and a date, rather than as the design.

Short-lived by construction, not by policy

Expiry written in a policy document is a plan. Expiry enforced by the issuer is a property. Only the second survives a bad week.

Short-lived credentials change the shape of an incident. A leaked token valid for fifteen minutes is a bounded problem, since the window closes without anyone doing anything. A leaked token valid for a year is an investigation, a rotation project and a set of awkward questions about where else it was used.

The operational objection is that rotation causes outages. It does when rotation is an exceptional event performed by hand under pressure. It does not when the credential lifetime is short enough that renewal happens continuously in normal operation, which is the argument for aggressive lifetimes rather than against them. A renewal path exercised a hundred times a day is a path that works.

The rule to adopt is that the agent should never hold a credential valid for longer than its longest single task, with a margin. An agent whose tasks finish in seconds has no business holding an hour of authority.

Acting alone and acting for a user are different grants

This distinction is missed constantly, and missing it quietly hands every user the permissions of the most privileged user.

Some actions the agent takes as itself, such as reading a public knowledge base or writing to its own working store. Those belong to the agent's own identity, and the scope is fixed.

Other actions the agent takes because a specific person asked, such as reading that person's documents or issuing a refund on their account. Those must execute with that person's authority, not the agent's, which is precisely what OWASP means by recommending that extensions execute in the context of the individual user with minimum privileges.

Collapsing the two is what produces the classic cross-tenant failure. The agent holds one credential that can read everybody's documents, applies a filter to keep to the current user's set, and the filter is a runtime decision made by the component from Chapter 3 that an attacker may be instructing.

Implement the distinction as delegation rather than as impersonation. The agent presents its own identity together with a token representing the user's authority, so the downstream system can see both, and the audit trail records that this agent acted for that person. Impersonation, where the agent simply becomes the user, destroys exactly the attribution this chapter exists to create.

The authority record, and who signs it

Chapter 1 said a principal has an authority someone granted. This is where that stops being an abstraction.

The authority record is a short document, kept in the repository beside the agent, that states its identity, the actions it may take, the data in scope, the environments it operates in, its credential lifetime, the autonomy position from Chapter 1, and the named person who approved it. It is the thing that makes permissions a decision rather than an accumulation.

Two properties make it useful rather than decorative. It is reviewed when it changes, by someone other than the person who wrote the agent's prompts. And it is compared against reality automatically, because a record that says four permissions while the identity provider grants eleven is worse than no record, since it produces confidence without accuracy.

The compliance angle is straightforward to state without straying into legal advice. The EU AI Act's implementation timeline puts the remainder of the Act into application on 2 August 2026, with the exception of Article 6(1). For systems in scope, the documentation of what a system is permitted to do, and who decided, is the sort of artifact that gets requested. Writing it during design costs an afternoon, and reconstructing it later costs considerably more.

A worked example, composited and labelled

The details here are composited from ordinary production shapes rather than taken from one system, and the shape is exact.

An organisation runs three agents. A support triage agent that reads tickets and drafts replies. An invoice reconciler that reads accounting records and proposes matches. A deployment assistant that reads CI logs and opens pull requests.

Before the work, all three run in the platform service and share its account, which carries forty-one permissions accumulated over four years, including production database write and the ability to create IAM roles.

After the work, each has a workload identity issued at start-up with a fifteen-minute lifetime. Triage may read tickets in its own queue and write drafts, and it reads customer records only under a delegated user token. Reconciliation may read two accounting tables and write to a proposals table, with no ability to post a ledger entry at all. The deployment assistant may read logs and open pull requests, and it cannot merge, because merging is the irreversible action from Chapter 4.

The property worth noticing is not that permissions shrank. Each of the three can now be revoked in isolation, at three in the morning, without an outage.

The objection: this is a lot of ceremony for one agent

For a single internal agent used by four people, the objection is fair on the day it is raised. It stops being fair quickly, and the direction of travel is predictable.

The honest minimum for a first deployment is small. A distinct identity, so actions are attributable. A credential that expires without human intervention. A written note of what the agent may do and who approved it, which can be a page in the repository rather than a governance process.

That much is perhaps a day of work, and it is not the expensive part. The expensive part is retrofitting identity onto three agents that already share an account and whose permission sets nobody can reconstruct, which is a project rather than a task.

There is also an offboarding argument that lands with operations teams immediately. Organisations know how to remove a departing employee's access, and almost none know how to remove a decommissioned agent's, because there was never a name to remove. An agent with no identity is never offboarded, so its permissions outlive it, and unused standing access is exactly what the next security review will find.

Chapter summary

An agent running under the application's service account has no identity, which costs three things that all come due at once: actions cannot be attributed to it, its permissions were scoped for a different job and are therefore wrong by construction, and it cannot be revoked without taking the product down. The unit of identity is the role rather than the process, so replicas share one identity while two agents with different jobs get two, and the test is whether you would ever want to disable one without the other, with environments splitting the same way. Prefer workload identity issued at runtime, where the platform attests what the workload is and the agent proves what it is rather than what it knows, over a long-lived secret that exists as a copyable string in environments, crash dumps and logs, and that an agent can be persuaded to disclose. Credential lifetime should be short by construction rather than by policy, because a renewal path exercised continuously works while an annual rotation performed under pressure does not, and no agent should hold authority for longer than its longest task. Acting alone and acting on a user's behalf are separate grants, and delegation, where the agent presents its own identity alongside a token carrying the user's authority, preserves the attribution that impersonation destroys. Write the authority record with identity, actions, data scope, lifetime, autonomy position and an approving name, review it when it changes, and check it automatically against what the identity provider actually grants.

The agent now has a name and a scoped credential. Nothing yet stops it from asking for something outside that scope and being served, because the check still lives on the wrong side of the call. Chapter 6 is Authorization Enforced Outside the Model, which moves the decision to the gateway and the destination system.