Non-Human Identity vs Agent Accountability
Non-human identity (NHI) is the discipline of giving machine actors – service accounts, workloads, and now agents – their own identities with scoped entitlements, so access can be granted, reviewed and revoked. Agent accountability is the separate question of who answers for what an agent actually did, and while identity establishes permission, accountability also requires a record of the agent's actions and a named owner.
What is non-human identity, and how do agents change it?
Non-human identity covers every actor in an environment that is not a person: service accounts, workloads, API clients, and increasingly agents. The discipline is mature in its fundamentals – provision an identity, scope its entitlements, review them periodically, revoke when the workload retires. Agents don’t invalidate that discipline, although they strain it in two specific ways.
The first is volume and lifespan, because a traditional service account is provisioned deliberately and lives for years, whereas agents are created by people entitled to create them, spawn sub-agents, and are frequently short-lived. An entitlement review cadence designed for a stable population behaves poorly against one that turns over continuously.
The second is the nature of the authority. Where a service account does one predictable thing, an agent decides what to do within its permissions, which means the same entitlement grant covers a far wider range of possible actions. The grant is a weaker description of expected behavior than it used to be.
What does identity tell you, and what doesn’t it?
Identity answers what an agent is permitted to reach and under whose credentials it acts. That is genuinely necessary, and an agent without a distinct identity cannot be governed at all, because nothing can be attributed to it specifically.
What identity does not answer is whether the agent used that permission, how, in what sequence, or to what end. Permissions define what an agent can do, while its behavior tells you what it does.
The gap between those two is where the useful findings sit. Two agents holding identical entitlements can represent entirely different risk, because one exercises capabilities the other never touches. No entitlement review distinguishes them, since on paper they are the same agent twice.
An identity SaaS platform found an employee using an unsanctioned agent with credentials linked to a competitor, exposing customer data and company IP. Nothing about the credentials themselves was anomalous, and the problem only showed in what the agent did with them.
What does accountability require that identity doesn’t provide?
The structural way to see it is that identity resolves a single node, while accountability requires a path.
An agent sits in a chain of relationships: to its owner, to the identity it acts under, to the model behind it, to the tools and data it reaches, to the permissions those carry, to the work it performs and the outcomes that work produces. An identity system holds one node in that chain and the edge immediately either side of it. It can tell you which credential an agent holds and what that credential may reach. It cannot traverse further in either direction – back to who decided this agent should exist, or forward to what the agent did with the access and what resulted.
Accountability is a traversal of that whole chain: which agent, acting under which credential, on whose behalf, performing what work, producing what outcome. Each link is individually unremarkable, and the finding only appears in the path as a whole, which is why useful risk intelligence has to reach the level of the individual tool, user and credential rather than stopping at the identity record.
Three things follow from that, and an identity system supplies none of them on its own.
The first is a durable record of what the agent actually did, in a form that survives the session and cannot be edited by the system under review. That is the audit trail problem, and it is separate from the entitlement problem.
The second is a named human or team who answers for the agent’s existence and behavior, which matters because identity systems record which credentials an agent holds; they do not reliably record who decided the agent should exist, or who to contact when it does something unexpected.
The orphaned case makes this concrete. A developer configures an agent, or installs a capability it loads, and later leaves the organization. Offboarding revokes the person, but nothing revokes what the person set in motion, so the agent carries on operating under credentials attached to someone who no longer works there. OWASP describes exactly this scenario for skills, and the mitigation it implies is unglamorous but specific: agent and capability revocation belong in the offboarding playbook alongside accounts and devices. Very few offboarding processes currently contain either.
The third is an articulated purpose to judge behavior against, because without a statement of what the agent was for, a deviation is only a deviation from a statistical baseline, which is a considerably weaker basis for a decision than deviation from stated intent.
How do delegated and standing authority differ?
This is the distinction most worth getting explicit, because it changes the accountability question rather than just the access scope.
An agent can act on behalf of an invoking user, inheriting that person’s permissions for the duration of the task, or it can act under its own standing role, with its own permissions, independent of who triggered it. Major identity platforms now model both, and the difference is visible in the credentials.
Delegated authority keeps a person in the accountability chain, since the agent did something a named user could have done at that user’s instigation. Standing authority does not, because the agent acted under its own role, which means accountability falls to whoever owns the agent rather than whoever invoked it – and if nobody is recorded as owning it, accountability falls nowhere.
The failure mode is that this choice is often incidental, decided by how the agent happened to be built instead of by what its accountability model should be, so it is worth making explicit at design time.
Do you need NHI governance before agent governance?
Identity is an input to agent governance rather than a phase that has to finish first. An agent with no distinct identity cannot be attributed to, so identity work has to happen, but sequencing a full NHI program ahead of any agent visibility work tends to fail for a practical reason: you cannot provision identities for agents you have not discovered.
In practice the two run together, with discovery establishing what exists, identity establishing what each agent is permitted to do, and behavioral observability establishing what each actually does. A program that completes the middle step in isolation produces a well-governed inventory of the agents it already knew about.
Common questions
Is an agent just another non-human identity?
It is one, but treating it as only that under-describes it, because a service account has an identity and a fixed function while an agent has an identity, a set of capabilities, a context it reasons within, and latitude over what it does next. Identity captures the first of these, and the rest needs its own treatment, which is why posture covers configuration and behavior alongside entitlements.
Does agentic identity replace service accounts?
No, and the practical position is messier than either replacement or coexistence suggests. Many agents currently run under service accounts and shared credentials that predate them, which is precisely what makes attribution difficult. Purpose-built agent identity improves that, but the migration is partial in most estates, so it is safest to assume a mixed population.
Can you hold an agent accountable?
Not in any meaningful sense, which is why the term needs care. Accountability attaches to the people and teams who deploy agents and decide what they are permitted to do. What the agent needs is traceability: a record specific enough that a human can be answerable for it. Framing accountability as something the agent bears obscures where the responsibility actually sits.
What breaks first at scale?
Ownership usually breaks before entitlements do. Entitlement sprawl is a familiar problem with familiar tooling, whereas an estate where a material share of agents have no identifiable owner is a different problem, because every subsequent finding arrives with no addressee, and remediation stalls on the question of who should act rather than on what should be done.
It also constrains what controls are available. A graduated response that pauses an agent and waits for a decision only works if the system knows whose decision to wait for. Without an owner, the available options narrow to allowing the action or blocking it, which is the binary that context-specific control exists to avoid.
What happens to agents nobody retires?
They keep their credentials, because decommissioning is the least-governed stage of the agent lifecycle and nothing forces the question: an agent built for a project that ended does not announce its own obsolescence, and it continues to hold whatever access it was granted for work that no longer exists. Identity governance catches some of this through periodic entitlement review, but review cadences designed for service accounts behave poorly against a population that turns over continuously. The practical fix is tying each agent to an owner and a stated purpose at creation, so that there is someone to ask when the purpose expires.
