Agents need identities, not API keys
The fastest way to get an agent working is to give it a service account with broad access. That decision is made in an afternoon, is almost never revisited, and turns every later security question into one that has no good answer.
The credential is created because the agent needs to reach something. It is given the permissions the first use case required, plus a few more so that the next one does not need another ticket. It goes into a secret store, it works, and the project moves on.
Eighteen months later that credential is the most privileged thing in the estate that nobody can describe. It has accumulated scopes, it is used by three systems, its actions appear in audit logs as itself rather than as anyone, and the answer to “who did this” is the name of a service account.
The claim: an agent is a party that acts, and a party that acts needs an identity, a delegation and an expiry. A long-lived key satisfies none of those, and the gap becomes visible the first time somebody has to reconstruct what happened.
What a key cannot answer
| A shared key or service account | A delegated agent identity |
|---|---|
| Who initiated this action? The service account | Which person the agent was acting for, carried in the token |
| Was it authorised? It had the permission, so yes | It had the permission the delegating user held, for this task, at that moment |
| What else can it reach? Everything in its scope, indefinitely | What the task needed, until the credential expires |
| Can it be revoked? Yes, and everything using it stops | Yes, for one agent or one delegation, without an outage |
| What was it doing last March? Whatever the logs happen to say | The delegation chain is in the record, because it was in the token |
The second row is the one that matters for governance. An agent operating with its own broad permissions can do things no human requester was entitled to do, which means the entitlement model of the organisation is silently bypassed every time the agent runs. Nothing detects that, because at every layer the request looks authorised.
Machine identities already outnumber human ones in most estates by a wide margin, and the practice for managing them is better developed than the practice for agents specifically — the Cloud Security Alliance’s work on non-human identity and agentic AI governance is a reasonable orientation to where the standards are heading. The direction is consistent: agents as first-class identities, short-lived credentials, and the human preserved as the delegating subject rather than replaced by the agent.
The decision, and when to make it
On whose authority does this agent act?
- Delegated credentials, scoped to that user, expiring with the task. The default for anything reading organisational data. Containment comes free.
- Its own identity, minimum scope, short-lived, with a named human owner. Batch enrichment, monitoring, reporting. Nobody is waiting, so nothing needs broad access.
- Stop. This is a shared key, and it will be the thing an incident is about. It is also how most agent deployments currently work.
The first branch is the single highest-value control available against the whole family of prompt injection attacks, and it is an identity decision rather than a security product. An agent that can only see what its requester could already see has a bounded worst case. An agent with a service account has the worst case of the estate.
What to put in place
The third line is the one that pays for itself in the first investigation. When an agent’s action is recorded as the agent, the audit trail ends at a piece of software. When it is recorded as the agent acting for a named person on a named task, the trail continues into the organisation, which is where the accountability was all along.
The unglamorous part
None of this is new engineering. Short-lived credentials, scoped tokens, delegation and workload identity are established practice with established standards behind them, and most large organisations already run the machinery. What has not happened is anyone applying it to agents, because agents arrived through data science and application teams rather than through the identity programme, and the two have not met.
That is the practical recommendation. The identity team already knows how to do this. The AI programme does not know that it needs it. The cheapest intervention available in most estates is a conversation between them, held before the next agent reaches production rather than after the first review finds a key with more access than anybody intended.
What this does not tell you
Delegated identity does not stop an agent from doing something wrong. It bounds what wrong looks like, and it makes the record legible afterwards. An agent acting for a user can still take an action that user would not have wanted, and the control for that is the irreversibility classification and the confirmation step, not the credential.
It also does not remove the case for monitoring. Short-lived scoped credentials reduce the blast radius of a compromise. They do not detect one, and an agent behaving anomalously within its legitimate scope is still the hardest thing in this space to see.
The person who decides differently after reading this is whoever is about to provision the credential for the next agent. Ask whose authority it acts on. If the answer is “its own”, ask why — and if the reason is that delegation was harder to set up, that is a week of work bought against a class of incident that is currently costing other organisations a great deal more than a week.