In most enterprises, non-human identities already outnumber human ones by a wide margin. Service accounts, API keys, tokens, certificates, machine identities, the silent majority of every directory. For years they were the unglamorous plumbing of enterprise IT, and for years they have also been one of the most reliable ways into a breached network, precisely because no one was watching them as closely as they watched the humans.
The security industry noticed. Non-human identity has become a named category, with its own tools, its own playbook, and its own budget line. Inventory every machine identity. Vault the secrets. Rotate the credentials. Scope the privileges. Deprovision what is no longer used. It is a sound playbook, built over a decade of treating machine identities as first class citizens of the security model rather than an afterthought.
Then AI agents arrived, and they are non-human identities of a kind the playbook was never designed for.
An agent authenticates, holds credentials, and acts on systems, which makes it a non-human identity by every definition. But it is not a service account. It does not do the same deterministic thing forever. It reasons, decides, and acts with open ended judgment, at machine speed, and it can be manipulated by the data it reads. The NHI playbook governs the credential. The agent's risk lives in the action. This piece is about that gap, why the existing non-human identity controls are necessary but not sufficient for agents, and what closing it actually requires.
What Non-Human Identity Was Built to Solve
To see why agents break the model, start with what the model was for.
A non-human identity is any identity that is not a person: a service account that lets one system call another, an API key that authenticates an integration, a machine certificate that identifies a server, a token that a workload presents to a resource. These identities exist because software has to authenticate to other software, constantly, without a human in the loop.
They were a problem long before agents, for reasons that have nothing to do with AI. There are too many of them to track by hand. They accumulate broad privileges that no one prunes. Their secrets get hardcoded, leaked, and reused. They outlive the systems that needed them, becoming orphaned credentials that still work. And because they operate silently in the background, a compromised non-human identity can be used for a long time before anyone notices, which is exactly why they feature in so many breaches.
The non-human identity playbook is the industry's answer to these problems, and it has a clear shape.
| NHI control | What it addresses |
|---|---|
| Inventory and discovery | You cannot secure identities you cannot see |
| Secrets management | Stop hardcoding and leaking credentials |
| Rotation | Limit the useful lifetime of a leaked secret |
| Least privilege scoping | Reduce what a compromised identity can reach |
| Lifecycle and deprovisioning | Remove identities when they are no longer needed |
| Posture and anomaly detection | Spot a machine identity behaving abnormally |
Read the right hand column carefully. Every one of these controls is about the credential and its access. Is the secret protected. Is it current. What can this identity reach. Is it still needed. Is it behaving like it usually does. The entire playbook operates at the level of the identity and its permissions. It assumes that if you secure the credential and scope the access correctly, you have secured the identity, because for a traditional non-human identity, the credential and the behaviour are tightly coupled. A service account with a well managed secret and a tight scope does a predictable, bounded thing. Secure the credential and you have bounded the risk.
That assumption is exactly what agents break.
Why Agents Are a Different Kind of Non-Human Identity
An agent satisfies the definition of a non-human identity and then violates every behavioural assumption the playbook was built on.
A traditional non-human identity is deterministic. The payment service does the payment service's job. Its behaviour is fixed at development time and visible in its code, so a tight scope on its credential genuinely bounds what it does. An agent is not deterministic. It decides what to do based on model reasoning over a context window, so its behaviour is not fixed and not visible in advance. The same agent, with the same credential and the same scope, can take entirely different actions depending on what its model decides.
A traditional non-human identity has a stable baseline, which is what makes anomaly detection work. It does roughly the same things at roughly the same rate, so genuine anomalies stand out. An agent has no stable baseline. Its whole purpose is to handle varied, novel tasks, so "unusual behaviour" is its normal mode, and anomaly detection against a baseline that does not exist produces noise, not signal.
A traditional non-human identity is not manipulable by data. You cannot talk a service account into exceeding its function by sending it a cleverly worded input. An agent can be manipulated exactly this way. The content it reads can change what it does, which means an attacker who cannot touch the credential at all can still redirect the identity's behaviour through the data it processes.
And a traditional non-human identity is static and inventoriable. It is provisioned, it exists, you can list it. Agents spawn sub agents, run ephemerally, and compose into chains, so the population of acting identities at any moment is fluid in a way a static inventory cannot capture.
| Property | Traditional NHI | AI agent as NHI |
|---|---|---|
| Behaviour | Deterministic, fixed in code | Non-deterministic, decided at runtime |
| Baseline | Stable, enables anomaly detection | None, novelty is normal |
| Manipulable by input | No | Yes, by the data it reads |
| Scope bounds the risk | Yes, credential and behaviour coupled | No, behaviour decoupled from credential |
| Inventory | Static, listable | Fluid, spawns and chains |
| Accountability | An owner, indirectly | None per action |
The middle assumption is the load bearing one. For a traditional non-human identity, securing the credential and scoping the access bounds the behaviour, because behaviour and credential are coupled. For an agent, they are decoupled. A perfectly vaulted, freshly rotated, tightly scoped credential held by an agent tells you nothing about whether the next action the agent decides to take should be allowed, because the action is chosen by model reasoning, not fixed by the credential. The playbook secures the thing that is no longer the source of the risk.
The Credential Is Not the Risk Anymore
This is the heart of it. The non-human identity playbook secures credentials because, historically, the credential was the risk. Steal the secret, become the identity, do what the identity can do, which was a bounded and predictable set of things. Protecting the secret protected the system.
For an agent, the credential is necessary but no longer where the danger concentrates. An agent with a completely secure, unleaked, properly rotated credential can still cause a catastrophe, because the risk is not someone stealing its identity. The risk is the legitimate identity, holding a legitimate credential, being reasoned or manipulated into taking an action it should not. No credential control touches this. The secret was never exposed. The rotation was on schedule. The scope was correct. And the agent still issued the refund, sent the data, or deleted the records, because it decided to, and nothing evaluated that decision.
Traditional NHI threat model:
attacker steals credential ──► becomes identity ──► bounded misuse
defence: protect, rotate, scope the credential ← the playbook works
AI agent threat model:
legitimate identity, secure credential
│
▼
agent decides (or is manipulated into) an action it should not take
│
▼
action executes on a valid credential
defence: ??? ← the credential playbook has nothing here
The non-human identity controls are not wrong. They remain necessary. You still must vault the agent's secrets, rotate them, scope them, and inventory the agent as the identity it is. An agent with a leaked credential is still a disaster in the ordinary way. But securing the credential is now table stakes that addresses the old risk while leaving the new one untouched. The new risk is the action, and the action needs its own control.
What Agents Need On Top of the Playbook
Closing the gap does not mean replacing non-human identity management. It means adding the layer the playbook never needed, because no previous non-human identity could decide its own behaviour.
The addition is action level authorisation. Every action the agent takes, on top of being performed by a properly managed identity with a properly scoped credential, is evaluated against policy, in context, before it executes. The non-human identity controls answer "is this a valid identity with access to this system." The new layer answers the question they cannot: "should this identity take this specific action, right now, given everything happening in this session."
The two operate together, at different levels.
| Layer | Question it answers | Governs |
|---|---|---|
| NHI management | Is this a valid, scoped, current identity | The credential and its access |
| Action authorisation | Should this identity take this action now | The behaviour |
Notice this is the same relationship as identity and authorisation everywhere else in security. Authenticating a human and authorising their individual actions are two different controls at two different levels, and no one confuses them. For non-human identities, the industry has historically collapsed the two, because a traditional machine identity's behaviour was fixed by its credential's scope, so authorising the identity effectively authorised the behaviour. Agents pull the two apart again. The identity is valid and the behaviour is still in question, which means non-human identities now need explicit action authorisation for the same reason humans always have: the behaviour is not determined by the credential.
This also resolves the manipulation problem that no credential control can touch. A manipulated agent holds a valid credential, so every credential control passes it. But the action it was manipulated into attempting is still evaluated against policy at the moment of execution, and policy the attacker cannot edit through the context window can decline it. The action layer catches what the credential layer structurally cannot see.
A Perfectly Managed Identity, Still a Breach
The argument is easiest to feel against a scenario where the non-human identity playbook is executed flawlessly and the breach happens anyway.
An enterprise deploys an agent to manage vendor payments. Its security team does everything the non-human identity playbook asks. The agent's credential is stored in a secrets vault, never hardcoded. It is rotated on a tight schedule. Its scope is least privilege, limited to exactly the payment and vendor APIs it needs and nothing more. The agent is inventoried as a first class identity, with an owner and a lifecycle. By every measure the non-human identity dashboard reports green. This is a model deployment of the playbook.
An attacker compromises a vendor record the agent reads as part of its normal work, planting content that manipulates the agent into redirecting a scheduled payment to an account the attacker controls.
Trace it through the non-human identity controls. The secret was never exposed, so secrets management has nothing to flag. The credential was current, so rotation is irrelevant. The action used only the payment API the agent was legitimately scoped for, so least privilege is satisfied; redirecting a payment is within the payment scope. The identity is known and inventoried, so discovery has nothing to report. Anomaly detection has no stable baseline for an agent that handles varied payments daily, so a payment to a new account does not stand out. Every control in the playbook passes, because every control in the playbook is about the credential and its access, and the credential was never the weak point. The behaviour was.
Now add action level authorisation. The redirected payment is intercepted before it executes. Policy evaluates it: the destination account is new and unverified, the change to a scheduled payment originated from vendor data the agent ingested rather than from an internal instruction, and the amount and pattern match a payment redirection risk. The verdict is escalate, a human reviews it, recognises the manipulation, and blocks it. A signed record captures the attempt and its basis.
| Control | Status in the breach | Caught it |
|---|---|---|
| Secrets management | Secret never exposed | No |
| Rotation | Credential current | No |
| Least privilege scope | Action within payment scope | No |
| Inventory and discovery | Identity known | No |
| Anomaly detection | No baseline to deviate from | No |
| Action authorisation | Redirect evaluated against policy | Yes |
Every non-human identity control was green, and the breach still happened, because all of them secure the credential and none of them evaluate the action. The single control that caught it is the one the playbook does not include. This is not an indictment of non-human identity management. The vault, the rotation, the scoping all did their jobs. It is a demonstration that their jobs do not include the thing that now matters most.
The Inventory Problem Gets Worse Before It Gets Better
There is a second, quieter way agents strain the non-human identity model, and it is worth naming because it is already happening in enterprises that have not noticed.
Non-human identity management depends on inventory. You secure what you can see, and the foundational control is discovery: knowing every machine identity that exists. This is already hard with static service accounts, which sprawl faster than anyone prunes them. Agents make it dramatically harder, because the population of acting identities is no longer static.
An orchestrator spawns sub agents. A workflow composes several agents into a chain. Agents run ephemerally, existing only for the duration of a task and then gone. The thing taking an action at any given moment may be a transient sub agent that did not exist a minute ago and will not exist a minute from now. A static inventory, built for identities that are provisioned and then persist, cannot capture a population that materialises and dissolves at the speed of task execution.
traditional NHI population agent population
account-a ████████████████ orchestrator ███████
account-b ████████████████ ├ sub-agent ██ (ephemeral)
account-c ████████████████ ├ sub-agent ██ (ephemeral)
service-x ████████████████ └ chain-call ███ (transient)
(static, listable, persistent) (fluid, spawns, dissolves)
This is why the answer cannot be inventory alone, even improved inventory. You will never have a clean, complete, point in time list of every agent and sub agent acting in a large deployment, because the population changes faster than any inventory refreshes. What you can do instead is enforce at the action. Every action, whoever takes it, transient sub agent or persistent orchestrator, passes through the same authorisation layer and is evaluated against the same policy. You do not need a perfect census of the actors if every action any actor takes is governed at the point of execution. The enforcement point does not care whether the identity behind the action existed an hour ago or a millisecond ago. It evaluates the action.
This inverts the traditional emphasis in a useful way. Non-human identity management leads with inventory and derives control from knowing the actors. For agents, you lead with action level enforcement and treat inventory as a supporting record, because the actors are too fluid to be the foundation. The stable thing to govern is not the identity, which comes and goes, but the action, which always passes through the layer.
The Same Lesson, One Level Deeper
The throughline connects this to a pattern the industry already knows. Every time a new class of actor has entered the enterprise, security has had to extend its identity and authorisation model to cover it, and every time the extension followed the same shape: authenticate the new actor, then authorise its actions.
Humans got authentication and then access control on their actions. Devices got identity and then posture based authorisation. Service accounts and workloads got non-human identity management. Each step brought a new actor under the same two part model: establish who or what it is, then govern what it does.
Agents are the newest actor, and they are mid extension right now. The first half is in hand: the industry correctly recognises agents as non-human identities and is starting to bring them under non-human identity management, vaulting their secrets and scoping their credentials. The second half is the gap. The action authorisation that every other class of actor eventually received has not yet been extended to agents, and agents need it more than any actor before them, because they are the first non-human identity whose behaviour is not determined by its credential.
the identity model, extended actor by actor
humans ──► authenticate ──► authorise actions ✓ both
devices ──► identify ──► posture-authorise ✓ both
workloads ──► NHI manage ──► scope access ~ behaviour fixed
agents ──► NHI manage ──► authorise each action ← the missing half
Treating an agent as a non-human identity is correct and necessary, and the enterprises doing it are ahead of those who are not. But an enterprise that manages its agents as non-human identities and stops there has done the first half of a two half job. It has secured the credential of an actor whose risk lives in the action, and left the action ungoverned. The non-human identity playbook brought agents to the door of the security model. Action level authorisation is what brings them inside it.
The agent is a non-human identity. It is also the first non-human identity that can decide, on its own, to do something it should not, and that single fact is why securing its credential was never going to be enough.
Xybern is the authorisation layer for enterprise AI agents. Every agent action is enforced, audited, and governed before it executes. Learn more at xybern.com or read the technical documentation at docs.xybern.com.