Role-based access control (RBAC) is a way of managing permissions in which access is granted to roles, such as "claims handler" or "payments clerk", and users or systems receive access by being assigned a role. For AI agents, RBAC decides what an agent can reach. It does not, on its own, decide how far the agent may act.
Why does role-based access control matter for agents?
RBAC is how most organisations already manage access, so it is the natural place to start. Giving an agent a defined role, rather than a pile of individual permissions, makes its access readable, reviewable and consistent with how staff are treated. When an auditor asks what the onboarding agent can touch, the answer is the role's permission list.
The risk is assuming a role is enough. A human payments clerk has the payments role and also has judgement, training and a manager. An agent with the same role has the permissions without the rest. RBAC tells you the agent can open the payments screen; it says nothing about whether it has proven it can pay correctly.
How does it work in practice?
The pattern for agents has four steps.
- Write the role first. Describe the agent's job: its purpose, the tasks it performs, what it must never do. An agent role charter is a useful format, and what an AI agent's role description should include lists the fields.
- Derive permissions from the role. Map each task to the systems and fields it needs. Anything not needed is not granted.
- Assign the role to the agent's own identity, not to a shared account.
- Review it alongside staff roles, and whenever the agent's job changes.
The role then becomes the agent's role scope: the outer edge of what it may do. Practical guidance on drawing that edge is in how to set an AI agent's role scope.
What does an example look like?
A business bank creates an "onboarding assistant" role for an agent. The role can read applications, check company registry data, request missing documents and write notes to the case file. It cannot approve applications, open accounts or change risk ratings. The onboarding team lead owns the role and reviews it with the team's other roles. When the bank later wants the agent to pre-fill account set-up, the role is changed first, through the same approval as any staff role change.
How is RBAC different from role scope with depth?
RBAC answers a yes-or-no question: can this identity reach this system or function? Agents need a second answer: how far may it act there? An agent may be allowed to reach the refunds function but proven only to draft refunds, not issue them. In our model that second answer is depth, earned capability by capability through certification. RBAC and depth work together: the role sets the outer edge, the certificate sets how far inside it the agent may go, and the customer's own limits narrow it again. Without depth, an agent with the right role can still go beyond what its job should allow by doing too much within it.
It also differs from attribute-based access control, which decides access from attributes such as amount, time or location. Customer limits often play that part for agents.
Which terms sit close to it?
Least privilege is the principle RBAC serves. Non-human identity is what the role is assigned to. Segregation of duties uses roles to stop one identity doing incompatible tasks. See our guide to agent governance for how these fit together.
Questions people ask
Can an agent hold more than one role?
It can, but every extra role widens its reach and makes its access harder to explain. Where an agent seems to need two roles, it is often better split into two agents.
Should agents share roles with staff?
They can share a permission set, but give agents their own role names so access reviews, audit queries and incident responses can find them quickly.