ABAC vs RBAC for AI Agent Query Permissions

An internal agent, given access to a company's docs tooling, touched files belonging to eight different people, on behalf of four different requesters, in a single session lasting under a minute. No human role-holder produces that pattern. That single fact exposes the central problem with running AI agents on role-based access control (RBAC): the model assumes a stable subject whose job predicts what data it needs, and agents violate that assumption completely.

RBAC's Foundational Assumption

RBAC was built around a simple design: assign permissions to a role, assign the role to a subject, and let the role do the work of deciding access at the moment someone is provisioned into the system. The decision gets made once, in advance, before anyone asks for anything. Kiteworks framed this distinction precisely in March 2026: RBAC makes the access decision at provisioning time, while ABAC (attribute-based access control) makes it at request time, with full visibility into who is asking, what they're asking for, why, and under what circumstances.

For a human clinician, a stable role is a reasonable stand-in for authorized access. Job functions don't change by the hour. A nurse's permissions today look like a nurse's permissions next month, and professional judgment fills in the gaps RBAC leaves open, governing what the person actually touches within the scope the role allows.

AI agents carry none of that stability. They get deployed for specific tasks, operate across data scopes that shift from one invocation to the next, run at machine velocity, and can execute dozens of parallel workflow instances at once. That eight-files, four-requesters, under-a-minute session documented by Zuplo in June 2026 is what agent traffic actually looks like, and no role was ever built to describe it.

An agent needs the specific thing stated, and a role cannot say it. "The agent may call the database" is true. "The agent has the editor role" is also true. Neither one tells you whether this particular call, on this particular record, for this particular task, should be allowed. Kiteworks lays out the concrete version: a "clinical documentation agent" role that grants PHI (protected health information) access cannot express that this one instance is authorized for three specific encounter records, for one patient, for one documentation task, delegated by one clinician, expiring at the end of the session, which makes it a policy evaluated against context rather than a role, and context-evaluated policy is what ABAC computes.

Role explosion and coarse grants: what RBAC does when pushed past its design limits

Faced with context it wasn't built to express, most teams don't replace RBAC. They multiply it. A role called "analyst" becomes "analyst-eu," then "analyst-eu-readonly," then "analyst-eu-readonly-prod," with each new variant an attempt to approximate a condition the original model has no native way to state. This pattern, known as role explosion, is the empirical record of RBAC meeting complexity it can't absorb.

TrueFoundry made a useful diagnostic point in September 2026: role explosion is usually a scoping bug rather than evidence the model itself has failed, and that reframe holds as long as the access binding belongs to a single, stable resource. Once both the subject and the resource scope start moving, as they do with agents, no amount of role refinement closes the gap. The fix that works for a messy but static permission structure doesn't work for a structure that changes every session.

The operational cost of role explosion is well documented. MiniOrange listed the consequences in April 2026: more roles to manage and maintain, longer access reviews and audits, more administrative overhead, a greater risk of misconfigured permissions, and growing difficulty figuring out who actually has access to what. Each of those costs compounds as the role count grows, and the role count grows precisely because the underlying problem was never solved, only patched.

For agents, the role-explosion path doesn't even arrive at a working solution eventually. Carried to its logical end, it would require a distinct role for every combination of user, resource, task, and session, making it a policy evaluated at runtime, built out of roles instead of attributes, doing the job badly that ABAC is designed to do directly.

The second failure runs alongside the first: grants that stay too coarse no matter how the roles get sliced. Because agents operate fast and often run several workflows in parallel, that aggregate over-access is the default state of the deployment. Kiteworks treats this as a compliance exposure rather than a hypothetical risk: for agents operating at this velocity, the gap between role-level access and task-level authorization is systemic, and no amount of role redesign closes it.

What ABAC evaluates, and why runtime attribute evaluation fits agents

ABAC doesn't hand out a category of access the way RBAC does. It evaluates a policy against the live state of four attribute dimensions at the exact moment a request comes in, which is the computation agent authorization actually calls for. Those four categories, as TrueFoundry and MiniOrange describe them, are subject attributes (department, clearance, employment status, manager, agent owner), resource attributes (classification, owning team, data region, sensitivity tag), action attributes (read, write, delete, invoke, approve), and environment attributes (time of day, source IP, device posture, request risk score).

A single well-written ABAC rule can express something RBAC has no vocabulary for at all: "the doctor assigned to this patient." The policy simply checks whether subject.assigned_patient equals resource.patient_id at the moment of the request. Applied to agents, that same mechanism can encode that Agent A is authorized by User B to perform Task C on Resource D within Session E, and the system re-evaluates that authorization on every individual data request inside the workflow, not only once at session start.

Kiteworks names ABAC as the component that makes a delegation chain actually enforceable: knowing that a clinician delegated a task to an agent means nothing if the access layer can't evaluate that delegation at the moment each data request arrives. The core problem with provisioning-time RBAC is that the access decision gets made long before the agent's real request shows up, with its full context: who delegated it, which specific resource it touches, whether the delegating user is still authorized. A semantic layer like the one Peaka builds enforces permissions at query time under the real user's identity, rather than assuming broad access from a service account, so each data request gets checked against the current state of the delegation and the specific task it's tied to.

The regulatory fit follows the same logic. HIPAA's minimum necessary principle, CMMC practice AC.2.006, and NIST 800-171 practice 3.1.2 all require access limited to what the specific authorized task needs, and that's a requirement a runtime-evaluated model can satisfy in a way a provisioning-time role assignment structurally cannot.

