Recent industry studies report tens to more than 100 machine identities per human, depending on what is counted and the environment measured.
Most enterprise identities are no longer human, yet we govern them as an afterthought. The gap between what machines are allowed to do and our ability to see, own, and stop them accrues like debt: silent, until an attacker calls it. Closing it takes five moves.
- Separate the six objects. A principal acts; a credential is only presented. Govern the relationships, not one blurred thing called a secret.
- Bind a lifecycle to every machine. Machines inherit none, so creation, ownership, renewal, and retirement must be deliberate.
- Reason about reachability, not inventory. Blast radius is the reachable subgraph, not a row in a list.
- Govern at machine speed. Resolve, reason, decide, enforce, and prove in a closed loop, because human-speed review cannot keep up.
- Converge on one control plane. Resolve every fragment back to one principal and the owner accountable for it.
The accountability gap
The modern enterprise is run by identities that are not human. They do the majority of the work, hold the credentials that move the data, and reach the most sensitive systems an organization owns. The market answered with hygiene: vault the secrets, scan the repositories, flag the misconfigurations, inventory the accounts. Each is worth doing. But hygiene is not a strategy, and an inventory is not a defense.
Identity security keeps authority connected to evidence and control. Every consequential action should be attributable to a known principal, the credential and grant it exercised, the runtime from which it acted, the purpose or delegation behind it, and an accountable owner or sponsor with the ability to intervene. Accountability, then, is an organizational capability, not a trait of the machine.
The accountability gap is the distance between the authority non-human identities can exercise and the organization's ability to identify, govern, observe, and stop that authority. It behaves like debt: every grant issued without the accountability a human equivalent would have demanded is a borrowed convenience, and the interest comes due the day an attacker finds it. Most organizations have no idea how large the balance has grown.
What a non-human identity actually is
A non-human identity is not one thing, and most of the trouble starts the moment we treat it as one. It is six linked objects, and only one of them acts. The principal is that actor: a workload, a service, an agent. The credential it presents, an API key or a token, is only proof, never the actor itself.
The other four objects describe and constrain that actor: the grant is what it may do, the runtime is where it executes, the resource is what it reaches, and the accountability context is who answers for it. Hold the six apart and every action has a clear story. Blur them into one thing loosely called a secret, and you can no longer answer the questions that matter: who acted, with what authority, and on whose behalf.
Autonomy is an attribute a principal can have, not a class of its own, so an agent is a principal too. We scope this paper to enterprise software and agent identities, not device, PKI, or IoT, and we use the word machine as a familiar shorthand for one of them.
Three asymmetries between human and machine identity
If machines were simply more numerous, this would be a capacity problem, solvable by buying more of the tooling we already have. It is not. Machine identities differ from human ones in three asymmetries that break the assumptions every identity program is built on.
The first is lifecycle. People arrive, are reviewed, and eventually leave, and their access is granted and revoked along the way. A machine inherits none of that rhythm. Nothing creates it, owns it, or retires it unless someone deliberately decides to, so its credentials routinely outlive the workload they were issued for and quietly never expire.
The second is context. Human authority stays bound to a known individual. Machine authority is handed from one service to the next, and at each handoff the power crosses intact but the context falls away: who it was for, why it was granted, how far it was meant to reach. What survives at the far end is full authority that no longer remembers its purpose.
The third is speed. People act slowly enough to be noticed and questioned. Machines act at machine speed, and an agent goes further, deciding at runtime which tool to call and which authority to use. Authorization stops being a setting configured once and becomes a live decision, made faster than any review can follow.
The non-human majority is not a backlog to clear. It is the permanent condition of the enterprise.
The four questions every identity must answer
Strip identity security to its essence and it asks four questions of every actor. What are you. What authority are you exercising. What are you doing right now. Who owns you, and who can stop you. The diagram below sets out what each question must resolve, from principal and credential to scope, runtime, and accountable owner.
For a human these four usually hold together and stay anchored: one principal, a scoped grant, a watched session, a named owner. For a machine the same four frequently fragment apart, and each fracture is a question the system can no longer answer. The ones you cannot answer are not abstract risk. They are the accountability gap, made specific, one token at a time.
Why human controls do not transfer directly
The instinct to point existing IAM at the problem fails, because nearly every human control is built around context the machine lacks: a person present to be prompted, the friction of a lifecycle, a reviewer who recognizes the account, the luxury of human time. The discipline is right. The mechanisms must be rebuilt.
Read the right-hand column top to bottom and you have the specification for non-human identity security. Read it against your current tooling and you will likely find that no single product delivers more than a fraction of it. That fragmentation is the reason the problem persists.
How risk propagates
The danger does not announce itself as sophisticated hacking. The scenario below is a composite drawn from recurring incident patterns, and it looks like this.
On a Tuesday, under deadline, an engineer generates a credential so a new service can read from a production database. To save time the scope is broad, the whole database, not the one table the service needs. The key is pasted into a config file and, in the rush, a help-desk ticket. The feature ships. The engineer moves teams. The key is never rotated, because no one is responsible for rotating it. It is, in effect, immortal. Eighteen months later it resurfaces, still valid, still reading the entire database, used at 3 a.m. from an address no one recognizes. No alarm fires, because nothing was ever watching that identity.
The same skeleton recurs across incidents. A credential escapes its boundary, persists because no one rotates it, carries far more privilege than its task required, meets nothing that segments the systems it can reach, and is watched by nothing at runtime. The lesson is not that the last gate failed. Prevention was possible at every one. Discovery alone would not have stopped it; it would only have listed the key. And silence is what lets impact compound: the unanswered what are you doing now, where dwell time stretches into months.
This is not hypothetical. The 2025 Salesloft Drift compromise followed this pattern exactly: OAuth tokens for a third-party integration leaked, were never scoped down or watched, and cascaded into hundreds of downstream customer environments. A machine credential, over-privileged and unobserved, exercised by someone no one could stop.
So the real question is never how many of these do we have. It is what becomes reachable if this one is taken. These objects are not a flat list; they form a typed graph of authority, where a principal runs as a runtime, presents a credential, holds a scoped grant, is owned by an accountability context, and can reach a resource. Each edge is a different kind of relationship, conditional, not an automatic inheritance of everything in view, so impact follows the path rather than the headcount.
The agentic inflection
Agents do not merely add identities to the count. One execution activates a set of real, distinct objects at runtime: multiple principals, credentials, delegated contexts, tool relationships, and downstream actions. Authorization stops being static and becomes a sequence of runtime decisions, fanning out faster than any review can follow. Autonomy is a risk dimension measured along velocity, reach, and exposure, not the single riskiest class.
Agents reach the world through tool protocols, with the Model Context Protocol prominent today. An MCP server is not inherently insecure, but it can become a high-value authorization intermediary when it holds broad downstream credentials, accepts tokens meant for other resources, or loses delegation context, the classic confused deputy.
The harder problem is cross-domain delegation across boundaries that are independently governed, not unguarded. Cross-domain risk is not authority breaking through, it is context leaking out. At each boundary, authority gets re-translated, and identity, purpose, and provenance fall away. This is the transitive-authority asymmetry at its most acute, and precisely the case secrets vaults, cloud posture tools, and human-centric identity providers were never built to see. The conclusion is not that identity security and AI security are the same discipline, but that identity is a foundational control plane within AI security.
Autonomy turns a permission into a sequence of decisions and actions.
The control loop
Almost every capability that closes the gap already exists somewhere, discovery here, vaulting there, posture in the cloud, detection on the endpoint. The reason the gap persists is that those capabilities live in separate tools that each see only a fragment. Correlation creates context, but context alone is not control. Control is a continuous loop.
The loop runs in five stages, each handing off to the next. Resolve stitches fragmented observations from many tools into one typed graph, keeping the six object types distinct and tagging each fact with confidence and provenance, not collapsing them into one merged identity. This is where the six shadows of a single actor finally resolve to one principal and the owner accountable for it. Reason computes authority, delegation lineage, effective reach, and risk. Decide applies policy, context, confidence, and impact. Enforce takes a proportionate response: deny, revoke, constrain, rotate, quarantine, require approval, or escalate. Prove preserves the evidence and the decision for audit, and that record loops back to enrich resolve. This is the move from context to control: correlation tells you what is reachable, the loop decides what to do about it.
Where to start, and the mandate
Sequencing is where most programs stall, so our guidance is deliberately opinionated, but it is not a strict order. Run three workstreams in parallel, with risk setting priority. Stop creating new debt by fixing ownership, short-lived credentials, and tested revocation at creation time. Reduce legacy debt by risk, prioritizing the orphaned, the privileged, the externally exposed, the long-lived, and any path that reaches the crown jewels. Monitor and contain present risk, instrumenting critical identities now and enforcing with graduated, reversible controls. The three feed one another: what you stop creating shrinks tomorrow's legacy, what monitoring learns retargets remediation, and what remediation clears narrows what must be watched.
A word of honesty: automated revocation that misfires can break a production pipeline at 3 a.m. as surely as an attacker can. The answer is not to avoid runtime enforcement but to ground it in correlation and confidence. The full maturity matrix and scorecard live in a companion assessment.
None of this asks for a sixth framework to memorize. The five principles below are how a program answers the four questions: four map to a single question each, and the fifth resolves all four into one accountable story.
Separate the six objects, never conflate them
A principal acts; a credential is only presented; a grant, a runtime, a resource, and an accountability context describe it. Govern the relationships among them, not a single blurred thing called a secret.
Bind a lifecycle to every machine
Because machines inherit none, deliberately bind creation, ownership, renewal, and retirement to a service and a purpose, so engineered decay and re-authorization replace the immortal static credential.
Reason about reachability, not just inventory
Map the typed authority graph and govern potential, effective, and observed reach, because blast radius is the reachable subgraph, not a property of a single node.
Govern authority at machine speed
Resolve, reason, decide, enforce, and prove in a closed loop, acting decisively where evidence is unambiguous and escalating where it is not, because human-speed review cannot govern machine-speed actors.
Converge on one control plane
Treat identity as a foundational control plane within AI security, and resolve every fragment back to one principal and the owner accountable for it, so an identity's full chain of action is a single, governable story.
One short example shows how the model works, not what a product ships. A user authorizes an agent to summarize records. The agent instead attempts a bulk export through an MCP tool, using a broad downstream credential. The loop resolves the user session, the agent runtime, the grant, the tool call, and the SaaS action into one path. Policy flags the mismatch between the authorized task and the observed behavior. A confident decision denies or revokes the action, and the action and its owner are preserved as evidence. Authority, tied back to accountability, for a machine.
Objections we hear
Three objections come up in nearly every conversation. Each is reasonable, and each stops short of the problem.
We already have a secrets vault.
A vault stores and rotates what you put in it. It does not discover unmanaged credentials across repos, pipelines, SaaS, and agent configs, assign ownership, right-size privilege, or watch runtime behavior. Necessary, and insufficient.
Our cloud and posture tools cover this.
Posture finds misconfiguration within a cloud. Non-human identities cross the IdP, SaaS, browser, and endpoint, and the risk lives in the path across them, which a single-surface lens cannot see.
Agents are still a small fraction of our identities.
True by count today. But an agent is not one more identity; one execution activates many principals, credentials, and tool relationships at runtime, so it makes authorization dynamic rather than merely adding to it. That is a new risk dimension to plan for now, not a row to wait on.
Identity security, evolved for a world where most identities are not human.
Answer the four questions, for every machine.
See Identra in action