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. Identity establishes permission. Accountability requires a record 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 strain it in two specific ways rather than invalidating it.
The first is volume and lifespan. A traditional service account is provisioned deliberately and lives for years. 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. 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. 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. The credentials involved were not the anomaly. What the agent did with them was.
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. The path is where the finding is, 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.
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.
A named human or team who answers for the agent’s existence and behavior. 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. 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.
An articulated purpose to judge behavior against. 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: the agent did something a named user could have done, at that user’s instigation. Standing authority does not. 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 rather than deliberate, decided by how the agent happened to be built rather than by what its accountability model should be. It is worth making explicit at design time.
Do you need NHI governance before agent governance?
You need identity as an input, not as a prerequisite phase. 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.
The two run together. Discovery establishes what exists, identity establishes what each is permitted to do, and behavioral observability establishes 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, and treating it as only that under-describes it. A service account has an identity and a fixed function. 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. 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, and the migration is partial in most estates. 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 before entitlements. Entitlement sprawl is a familiar problem with familiar tooling. 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. Decommissioning is the least-governed stage of the agent lifecycle, because 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.
