Role-based access control for AI agents assigns each agent a predefined role, a named bundle of permissions, and grants access based on which role the agent has, the same pattern that's run enterprise authorization for decades. It works reasonably well for agents whose job stays fixed and predictable: an agent that only summarizes support tickets can sit comfortably under a "read support tickets" role and never need anything else. Where RBAC starts to strain is with agents whose behavior varies task to task, because a role has to be broad enough to cover everything the agent might legitimately need, which usually means it's broader than what any single task actually requires.
Where RBAC fits naturally
Agents with a narrow, stable purpose are the best fit for RBAC. A billing-lookup agent, a document-classification agent, a scheduling assistant, each of these has a bounded, well-understood set of actions it performs, and defining a role around that set is straightforward. RBAC also gives you something valuable operationally: a small number of named roles are much easier to review, audit, and explain to an auditor than a sprawling set of ad hoc permission grants.
Where it starts to break down
Agents that handle varied, open-ended tasks, a general-purpose assistant that might need to query a database, draft a document, or send a message depending on what the user asks, don't map cleanly to one role. Either you create a role broad enough to cover every possible task, which over-permissions every individual task the agent actually performs, or you create many narrow roles and constantly reassign the agent between them, which adds operational overhead that RBAC wasn't really designed for.
Role granularity matters more for agents than for humans
Human RBAC often works with a handful of broad roles because a person's job function doesn't change every few minutes. An agent might switch from a read-only lookup to a data-modifying action within the same conversation, depending on what a user asks next. Roles built for agents need finer granularity than typical human roles, splitting read from write, splitting different tool categories, so that the role assigned for a given task doesn't quietly carry along capabilities the current interaction never actually needs.
Combining RBAC with per-task narrowing
A workable pattern uses RBAC as the outer boundary, defining the maximum an agent's role could ever authorize, and then narrows further per task using scoped, delegated tokens that carry only what the current request needs. This keeps the benefits of RBAC's auditability at the role level while avoiding the trap of letting every task run with the role's full breadth of access just because that's what was assigned.
Reviewing roles as agent behavior evolves
An agent's role should get revisited as its actual behavior is observed in production, the same way any permission scoping should. If an agent's role includes actions it's never actually taken, that's a signal the role is broader than necessary. If it's regularly being denied actions it needs, that's a signal to either add a specific, justified permission or reconsider whether the task belongs to that agent at all.
Migrating from ad hoc grants to defined roles
Many agent deployments don't start with RBAC at all; they start with a handful of permissions granted directly to get a prototype working, and RBAC gets introduced later once the number of agents and the number of one-off grants becomes too unwieldy to track individually. That migration is worth doing deliberately rather than all at once. Start by grouping the existing, ad hoc grants across your agents into natural clusters based on what they actually do, and define roles around those observed clusters rather than an idealized role structure that doesn't match how agents are really being used.
Rolling out the new roles gradually, agent by agent, and comparing what each agent could do under its old ad hoc grants against what it can do under its new role, catches mismatches before they become production incidents. It's tempting to skip this comparison step under time pressure, but it's exactly the step that reveals whether the new role structure is actually equivalent to, narrower than, or accidentally broader than what existed before.
Where TELEON fits
TELEON enforces policy at the tool-call boundary regardless of whether the underlying permission model is role-based, attribute-based, or a mix, evaluating whatever identity and role context the calling application presents. Its audit trail can help show whether an agent's actual tool call activity stays within its assigned role over time, which is useful evidence during a role review.
Designing the specific roles, their granularity, and how they map to an organization's agents and tasks is access management design work that happens outside the enforcement layer itself.
A short checklist
- Use RBAC for agents with a narrow, stable, well-defined task set.
- Split roles finely enough to separate read from write and distinguish tool categories.
- Avoid one broad role covering every task an agent might ever perform.
- Combine RBAC's outer boundary with per-task, scoped narrowing where agent behavior is dynamic.
- Review roles periodically against actual observed agent behavior, not assumed behavior.
- Keep the number of roles manageable enough to audit and explain clearly.
- Reassess whether RBAC alone is sufficient once an agent's task variety grows significantly.
RBAC isn't the wrong model for AI agents, it's a model that fits some agents well and others poorly, and the difference comes down to how predictable the agent's job actually is. The mistake isn't choosing RBAC, it's assuming one role, defined once, will keep fitting an agent whose responsibilities keep quietly expanding underneath it.