The non-human identity problem: why the agent, not the human, is now the control plane attackers target

Why is every AI agent a new identity that multiplies silently?

An AI agent is not a feature bolted onto an app. It is an actor. To read a database, call an API, or send a message, it needs credentials, a token, a key, a service account. That makes each agent a distinct non-human identity, indistinguishable at the wire level from any other principal asking for access. The difference from a human user is scale and speed: agents spawn sub-agents, request fresh tokens, and provision new access paths without a person in the loop.

The result is silent multiplication. One deployed workflow can generate dozens of downstream identities, each with its own reach, and none of them tied to a face or an offboarding date. Human identity growth is bounded by hiring. Machine identity growth is bounded only by how much you automate, which is to say, effectively unbounded. Security teams built for the first curve are now facing the second, and the gap is where attackers operate.

What does the 2026 non-human identity data actually show?

The numbers from 2026 reporting tell a consistent story: incidents are common, breaches are widespread, and the visibility needed to catch them is scarce. Read the runtime-visibility figure against the incident rate, because that gap is the whole problem in one frame.

What does the identity gap look like in one downloadable picture?

It looks like a chasm between what is happening and what defenders can see. The infographic below puts the two sides next to each other: near-universal incidents and widespread breaches on one side, scarce runtime visibility and a real tracking vacuum on the other. Download it for your next security review.

Why do so many organizations fail to track their AI identities?

You cannot protect what you have never counted. The Cloud Security Alliance reports that more than 16% of organizations do not track the creation of AI identities at all, describing a genuine non-human-identity governance vacuum. That figure is easy to skim past, but sit with it: for one in six organizations, agents are being born into production with no registry, no owner, and no lifecycle. They are invisible by default.

This vacuum compounds everything else. Sophos’ State of Identity Security 2026 found that 71% of organizations suffered at least one identity breach in the past year, and secondary 2026 reporting suggests only around 21% have runtime visibility into their agents. An untracked identity cannot be reviewed, rotated, or revoked, because no one knows it exists. When the inventory is missing, every other control is operating blind, and the attacker’s job is simply to find the identity the defender forgot.

The reasons the vacuum forms are ordinary, which is exactly why it is so common. Agents are created by developers and platforms in the flow of building features, not by an identity team following a provisioning process, so there is no natural checkpoint where a new identity gets registered and assigned an owner. Many are spun up by other agents, one layer removed from any human decision at all. And because a working agent looks like productivity rather than risk, no one has an incentive to slow down and catalog it. The result is that the inventory gap is not a single oversight to fix once; it is a structural byproduct of how fast automation ships, which is why closing it requires making identity a property an agent is born with rather than a record someone remembers to create afterward.

How do non-human identity compromises actually happen?

The attack paths are not exotic. They are the same identity failures that have plagued service accounts for years, now multiplied across a workforce of agents that no one is watching in real time. Three patterns account for most of the damage:

• Over-permissioned credentials: an agent is handed far more access than its task requires, so a single compromise becomes a broad one; the blast radius is set at provisioning time, not attack time.
• Unrotated or leaked secrets: long-lived tokens and keys sit in code, config, and logs, and because no one is tracking the identity, the secret is never rotated and its exposure is never noticed.
• No revocation path: when an agent is retired or turns out to be compromised, there is no clean way to kill its identity, so stale credentials keep working long after they should have gone dark.

What makes machine identities harder to secure than human ones?

It comes down to four differences, and each one bends a control that was designed for people. The first is scale: machine identities already outnumber humans by a wide margin, with CyberArk’s 2025 research putting the ratio near 82 to 1, so any process that assumes a reviewable number of accounts is immediately swamped. The second is speed: humans are onboarded in days and offboarded on a known date, while agents appear and provision access in seconds and often have no offboarding date at all, so the lifecycle controls that work for employees never get a chance to run. The third is attribution: a person is behind one identity, but an agent can spawn sub-agents and delegate, so a single action at the end of a chain may trace back through several machine identities to an original principal that no one recorded, which is exactly where confused-deputy attacks live.

The fourth, and the one that ties the others together, is proof. When a human does something questionable, there is usually a trail: a login, a device, a session. When an agent does something questionable and its identity was a shared, long-lived secret that many callers hold, there is often no way to say which agent did it or whether it was even authorized. That absence of proof is what turns an untracked machine identity from an inconvenience into a genuine soft target, because the attacker who rides it leaves no more trace than the legitimate agent would have. Securing machine identity is therefore less about adding another gate and more about making each agent uniquely identifiable, tightly scoped, cleanly revocable, and provable after the fact, which is the opposite of the shared-secret status quo. The same shift is covered from the agent-runtime angle on AI agent security.

How do you give each agent a provable, revocable identity?

The fix is not another dashboard bolted onto an untracked fleet. It is a change in what an identity is. A shared, long-lived secret answers only one weak question, whether the caller holds the key. It says nothing about which agent this is, what it is allowed to do, or whether that permission still holds. RankShield’s honest position is that you cannot secure what you cannot uniquely identify and prove, so the starting point is giving every agent a distinct, least-privilege, revocable identity rather than a reused credential.

Attestation goes one step further: a verifiable record of what each agent actually did, where verifiable means independently checkable rather than taken on trust. When identity is distinct, permissions are scoped tight, revocation is real, and actions leave a record anyone can verify, the machine identity stops being the soft target. The tracking vacuum closes because the identity was provable from the moment it was created, not reconstructed after a breach. See how this is delivered on agent passports and the attestation API.

How exposed are your own machine identities?

Run the quick check below. It scores your posture against exactly the failure modes the 2026 data reveals: untracked creation, over-permissioning, missing revocation, and no verifiable record. The point is to find the gaps while they are cheap to close.