Identity & Access · Chapter 7 of 16
Machine and agent identity
Non-human identities already outnumber humans. AI agents are about to make that worse — and it is becoming a job title.
Every service account, CI runner, container, function and API client is an identity. In most organisations these already outnumber human identities by a wide margin, and they are governed far more weakly: no HR record, no joiner-mover-leaver, no manager to review them, frequently no owner and no expiry.
Why AI agents sharpen this
An AI agent is a non-human identity that acts unpredictably and can be influenced by the content it reads. Every existing weakness in machine identity becomes materially more dangerous, because the classic assumption — that a service account does one predictable thing — no longer holds.
- Agents need their own identity, not a borrowed one. An agent using a shared service account is unattributable: you cannot tell which agent, which user's request, or which run took an action.
- They should act on behalf of the requesting user, scoped per request, rather than holding standing authority. This is the confused-deputy problem, and delegation — OAuth token exchange, on-behalf-of flows — is the established pattern.
- Time-bound and task-bound. Credentials for the duration of the task, not the lifetime of the service.
- Every tool call attributable to an agent identity, a run, and an initiating human. Without that you cannot investigate.
This is now a hiring signal, visibly
In the postings behind this atlas the identity vendors are already advertising for it directly — “Forward Deployed Engineer, Okta for AI Agents”, “Product Manager, Identity for AI”, “Software Engineer, Identity for AI”. Non-human identity has moved from a hygiene topic to a product category inside about two years.
If you already know identity and you learn the AI material in the other books here, you are positioned for a specialism that barely has practitioners yet. That combination is rare on purpose — almost nobody has both halves.
Why machine identity is now the larger problem
Machine identities outnumber human ones by a large multiple in any modern estate — services, jobs, containers, functions, pipelines, and now agents. They have none of the properties that make human identity manageable: no joiner event, no manager, no leaver process, and no one to notice when something looks wrong.
| Property | Human identity | Machine identity |
|---|---|---|
| Created by | A hiring process, with a record | Anyone with API access, in seconds, often in a script |
| Owned by | A manager | Frequently nobody — and the creator has often left |
| Removed when | Someone leaves, with a triggering event | Never. There is no event, and disabling it risks an outage nobody can scope |
| Credential | A password plus a second factor | A key or token, often long-lived, often in a file |
| Anomaly detection | Unusual location or hours are meaningful signals | Behaviour is supposed to be uniform — which makes deviation easier to spot and means nobody is looking |
The last row is an underused opportunity. A service that has called the same four endpoints every five minutes for a year is the easiest anomaly-detection target in the estate — far easier than a human, whose behaviour is legitimately erratic. Very few organisations monitor machine identities behaviourally, and it is comparatively cheap.
Agents make this materially worse, and the reason is not the model.
An agent acting on a user's behalf raises a question the estate usually cannot answer: is this action authorised for the agent, for the user, or for both?
The wrong answer — and the common one — is to give the agent a powerful service identity and rely on the application to check the user's permissions. That collapses the moment the agent can be steered by content it reads, because the credential is not scoped to the user at all.
The right shape is delegation: the agent acts with the user's authority, reduced — never with its own broader authority on the user's behalf. It should be unable to do anything the user could not do, and ideally much less.
And the audit requirement follows: the log must record the agent, the user it acted for, and the specific grant that permitted it. ‘Service X performed action Y’ is not an audit trail once a model is choosing Y.
The practical test: “if the agent reads a malicious document, what is the worst thing its credentials permit?” That is the blast radius, and it is an access-control answer rather than an AI one.
Check yourself