What is a non-human identity?
A non-human identity is an account something other than a person acts under: a service account, an API key, an OAuth token, a webhook secret, or the credential an AI agent uses to reach a system. They behave differently from staff accounts in three ways that matter. Nobody joins or leaves, so there is no event that prompts a review. They rarely expire. And when one is used, the log records the identity rather than the person who set it up, so an action taken under it has no author unless something else recorded one.
Why agents made this worse
Service accounts and API keys are older than any of this. What changed is the rate of creation and who creates them. Connecting an agent to a system takes a few minutes and produces a credential, and the person who does it is doing it in the middle of building something else rather than as an act of provisioning.
The permissions attached tend to be whatever the consent screen asked for, which is written to cover everything the vendor might ever need, not what your agent does. That is not carelessness. It is the default, and nothing in the flow suggests that a decision is being made.
The result is a population of credentials that grows steadily, is scoped generously, belongs to nobody in particular, and does not appear on any list until somebody goes looking. The joiners and leavers process that catches a departing employee's access has no equivalent here.
The two questions that matter most
Where is the credential held, and can you kill it. Those two travel together, and a shipped RedHub gate treats them as a pair for a reason: a credential stored in a config file with a working revocation path is recoverable, and so is a vaulted credential with a slow revocation path. A credential that is both loose and un-killable is neither.
Storage is the easier of the two to check and the one most often quietly wrong. A credential in a prompt is a credential in every log line, every trace and every copy of that conversation, which means the blast radius of a leak includes places nobody thinks of as a secrets store.
Revocation is the harder one, because it is widely believed to exist and rarely exercised. The path frequently turns out to depend on a vendor portal, a person who is on leave, or a rotation that takes a working day. That is worth discovering deliberately rather than during an incident.
An identity of its own, with a person attached
An agent running under a staff member's account inherits every permission that person has accumulated, which is invariably wider than the agent's job, and it makes the audit log say that a human did something a human did not do. The first hour of an investigation then goes on establishing that.
The fix is an identity created for the agent, granted only what the agent needs, with a named person accountable for it. The accountable person is not the operator of the credential. They are the one who can answer the question of why it exists and what it is allowed to do, and naming a team instead is the most common answer and is not one, because a team cannot be asked.
Being accountable for an identity is not the same as being answerable for everything done under it. The designation is an internal governance arrangement: it decides who can say why the credential exists and what it may reach. It does not determine what any individual is personally liable for when an agent acts, which is set by law and by the arrangements between a person and their employer rather than by an owner field. Who is appropriate to name is a question for your own counsel or HR, and this site does not answer it.
Common questions
- How many non-human identities does a company typically have?
- Usually more than it has staff accounts, and the number is not knowable without looking. The useful exercise is not estimating it but enumerating them per system: every integration, every scheduled job, every agent, every webhook. The gap between the list somebody produces from memory and the list the systems hold is the finding.
- Do non-human identities need owners if they are scoped tightly?
- Yes, and scoping is what makes ownership tractable without being a substitute for it. Scope answers what the credential can do. An owner answers who decided it should exist and who notices when it should not any more. A tightly scoped credential nobody owns still outlives the reason it was created.
- What is the difference between rotating and revoking?
- Rotation replaces a credential on a schedule and is a hygiene measure. Revocation kills one on demand and is an incident measure. A rotation schedule is not a revocation path, and discovering that during an incident is the ordinary way it gets discovered.
Find out where you stand
The assessment on this site asks up to 24 questions about what your agent can reach and what happens when it is wrong, and returns a score, a verdict and, where a control is short, the one thing to fix first. It takes about ten minutes, and questions your agent has no surface for are dropped rather than scored against you.
It is a self-assessment of design, permissions and recovery, not a penetration test, not an audit of a running system, and not a certification.
Run the assessment