Role-Based Access Control for AI Agents

Overview

Take an HR assistant agent with one role, hr-assistant, holding read access to leave balances and compensation bands. A team lead asks about a direct report's remaining leave and it should answer. An individual contributor asks about a colleague's salary band and it should not. Same role, same grant, opposite correct outcomes, and nothing in the role can tell the requests apart. That is not a flaw in how the role was written. RBAC assigns permissions to a named job, and both requests come from the same job.

What makes it worse for agents than it ever was for people is arithmetic. A human in that role makes a handful of sensitive requests a day and has a manager. An agent serves everyone who can invoke it, at machine rate, and the role is now attached to two subjects: the agent and whoever it is acting for. Most role catalogues were designed when there was only one.

What RBAC Means for Agents

Role-based access control groups permissions into named roles and assigns those roles to actors instead of granting each capability one at a time. It is neither new nor vague. Ferraiolo and Kuhn formalised it in a 1992 paper at the 15th National Computer Security Conference; it became ANSI/INCITS 359-2004 on 11 February 2004, revised as INCITS 359-2012; and NIST cites an RTI International analysis estimating its RBAC research "saved industry $1.1 billion." Whatever its limits, that is three decades of operational evidence, which is more than any agent-specific authorisation scheme can claim.

For an agent, a role becomes a bundle that maps to a recognisable job:

• An IT operations triage agent reads alerts, acknowledges incidents and posts status updates, and cannot restart production services.
• A data analytics agent runs read-only warehouse queries and builds dashboards, and cannot write to source tables or export raw records.
• A procurement assistant reads the vendor catalogue, drafts purchase requests and checks budget, and cannot approve a purchase order.

The role names the kind of work; the permissions name its verbs. An agent assigned analytics-readonly inherits a known set of capabilities and gets reasoned about as a category rather than a one-off.

Kubernetes is the largest RBAC deployment most engineers have touched, and its vocabulary carries over. A Role "always sets permissions within a particular namespace"; a ClusterRole is "a non-namespaced resource"; bindings attach one to a subject. The line worth memorising is the constraint: "Permissions are purely additive (there are no 'deny' rules)."

That is the design discipline in one clause. You cannot carve an exception out of a role already granted, so the only way to withhold something is to never put it in. Role design is subtractive work done before deployment, not corrective work after an incident.

Why RBAC Works as a Foundation

RBAC earns its place by making agent permissions standardised and reviewable, two properties that are hard to retrofit once permissions have sprawled.

Security teams approve a role once and reuse it across every agent of that type. Business teams can tell what an agent may do without reading a permission manifest. And a role called finance-reporting that quietly includes write access to ledgers is an obvious red flag precisely because the role gave it a name to violate.

There is a less obvious property, and NIST names it while discussing ABAC's weaknesses. Some organisations need "to know what access each individual has before the requests are made," which SP 800-162 calls "before the fact audit," and which exists "to demonstrate compliance to specific regulations or directives." RBAC answers that by construction: read the role, know the ceiling. This is what teams give up without noticing when they replace roles with computed decisions, and it is what an auditor will ask for.

Roles scale operationally too. A tenth analytics agent does not mean renegotiating permissions, and tightening access later means editing one role rather than chasing every agent granted something directly.

Where RBAC Runs Out of Room

RBAC describes what kind of thing an agent may do. It is much weaker at describing when, on what, and on whose behalf, and agents constantly need those finer distinctions because a single role spans situations that deserve different treatment.

NIST wrote the diagnosis down in January 2014, a decade before anyone deployed an agent. SP 800-162 observes that "RBAC does not easily support multi-factor decisions," offers recent HIPAA training as a prerequisite a role cannot express, and notes that role assignments "tend to be based upon more static organizational positions, presenting challenges in certain RBAC architectures where dynamic access control decisions are required." Then the consequence: trying anyway "would require the creation of numerous roles that are ad hoc and limited in membership, leading to what is often termed 'role explosion'."

