Ask your team a simple question this week: when one of your agents calls an internal API, whose identity is it using? The answer is usually a service account whose password sits in a vault, or an API key issued to whoever built the integration. Both work. Both are the shared-account problem, now running at machine speed.
An agent is not a user, and not simply a credential
Agents do not fit the two boxes we already had. They are not users: nobody types a password, there is no device to bind, and “who is signed in” has no natural answer. They are not credentials either, because a credential has no behaviour and an agent very much does.
The distinction that makes this tractable is between two situations that look identical from outside. An agent acting for itself — a scheduled job reconciling invoices overnight — needs an identity of its own, with its own permissions and its own audit record. An agent acting for a person borrows authority, and that authority should be narrower than the person’s, time-bound, and attributable to both.
Why the usual approach ruins the audit trail
When both cases run through the same long-lived key, every row in the audit trail says the same thing. You cannot separate the overnight job from the assistant acting for a colleague from the engineer debugging at 2am. The record exists, and it answers none of the questions you would ask during an incident.
This is the same failure that makes shared accounts dangerous, which is the clue to the solution. The problem was never specific to AI.
Service identities, and what makes them different
A service identity holds no credentials of its own. Named people are permitted to assume it, for a set duration, and only one person can hold it at a time. Once assumed it behaves as an identity — including into connected single sign-on applications — which is what separates it from a privileged role, where your own identity stays with you and the downstream application never sees the difference.
Delegation covers the second case: a selected set of operations with its own expiry, rather than a copy of the person’s permissions. The agent gets what the task needs, and when the grant lapses it lapses on its own.
Keys that cannot travel
A leaked key is only valuable where it can be used. Binding a key to a network range makes a stolen key inert outside it, and that matters more for agents than it ever did for people, because agents run in known places: a VPC, a scheduler, a specific host. There is rarely a good reason for an agent’s key to work from a residential address on another continent.
The second half is lifecycle. A key created under a role should die with that role, so when the person who built the integration changes teams, the keys issued under their entitlement stop working. That is the opposite of what usually happens.
Put it into practice
Three questions for any platform
- When an agent acts for a person, does the audit record name both?
- Can the agent’s authority be narrower than the person’s, and expire by itself?
- If the agent’s key leaked tonight, where in the world would it work tomorrow?
- Can one agent identity be held by two people at the same time? It should not be.