Non-Human Identity: The Access Review Nobody Runs

Most organisations run a quarterly access review. Someone exports the list of who can reach which system, managers confirm their people still need what they have, the exceptions get revoked, and the evidence goes in a folder for the auditor.

That list enumerates people. An autonomous agent holds delegated permissions — often broader than any individual's, because it was provisioned once to work for everyone — and appears on no list at all. The review completes, the evidence is filed, and the most permissive actor in the environment was never in scope.

The access review did not fail. It ran correctly against a population that no longer describes who acts in your systems.

Why agents fall through

Access governance grew up around a model with two clean categories: humans, who are reviewed, and service accounts, which are static and change rarely. An agent is neither. It acts on behalf of a person, sometimes several, and what it does next is decided at runtime rather than at provisioning time.

• It is not a person, so joiner-mover-leaver never touches it. Nobody offboards an agent.
• It is not static, so the annual service-account sweep does not describe it either.
• Its permissions are usually a union — it needs whatever any of its tasks might need, so it accumulates.
• It acts under delegation, so the audit trail may record the human it acted for rather than the agent that acted.
• It was created by an engineer solving a problem, not by an identity process.

That last point is the structural one. Human identities are created by a process that exists to govern them. Agent identities are created by whoever needed one, which means the governing process learns about them afterwards, if at all.

What the frameworks already require

None of this needs new regulation to become your problem. SOC 2's Trust Service Criteria require that access be restricted based on role and reviewed periodically — the criteria say access, not human access. DORA requires financial entities to manage ICT risk across their systems, and an agent with production permissions is squarely inside that.

So the question in a vendor-risk review is not whether a novel control applies. It is whether the control you already claim to operate covers a population you have not been counting.

The three questions to answer first

Which agents can act, and with whose authority?

An inventory derived from what actually ran, rather than maintained by hand. A hand-maintained list is accepted right up until a reviewer finds one run that contradicts it — and runs are the one thing that cannot be tidied retroactively.

What can each one reach?

Not the permissions it was granted — the permissions it exercised. The gap between the two is the least-privilege finding, and it is usually large, because an agent gets provisioned for the widest task it might ever perform and then performs the narrow one.

Who approved that, and when was it last looked at?

This is the one that turns an inventory into evidence. A list of agents and scopes describes the present. A record of who granted each scope, when, and when it was last reviewed is what a control assessment is actually testing.

Roles are the easy half

A layered role model — platform, organisation, workspace — is worth having, and it is well-understood territory. Owner can delete; admin can configure but not delete; member can operate; viewer can read. None of that is difficult, and none of it is where the finding comes from.

The finding comes from the population the model is applied to. A carefully designed six-role hierarchy that governs people, running beside agents provisioned outside it, produces a confident answer to the questionnaire and a gap underneath it.

Attribution is the control that makes the rest work

Every other control here depends on being able to say which identity performed a given action. Without attribution on the run, an inventory cannot be derived, exercised-permission analysis is impossible, and the access review has nothing to review.

Attribution is also where delegation gets subtle. If the trail records only the human on whose behalf the agent acted, you can answer who authorised the work and not what acted. If it records only the agent, you lose the authority chain. Both belong on the record, and treating them as one field is a decision you will regret in front of a reviewer.

Where Dobby fits

Dobby reads run telemetry out-of-band — CrewAI, LangChain, OpenAI, Google ADK or a custom SDK — and never sits in the request path. Each run carries the identity that triggered it, so the agent inventory is derived from what ran rather than from a list somebody maintains.

Where the telemetry does not carry an identity, the access-control verdict returns unverifiable rather than compliant, and the gap report names the field that is missing. That is the honest result: whether an action can be attributed is a property of your instrumentation, and reporting a pass on an unattributable run would be exactly the false compliance this control exists to catch.