Figure 1 — Two requests through the identical role, with opposite correct answers. That's the shape of every case RBAC alone can't handle.

A footnote in the same document reads like a specification of the problem. It gives three precision levels for one rule: "coarse: employees can read file X, fine: employees working on project A can read file X, and finer: employees working on project A during office hours can read file X." A role expresses the first. Only the first.

Three agent cases land on the wrong side of that line. A marketing agent may draft a campaign email but not send it externally without sign-off. A legal review agent may read most contracts but must be kept away from anything flagged privileged or under litigation hold. An analytics agent may query a dataset only if the person who invoked it can. Each depends on the record, the requester, or the moment.

Of the three, the legal case worries us most. Missing a privilege flag doesn't surface as an incident. It surfaces months later, in discovery, when the question is why a system that could read everything was never told the one thing that mattered.

Handle these with RBAC alone and the response is always the same: invent a narrower role. hr-assistant-own-records. hr-assistant-direct-reports. Do that enough times and the catalogue stops being something anyone can hold in their head, which was the entire reason RBAC was worth adopting.

RBAC, ABAC and ReBAC, and What Each Costs

The instinct after the section above is to replace roles with attributes. The two credible alternatives answer different questions, and both cost more to operate than a role. RBAC and ABAC are aact:authorization-model/role-based and per-action-policy in the Agent Access Control Taxonomy.

Table 1 — Three models, three different questions. Rows two and three are not upgrades to row one.

ABAC is the one most agent platforms drift toward, and NIST's own guide is the best argument for restraint. It says ABAC "is not the right solution for every access control problem but can prove viable for environments where subjects and objects carry a rich set of attributes," and it names a cost nobody budgets for: as authorisation moves "from the traditional method of provisioning an account and populating an ACL to an automated decision process, it will be more difficult for system users to understand and remedy access denials." For an agent that means a tool call failing for a reason nobody can explain, which is a support load rather than a security win.

AWS states the trade-off from the operator's side. Its IAM documentation names the RBAC disadvantage exactly, that "when you or your users add new resources to your environment, you have to update the policies to allow access to those resources," and sells ABAC on the grounds that it "requires fewer policies" and that "permissions scale with innovation." Both halves are true. The bill is the tagging discipline underneath.

ReBAC is the model fewest teams have evaluated and the one that fits several agent cases best, because "may query a dataset only if the invoking user can" is a relationship question. Google's Zanzibar paper (USENIX ATC '19) showed the approach holds at scale: it "scales to trillions of access control lists and millions of authorization requests per second" with "95th-percentile latency of less than 10 milliseconds and availability of greater than 99.999% over 3 years of production use." OpenFGA, whose syntax "closely follows the original syntax in the Zanzibar Paper," reduces the model to tuples of a user, a relation and an object: user:anne, editor, repo:auth0/express_jwt.

We think the honest answer for most teams is roles plus one narrow relationship check rather than a migration. Keep the role as the ceiling and add the single relationship question the domain turns on, usually whether the invoking user could reach the object themselves.

Designing Roles That Don't Explode

The discipline that keeps a catalogue useful is refusing to let it grow past what one person can read in one sitting.

Keep roles verb-scoped, not job-title-scoped. "Can read leave balances" is a role decision. "Is an HR agent" is not, because it invites every future HR-adjacent capability under one label. Separate roles for separate duties, the way procurement separates drafting a requisition from approving one, matters as much for an agent as for the person it is modelled on.

Build a small hierarchy where it helps: a base read-only role that several specific roles extend, rather than five that each redeclare the same read permissions. Kubernetes supports this through aggregated ClusterRoles, and the feature exists because flat catalogues duplicate rules until nobody can tell which copy is authoritative.

Treat every new role request as a design decision, not an inventory addition. If nobody can say in one sentence what makes it different from an existing role, it probably shouldn't exist. And the question at review time is never what to take away later. It is what we are about to hand over permanently.

What a Role Was Never Going to Decide

