Machine identity, non-human identity, service account.
Three terms that overlap and are used interchangeably by people who mean different things. The distinctions matter less than most vendor pages suggest, and in exactly one place they matter a lot.
cursor-agentDecides its own next callDecides- The three terms overlap heavily and no standards body owns them. Vendor definitions disagree, and that is not a conspiracy, just a young field.
- Machine identity is usually the widest: anything non-human that authenticates, certificates included.
- Service account is the narrowest and the most concrete: an account object in a directory or cloud IAM.
- The distinction that actually matters is whether the thing decides its own actions. That is what separates an agent from a cron job.
Published Last reviewed
Three words, one question underneath.
The useful test is not which word is correct. It is whether the thing you are looking at decides its own actions.
Usually means any identity a machine uses to authenticate, including TLS certificates, SSH keys, signing keys and workload identities. People who come from the certificate world use it this way, and for them the lifecycle question is expiry and rotation rather than permissions.
Usually means the same set, read from the access side: what does this identity hold, and what may it do. People who come from identity governance use it this way, and OAuth apps and API keys sit firmly inside it.
An actual account in a directory or cloud IAM, created for a system rather than a person. It is a subset of both terms above, and the only one of the three you can point at in a console.
An identity that chooses its own next call. Everything true of the others is true of it, plus the set of permissions it uses is the set it has rather than the set its code calls for. This is the distinction worth keeping.
Where the definitions actually differ.
Read the last column first. It is the only one that changes what you would do differently.
| Term | Typical scope | Who uses it | What it says about permissions |
|---|---|---|---|
| Machine identity | Widest: certificates, keys, workloads | PKI and certificate teams | Little. The focus is expiry and rotation. |
| Non-human identity | Wide: accounts, keys, OAuth apps, agents | Identity and access teams | Everything. The focus is what it can reach. |
| Service account | Narrow: an account object | Platform and cloud teams | Direct permissions and assumable roles. |
| AI agent | An NHI that acts on its own | Security teams, since 2024 | All of the above, used at runtime without a plan. |
How to use the terms.
In an environment where three teams already use three words.
Internally it matters less which term you choose than that everybody means the same thing by it. Put the definition in the policy, not in a conversation.
Separate the identities that execute a fixed set of calls from the ones that choose their calls. The second group needs different controls regardless of the label.
Three terms tempt teams into three lists maintained by three groups. One list with a type column is better than three lists that disagree.
When comparing products, translate their word into yours before comparing features, or you will compare two different scopes.
Questions, answered.
Short answers on machine identity vs non-human identity.
Is a non-human identity the same as a machine identity?
In most practical contexts yes, and the overlap is close to complete. Machine identity is more common among certificate and PKI teams and tends to include TLS certificates and signing keys. Non-human identity is more common among identity and access teams and tends to emphasise what the identity can reach.
Is an AI agent a service account?
It runs as one, often. The agent is the software that decides what to do; the service account is the identity it authenticates with. Several agents can share one service account, which is exactly the situation that makes an incident hard to attribute afterwards.
Which term should we use in our policy?
Whichever one your identity team already uses, defined once in writing. The risk is not the word, it is three teams maintaining three inventories because each used a different one.
Keep reading.
The pages that belong to the same picture.
See what your agents can reach. Before someone else does.
Book a demo and we walk through the access paths in an environment like yours.