Field guide
Machine identity security for AI agents
A machine identity is how software proves who it is to another system without a person present. An AI agent has one the moment it can call anything. This page is about whether each agent has its own, who owns it, what it holds and how fast it can be taken away.
What a machine identity is, for an AI agent
A person authenticates because somebody is present to do it. A machine authenticates because it was configured to, sometimes years ago and sometimes by someone who has since left. That second kind is a machine identity: a service account, a workload identity, an API client, a pipeline credential, a managed identity in a cloud.
An AI agent sits on top of one. In the model Agent Trust Cloud uses, there are three classes: human identity, machine identity, and AI agent identity, which is a machine identity that decides what to do next. The chain that matters for security runs in one direction:
human owner → AI agent → machine identity → credential → resource
Every link is a place where a question stops being answerable if nobody recorded it. Who is accountable for this agent? Which identity does it run as? What credential does that identity hold? What does the credential reach?
Why agents need their own
The shortcut is to let an agent borrow an identity that already exists: a person’s login, or a service account several systems already share. It works on the first day. It is the reason the questions above stop being answerable.
- You cannot say which agent acted. Two agents on one credential leave one trail. An investigation starts by guessing.
- The permissions are the union of everyone’s needs. A shared identity has to carry what the most demanding agent requires, so every other agent holds more than it uses.
- Revoking it stops everything. The cost of shutting off one misbehaving agent is an outage in the others, so it gets postponed.
- A borrowed human identity lives and leaves with the person. An agent running as someone who changes role or leaves is either broken or quietly keeps access nobody reviews.
An identity of its own gives each agent one owner, one set of permissions and one thing to revoke. That is our view of the minimum, not a published standard.
The four core risks
| Risk | What it looks like | The question that finds it |
|---|---|---|
| Long-lived credentials | A secret that does not expire and has not been rotated since it was issued. Whoever holds a copy, holds the access. | Which credentials never expire, and when did each last rotate? |
| Over-broad permissions | An identity granted far more than the agent has ever used, because narrowing it was never anyone’s job. | For each identity, what is granted, and what has been used? |
| No owner | An identity nobody is accountable for, often because the person who created it moved on. | Which identities have no named business owner and no named technical owner? |
| No revocation path | Nobody knows how to switch the identity off, how long it takes, or which agents break when it is switched off. | If this credential is compromised, which agents were relying on it, and who can revoke it? |
The risks compound. A long-lived credential on a broadly permissioned identity with no owner is the case where a leak is both likely to go unnoticed and expensive when found. None of the four needs an exotic attack to matter; they are the ordinary state of an estate nobody has inventoried.
What good looks like
This is our own practical checklist, built from the four risks above. It is opinion, not a framework you can be certified against.
- An inventory. Every agent is recorded together with the identity it runs as. You cannot secure an identity you have not listed. The AI agent inventory page has the field specification and a free spreadsheet template.
- An owner for every identity. A named person, ideally a business owner and a technical owner, not a team and not a blank cell.
- Least privilege, checked against use. Start from what the agent needs, and compare it with what the identity is granted and what it has actually used. The agent permission matrix is the working document for this.
- Rotation and expiry. Prefer credentials that are short-lived or federated over bearer secrets that live until somebody remembers them. Where a long-lived secret is unavoidable, give it an expiry and a rotation date someone owns.
- A quick, tested revoke. Write down who can switch an identity off, how, and what depends on it. Try it on something unimportant before you need it.
How Agent Trust Cloud models it
The Machine Identity module is built around the chain above. It is described as holding a credential inventory that separates short-lived and federated credentials from long-lived bearer secrets, and says when each last rotated; effective permissions set against observed use; a blast radius per credential, meaning what it reaches and which agents depend on it; and persistent findings for dormant, ownerless, overprivileged, shared and expiring identities.
To see the idea worked through, the console’s machine identity page shows a seeded sample estate, not customer data. Each identity there lists its credentials, its permissions and the agents that run as it, and the findings are derived from those facts rather than written down. The seeded estate is an illustration of how the records fit together; it is not evidence about any real organisation.
Common questions about machine identity security for AI agents
What is a machine identity?
A machine identity is the way software proves who it is to another system when no person is present. A service account, a workload identity, an API client and a pipeline credential are all machine identities. An AI agent is one that also decides what to do next.
Why does an AI agent need its own machine identity?
When agents share a credential, nobody can say which agent took an action, the credential must carry the permissions of every agent that uses it, and revoking it stops all of them at once. An identity of its own gives each agent one owner, one set of permissions and one thing to revoke.
What are the main machine identity risks for AI agents?
Four: credentials that never expire or rotate, permissions broader than the agent uses, an identity with no named owner, and no tested way to revoke it quickly. Each can be found by asking a question of the inventory.
Where do I start with machine identity security for AI agents?
Start with an inventory that records, for every agent, the identity it runs as, who owns that identity and what it can reach. The free AI agent inventory template on this site has columns for the owner and for tools and permissions, and the full specification adds an identity-used field.