Requests that depend on the record, the requester or the moment aren't a failure of role design. They were never role-shaped, and the honest move is routing them elsewhere.

NIST SP 800-207, the zero trust architecture guide published August 2020, describes where they go. Its operative definition turns on "accurate, least privilege per-request access decisions," and two of its seven tenets are the relevant ones: access "is granted on a per-session basis," and access "is determined by dynamic policy, including the observable state of client identity, application/service, and the requesting asset," which "may include other behavioral and environmental attributes." A decision point and its matching enforcement component are the architectural home for everything a role cannot say.

For agents there is a second subject, and the standards already have vocabulary for it. RFC 8693's act claim exists to "express that delegation has occurred and identify the acting party to whom authority has been delegated," and may_act "makes a statement that one party is authorized to become the actor and act on behalf of another party." Read that as a design requirement. A role bounds the agent; the acting user's own access bounds the request; the effective permission is the intersection, aact:authorization-model/intersection-of-agent-and-user, and it is smaller than either.

OWASP's Agent Control Standard, published 1 September 2026, makes the same point from the operations side, requiring agents to be "inspectable, traceable and instrumentable" because "enterprises cannot rely on black-box agents operating across cloud, SaaS, on-premises and endpoint environments." A role is the inspectable part and neither of the other two.

Figure 2 — Three gates. RBAC is the first one, and on its own it is the only one most deployments have.

Catalogue Rot, and Its Symptoms

Role explosion does not announce itself. It shows up as operational symptoms that are easy to read once you know they are the same disease.

Table 2 — Six symptoms of a catalogue that has been asked to do the wrong job.

The fifth row is the agent-specific one, and the one we would instrument first, because it is silent by construction. Nothing fails. The agent holds a role permitting forty tools, the user it acts for is entitled to six, and the other thirty-four work fine until someone asks why.

In Practice

None of this requires a rewrite. It requires deciding which decisions belong in a role and resisting the pull to encode everything as a new one. A permission that is stable and tied to the agent's purpose belongs in the role. A permission that depends on the request, which record, which requester, which threshold, does not belong in a role at all, however tempting a narrower role looks in the moment.

Written out, an agent's role has two halves, and only the first is RBAC.

role: analytics-readonly
tools:
  - warehouse.query          # SELECT only
  - dashboard.create
  - dashboard.share
denied_by_omission:
  - warehouse.write          # never granted: additive models cannot revoke
  - export.raw_records

# Not expressible as a role. Evaluated per call, against the acting user.
per_request_checks:
  - acting_user_can_read: "${query.tables}"
  - row_filter: "region == acting_user.region"
  - max_rows: 50000

The second block is the one a role catalogue keeps trying to swallow. Keep it out. Every entry moved up into tools becomes a permission you cannot take back without editing the role for every agent sharing it.

Agentic Fabriq sits on the RBAC half of that split, deliberately. It runs default-deny across organisation, team and member with scope sets and per-user overrides, and an agent's effective tool list is the intersection of the user's scopes and the agent's, computed before the call. Every request carries two identities, the agent and the acting user, into the audit record. What it does not do is evaluate record-level rules for you. That check is yours to write, in the layer the second block describes.

Frequently Asked Questions

Is RBAC enough for AI agents? For bounding what kind of thing an agent is, yes. For deciding a specific request, no. NIST SP 800-162 says RBAC "does not easily support multi-factor decisions" and that trying anyway produces role explosion, and that was written in 2014 about human users.

What is role explosion? NIST's term for what happens when situational decisions are forced into roles: "the creation of numerous roles that are ad hoc and limited in membership." The tell is a catalogue where several roles differ by one permission and nobody remembers why.

Should we use ABAC instead of RBAC for agents? Not as a replacement. NIST's own guide says the cost of ABAC "may exceed its benefits in the long term" and that it suits environments where "subjects and objects carry a rich set of attributes." It also warns that before-the-fact audit gets hard. We think roles plus one narrow per-request check beats a migration for most teams.

