AI agent identity: why service accounts do not work for agents

What a service account cannot express

A service account answers one question: is this caller allowed to make this call? For a cron job that syncs two databases every night, that is the only question there is. The job has no intent, no requester and no discretion.

An agent has all three. It acts because a person asked it to, it chooses which tools to invoke, and the same agent can legitimately perform an action for one user that it must not perform for another. A single shared credential collapses all of that into one undifferentiated caller.

The two-identity model

The fix is to stop treating the agent as the actor and start treating it as an intermediary. Every consequential action carries two identities: the agent that performed it, and the human principal on whose behalf it acted.

This is not bookkeeping. It changes what the system can enforce. Permissions become the intersection of what the agent may do and what the requesting user may do, so an agent cannot be used to launder an action its requester was never entitled to take. It also changes what the record can prove, because "agent-7 exported the customer table" and "agent-7 exported the customer table for a contractor whose access expired in March" are different findings.

What an agent identity has to carry

Beyond a credential, a usable agent identity records:

• A stable identifier that survives redeployment, so history is continuous.
• An owner: a named human accountable for the agent, not a team alias.
• A declared purpose, which is what you compare behaviour against later.
• The scopes it is entitled to, expressed as data and tools rather than network reachability.
• A lifecycle state, so a suspended agent is distinguishable from a deleted one.
• Its model and version, because behaviour changes when those change.

Credentials are the easy half

Short-lived credentials, scoped tokens and rotation are well-understood problems with good existing tooling, and agents do not make them harder. What agents add is the authorisation question that comes after authentication: this caller is who it claims to be, but should this particular action, for this particular requester, be allowed right now?

That question cannot be answered by an identity provider alone, because it depends on the action and its context. It needs a policy decision at the point of use, and a record of the decision that was made.

The offboarding problem

Human identity has a mature leaver process: someone resigns, HR triggers a workflow, access is revoked. Agent identity usually has nothing equivalent. Agents are created during a project, outlive it, and keep their credentials indefinitely because no process exists to retire them.

The result is a population of live credentials belonging to agents nobody currently owns. Treating agents as first-class identities means giving them the same lifecycle discipline as employees: an owner who is accountable, periodic re-attestation that the agent is still needed, and revocation when it is not.