Get started
AI governanceAI agentsGovernanceAccess control

Role-based access was built for people. Your agents are not people.

Adam Cowles2026-09-20T20:30:00.000Z5 min read
A permission grid resolving into a single named, witnessed agent identity, cyan and violet over near-black

A role tells you what may happen. It does not tell you who it happened as. For a person those are close enough. For an agent they are not the same question at all.

Start with the question you actually have to answer when something goes wrong.

An action ran against your systems at 02:14. It moved data, or it approved a payment, or it changed a config. The board, the auditor, the customer all ask the same thing: who did that? For twenty years the answer has been a lookup. A user, a session, a role, a permission that let them. Role-based access control was built to make that answer cheap, and for people it works.

Then you put agents in the loop, and the lookup stops answering the question.

What a role does, and where it stops

RBAC is an authorisation model. It decides whether a caller holding a role is permitted to perform an action. That is a real job and agents still need it: an agent that can spend money should hold a role that says so, and one that cannot should be refused. None of what follows is an argument against roles.

The gap is that a role is a permission set, not a subject. It answers may this be done. It does not, on its own, answer three questions that only start to matter once the caller is an agent:

  • Which agent did this, out of the several that share the same role?
  • Acting as whom, when a live session is driving an agent rather than a person clicking a button?
  • On whose authority, when the thing that triggered the action was another agent, not a human at a keyboard?

Give ten agents the same role and RBAC sees ten identical callers. The permission check passes for all of them and the evidence, if there is any, points at the role, not the actor.

The impersonation problem

The naive fix is to let a caller say which agent it is. A session announces "I am SEER", the SEO analyst, and everything it does gets tagged SEER. This is worse than nothing, because it is a claim with no enforcement behind it. A session that can name itself can name itself anything. That is cosplay: the label is real, the identity is not, and the audit trail records a decoration.

An identity is only worth having if the system enforces it over anything the caller asserts. The claim has to come from something the caller cannot forge, and the actor type has to be set by the server, not accepted from the client. Otherwise you have added a field to your logs, not an answer to your question.

What we actually built and ran

We took the identity out of the client's hands. In Quox a live session can attach to an agent: it adopts that agent's real definition, its system prompt, its tool set, its model routing, and receives a signed token whose claim the server trusts over anything the session sends. The actor type is stamped server-side. The session cannot quietly promote itself.

We proved it once, end to end. An ordinary session attached as SEER and did a run of real work. Every step landed in the evidence log attributed to the agent, not to the host or the session that happened to be driving: the attach, each tool call, the memory write, the handoff, the detach. The record does not say "a caller with the analyst role did a thing". It says this agent did it, and it can be checked after the fact by someone who was not there.

Being straight about the maturity: this is Beta. The full loop has run once, on a single box with a single agent. That is real and it is not the same as soak-tested across a fleet, and we will say so when that changes.

Roles and identity are different layers

Hold the two apart and each does its job. The role is authorisation: it decides what is allowed before the action runs. The identity is attribution: it records who it ran as, in a form that survives the session closing and cannot be rewritten by the thing being audited. RBAC gates the door. Identity signs the logbook.

Most stacks ship the first layer and improvise the second, usually as a hopeful string in an application log. When the caller was a person that improvisation mostly held, because a person maps cleanly to an account. An agent does not: it is defined by a prompt and a tool set, it can be driven by different sessions on different days, and it can be set in motion by another agent. The subject got harder to pin down exactly as the number of actions exploded. That is the reason to make agent identity a first-class, enforced, witnessed thing rather than a field you fill in and hope.

So the honest one-line answer to "is RBAC enough for agents" is: it was never meant to be the whole story, and it shows the strain sooner with agents than it did with people. Keep the roles. Add an identity the caller cannot fake and an evidence trail the caller cannot edit, and "who did this?" goes back to being a lookup, this time one you can defend.

This is one piece of a larger argument about how agentic AI has to work when every action must be accountable to someone who was not in the room. The agent model is where the identity lives; the evidence is what lets you prove it after the fact.