What is ReBAC and when is it the right answer? Relationship-based access control, in the shape Google's Zanzibar paper described and OpenFGA implements: tuples of a user, a relation and an object. It is the right answer when your real rule is a relationship, and "the invoking user must be able to read this record themselves" is exactly that.

Can a role stop an agent acting outside a user's own access? Not on its own, because the role is attached to the agent. The acting user's entitlement has to be evaluated on the same call and the permission taken as the intersection. RFC 8693's act claim is the standards-track way to carry both parties.

Do agents need their own roles, or can they reuse human ones? Usually their own, narrower ones. Human roles were sized for a person who exercises a fraction of them, with judgment and a manager. An agent in the same role will exercise all of it, quickly.

Why can't we just add a deny rule? Some systems have them; the largest RBAC deployment most teams run does not. Kubernetes states that "permissions are purely additive (there are no 'deny' rules)," so the only reliable way to withhold a capability is never to grant it.

Roles and Boundaries

RBAC is a strong foundation and not the whole authorization strategy. Roles give an agent a recognisable identity and a reviewable ceiling, with three decades of tooling and audit practice behind them. On their own they don't capture what makes a single action safe in a specific moment, and they were never going to.

The answer isn't a bigger catalogue, and it usually isn't a migration either. It is a smaller catalogue that stays legible, plus the two checks a role structurally cannot make: whether the acting user holds the permission independently, and whether the named record is one they could reach themselves.

Sources

All URLs read 2026-09-29.

• Role Based Access Control, NIST Computer Security Resource Center — the 1992 Ferraiolo and Kuhn paper, ANSI/INCITS 359-2004 and its 2012 revision, and the RTI International estimate of $1.1 billion saved.
• NIST SP 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations — January 2014; section 2.1 on multi-factor decisions and role explosion, section 3.1.2.1 on ABAC's development and maintenance cost, section 3.1.2.3 on before-the-fact audit, section 3.2.1.5 on explaining denials, and the coarse/fine/finer footnote.
• NIST SP 800-207: Zero Trust Architecture — August 2020; the definition built on "least privilege per-request access decisions", tenet 3 on per-session access, tenet 4 on dynamic policy and behavioural attributes, and the decision-point architecture.
• Using RBAC Authorization, Kubernetes documentation — Role versus ClusterRole, the four API objects, aggregated ClusterRoles, and the statement that permissions are purely additive with no deny rules.
• Define permissions based on attributes with ABAC authorization, AWS IAM — the stated RBAC disadvantage when new resources appear, the claims that ABAC requires fewer policies and scales with innovation, and session tags from a SAML or OIDC provider.
• Zanzibar: Google's Consistent, Global Authorization System — USENIX ATC '19; trillions of ACLs, millions of authorization requests per second, sub-10ms 95th-percentile latency and over 99.999% availability across three years.
• OpenFGA concepts — the user, relation and object tuple model, conditions, usersets, and the acknowledged debt to the Zanzibar paper.
• RFC 8693: OAuth 2.0 Token Exchange — January 2020; the act claim for expressing delegation and identifying the acting party, and may_act for gating who may act for whom.
• Agent Control Standard, OWASP GenAI Security Project — 1 September 2026; agents as inspectable, traceable and instrumentable, and the argument against black-box agents in enterprise environments.
• OWASP Top 10 for Agentic Applications 2026 — published 9 December 2025; the current category list for agentic application risk, including identity and privilege abuse.
• MCP specification 2025-06-18: Authorization — how an agent-facing server is expected to validate what a token is for, which is the layer beneath any role decision.
• Agent Access Control Taxonomy — the authorization model dimension, and the question it asks: how is each action the agent attempts decided.
• Agent access control taxonomy, authorization-model.yaml — aact:authorization-model/role-based, per-action-policy, and intersection-of-agent-and-user with its note that an intersection "prevents an agent from becoming a privilege-escalation path for a low-privilege user, and vice versa".