None of this comes free. TrueFoundry identifies the real trade: with RBAC, the question "who can read this data?" has a lookup answer, something you can pull off a table. With ABAC, you have to run the policy engine to find out, because the answer depends on conditions that only resolve at request time. Policies are code. They need review, testing, versioning, and some way to reason about how rules interact with each other, and the failure mode at scale is policy sprawl nobody fully understands anymore. ABAC also assumes something most organizations don't have by default: attributes that are trustworthy and consistently populated. A policy keyed off resource.data_region is only as reliable as the tagging discipline feeding it, and that discipline has to be built, not assumed.

Three compliance gaps RBAC structurally creates for AI agent deployments

An AI deployment governed only by RBAC cannot satisfy minimum-necessary-access requirements, no matter how carefully the roles are designed. Kiteworks identifies three specific gaps this creates.

Minimum necessary access can't be enforced at the operation level. A role grants a category of access rather than a verdict on whether this specific operation, on this specific record, falls within the authorized scope of this specific workflow. Delegation can't be represented. When a clinician hands a task to a documentation agent, the role the agent holds carries no record that the delegation happened, what it covers, or when it expires. Audit trails capture identity but not authorization context. Telling a regulator that the agent had the PHI Read role says nothing about whether that specific access fell inside the task it was actually authorized to perform.

The risk compounds once agents start writing or executing rather than only reading. Write and execute actions create integrity and side-effect exposure that read-only RBAC models were never built to anticipate. Approval gates for destructive or high-impact writes, things like production changes, external messages, deletions, or payments, function as a separate control layer that RBAC alone cannot substitute for, no matter how the roles are structured underneath it.

Why multi-agent chains break even a well-implemented ABAC policy

ABAC evaluates each access request on its own. It has no way to model the full chain of accesses that makes up a multi-agent workflow, and no way to express a constraint on what happens when individually authorized accesses get combined. That gap has a name: Tallam, writing in an arXiv paper published May 2026, formalizes it as "authorization propagation," a workflow-level property distinct from both prompt injection and the classical access-control failures RBAC and ABAC were built to address.

The paper identifies three sub-problems that classical models, ABAC included, don't fully cover. Transitive delegation: Agent A delegates to Agent B, which delegates to Agent C, and the authorization invariant has to hold across the entire chain, not just at each individual hop. Aggregation inference: a set of individually authorized accesses, each one harmless on its own, can combine to reveal information the originating principal was never cleared to see. Temporal validity: an authorization granted for a session-scoped task can get consumed by a sub-agent long after the session that granted it has already ended.

Preliminary implementation evidence cited in the paper shows these failures already occurring in a production enterprise AI platform through ordinary system behavior, not adversarial manipulation. The system did what it was told, and the authorization logic still broke down across the chain.

The paper's central claim is that identity governance has to be treated as infrastructure: evaluated continuously, enforced at every interaction boundary, and designed into the system before orchestration logic is allowed to scale past what anyone can reason about. The field is converging on partial answers. Tallam points to invocation-bound capability tokens, task-scoped authorization envelopes, dependency-graph policy enforcement, and execution-count revocation as emerging responses, though no complete architecture exists yet. ABAC remains necessary for evaluating any single request correctly. It is not sufficient once agents start delegating to other agents, and that distinction is what the production design has to account for.

The hybrid design that ships: RBAC as the ceiling, ABAC as the floor-level enforcer

The design that holds up in production doesn't choose between RBAC and ABAC. It layers them. RBAC sets the outer boundary of what a given agent type is ever permitted to touch, and ABAC enforces the specific authorization for each operation inside that boundary. Kiteworks puts it directly: RBAC sets the ceiling, and ABAC does the work at the floor.

In practice, that means RBAC still defines a coarse role, something like a "documentation agent" with a PHI-read ceiling, and ABAC narrows that ceiling down at every request by customer account, folder path, project ID, environment, document label, or session delegation. Neither layer is asked to do the other's job.

Zuplo's practical recommendation matches that same honesty about what's deployable today: the least-privilege control that actually ships right now is tool curation plus scoping, not full relationship-based checks. That means publishing a hand-picked subset of upstream tools per route and binding every token to the specific server it was minted for, so a token can't get replayed somewhere else. Per-resource relationship-based access control (ReBAC) checks at the gateway boundary are available as a deeper layer for teams ready to take them on, but they're not where most deployments start.

Scoped, short-lived tokens enforce least privilege at the credential level itself. Audience limits and narrow claims, things like read:docs, write:drafts, or execute:query, tied to specific resources mean a leaked or confused token can only reach what the current principal could already reach. That shrinks the blast radius on every single operation, not just at the start of a session.

ABAC's runtime attribute evaluation mirrors how data platforms built for agents need to operate generally: the decision happens at the moment of the request, not back at provisioning, and it can fold delegating-user identity, task context, and resource specificity into one evaluation. For a platform exposing data to agents, that means governance becomes part of the query layer itself, evaluated against live state rather than inherited from a static role assignment made weeks earlier.

Write and execute actions still carry a different risk profile than reads, and that difference needs its own control, not just a tighter policy. Approval gates for destructive or high-impact actions, production changes, external messages, deletes, payments, are the appropriate control for a risk class that RBAC and ABAC, even layered together, cannot fully contain on their own.