Non-human identities: governing AI agents’ access
When we talk about identity management, we almost always think of people. But in modern architectures, and very especially with AI agents, non-human identities now vastly outnumber human ones. Services, APIs, bots and autonomous agents need credentials to act, and each of those identities is a door that has to be watched.
What non-human identities are
A non-human identity is any credential that does not belong to a person: service accounts, API keys, tokens, certificates or the identities that AI agents use to access systems. They allow software to act automatically, but they also allow an attacker who compromises them to operate with their privileges without arousing suspicion.
The problem is that these identities are usually managed far worse than human ones: passwords that never expire, excessive permissions and little traceability. And their number grows out of control as integrations are added.
Why AI agents drive up the risk
AI agents in regulated sectors act on behalf of the organisation: they read data, call tools and execute actions. Each agent is a non-human identity with the ability to do real things. If one is manipulated, for example through prompt injection, its credentials become the attack vector.
That is why the rise of agentic AI is not only a capabilities challenge, but above all an identity governance challenge.
How to govern non-human identities
Inventory and ownership
You cannot protect what you do not know. The first step is to inventory all non-human identities and assign each one a human owner. An orphan credential is a time bomb.
Least privilege and rotation
Each identity should have only the permissions that are strictly necessary and credentials that rotate periodically. This ties in with cybersecurity risk management: limiting the scope reduces the damage if a credential is compromised.
Continuous monitoring
Watching the behaviour of non-human identities makes it possible to detect anomalous use: an agent that suddenly accesses data it never touched is a warning sign. Monitoring is the safety net when the other layers fail.
The problem of secrets and credentials
When I deploy AI agents in an organisation, the first weak point that appears almost always is secrets: API keys, tokens and passwords that those agents need to operate. If they are stored in the code, in a configuration file or, worse still, inside the prompt itself, sooner or later they end up exposed. A poorly protected non-human identity is an open door that no one is watching, because unlike an employee, an agent does not warn that something is wrong nor change its password on its own initiative.
That is why I insist on managing these secrets with dedicated vaults, automatic rotation and short expiry. The less time a credential lives, the less it is worth to an attacker who captures it. And each agent should have its own identity, never a shared one, so that you can trace exactly what each did and revoke the access of a single one without affecting the rest.
Non-human identities and Zero Trust
Governing agents’ identities fits naturally into a zero-trust architecture. The idea is simple: no access is taken as valid just because it comes from inside the network. Every request from an agent is verified, limited to the minimum necessary and logged. Applying this principle to non-human identities is, in my experience, one of the most effective defences against the misuse of agents, and I develop it in my article on Zero Trust architecture in banking.
The practical difference is enormous. In an implicit-trust model, a compromised agent can move freely; in a zero-trust model, every step it tries to take runs into a verification. It does not eliminate the risk, but it bounds it so tightly that an incident is contained instead of spreading across the whole organisation.
My conclusion is that non-human identities already outnumber human ones in many companies, and that trend is only going to accelerate with autonomous agents. Treating them as second-class citizens in the security strategy is a mistake that is paid for dearly. They deserve the same governance rigour we apply to people: controlled onboarding and offboarding, least privilege and constant vigilance.
The growth of AI agents has triggered a problem that many organisations still do not grasp the scale of: for every person there can be dozens of non-human identities —API keys, tokens, service accounts— with sometimes excessive permissions and almost never reviewed. My recommendation is to apply the same discipline to them as to people: a responsible owner, the minimum privilege needed, periodic credential rotation and an expiry date. Treating these identities as second-class citizens is, today, one of attackers’ favourite ways in.
Conclusion: the new perimeter
Non-human identities are the new security perimeter. As we delegate more actions to AI agents, governing who (or what) can do what becomes as important as protecting people. Ignoring them is leaving the back door open just when the most traffic is passing through it.
Frequently asked questions about non-human identities
They are the credentials that do not belong to a person: service accounts, API keys, tokens, certificates or the identities that AI agents use to access systems. They allow software to act automatically.
Because they act on behalf of the organisation (reading data, calling tools, executing actions) using non-human identities with real capability. If an agent is manipulated, for example through prompt injection, its credentials become the attack vector.
By inventorying them and assigning each one an owner, applying least privilege and credential rotation, and continuously monitoring their behaviour to detect anomalous use.
Because they usually have passwords that never expire, excessive permissions and little traceability, and their number grows out of control as integrations and agents are added, becoming a security blind spot.
Do you have to apply this under DORA, NIS2 or ENS? Tell me about it.
Book 20 minutes