RBAC vs ABAC: Choosing an Access Control Model for AI Agents

What RBAC actually is

Role-based access control puts a named layer between people and permissions. You do not grant Priya the ability to read a secret group. You define a role called Secret Group Viewer containing that permission, and assign Priya to it.

Three pieces make up the role based access control model:

The value is indirection. When security decides viewers should no longer see secret values, they edit one role and every viewer changes at once. NIST formalized this model decades ago, which is why every cloud console has a roles page.

The weakness is also the indirection. Roles are static sets. If a permission should apply only from a corporate IP, or only to records in the requester’s own region, plain RBAC cannot express it. Teams respond by minting more roles: analyst-eu, analyst-eu-readonly, analyst-eu-readonly-prod. This is role explosion, the most cited reason people go looking at ABAC.

What ABAC actually is

Attribute based access control removes the named bundle. Instead of asking what role a subject holds, it evaluates a policy expression at request time over four categories of attribute:

A policy reads something like: allow read when subject.department == resource.owning_team and resource.classification != "restricted" and env.network == "corp". NIST SP 800-162 is the canonical write-up; in practice ABAC ships as a policy language such as XACML, Rego, or Cedar behind an authorization service.

ABAC is genuinely more expressive. One well-written rule can replace a hundred roles, and it handles relationships RBAC cannot state at all: “the doctor assigned to this patient.”

That expressiveness is bought with something. Policies are code: they need review, tests, versioning, and a way to reason about how rules interact. And the question an auditor asks first — who can read this data? — stops having a lookup answer. You have to enumerate every subject and evaluate the policy against each. Some engines ship reverse-query tooling for this reason; most deployments do not use it.

RBAC vs ABAC differences at a glance

One thing the table hides: ABAC has a prerequisite, trustworthy attributes. A policy keyed off resource.data_region is only as good as the tagging discipline that populates that field. Most organizations that try ABAC find they have an untagged-data problem before they have an authorization problem. And the two models are not exclusive — the common production shape is RBAC as the backbone with a few attribute conditions on top.

Where teams get this wrong

Treating role explosion as a reason to switch models. Role explosion is usually a scoping bug, not a model failure. If you have analyst-team-a, analyst-team-b, and analyst-team-c, you do not need attributes — you need one analyst role bound separately to each team’s resources. Most of the pain blamed on RBAC comes from granting tenant-wide when the binding belonged on a single resource.

Buying expressiveness you cannot audit. ABAC lets you write a rule your compliance team cannot read. That trade is sometimes worth it, never by accident. Before adopting a policy engine, ask who will answer the access-review questionnaire next quarter, and how.

Forgetting that grants combine. A subject can hold access directly and inherit it through a team, and removing one does not remove the other. It gets worse when a policy engine is layered on top, because two systems can then grant independently.

Permissioning the human and ignoring the agent. Every control on the human side is decorative if the agent they built runs on a shared service token with tenant-wide access.

Want to see scoped access in practice?

Spin up TrueFoundry and grant a role on a single resource instead of the whole tenant — it takes about two minutes.

Get started free

Why AI agents look like the case for ABAC

An AI agent is a non-human subject whose effective authority is not fixed. It might read a public repository in one turn and touch a customer record in the next. It acts for different people at different times. Its inputs can be adversarial — a poisoned issue body can steer it toward a tool it should not call. And unlike a human, it does not pause to wonder whether an action is wise.

Write that as a requirement and it reads exactly like an ABAC brief: allow this tool call when the acting user has upstream access to the target, the tool is not destructive, and the request did not originate from untrusted content. Three attributes, one rule. So why does almost nothing ship that way?

Because the attributes are not reliably available at decision time. “Did this request originate from untrusted content” is not a field, it is a research problem. “Does the acting user have upstream access” is knowable — but the cheapest correct way to know is to call the upstream system with that user’s own credentials and let it answer, rather than mirror its permission model into your policy engine and hope the copy stays fresh.

The auditability cost also lands hardest exactly where agents live. Agent permissions are what security review asks about most sharply, and “the policy evaluates to allow under these conditions” is a far worse answer than a table saying this agent holds MCP Server User on these three servers.

So: agents need narrower access than humans and more inspectable access than humans. ABAC delivers the first and undermines the second. Hence the shipping pattern — RBAC with tight resource scoping, plus a few contextual gates where context genuinely matters.

How this works in TrueFoundry

TrueFoundry implements RBAC with resource-scoped role bindings. It is not an ABAC policy engine, and it is worth being plain about that. The model answers one question: who can do what, and where?

• A subject is the identity receiving access: a user, team, virtual account, or agent.
• A resource is the thing being accessed: a model provider account, MCP server, agent, cluster, workspace, repository, or secret group.
• A role is a named set of allowed actions.

Assigning a role to a subject for a resource creates a role binding. Access is managed independently of the resource’s configuration, so you can change who has access without redeploying anything.

Grants are made from the resource itself — open its three-dot menu and select Access Control:

Then choose one or more subjects and a role. The drawer lists the actions each role includes, so you see what you are granting before you grant it:

Grant Access drawer showing the subject selector with the Manager and User roles available for a provider account

The roles offered depend on the resource type: Manager and User on a model provider account; MCP Server Manager, MCP Server User, and MCP Server Approver on an MCP server; Agent Manager and Agent Access on an agent. Clusters, workspaces, and secret groups each have their own admin, member, and viewer tiers.

Three scopes, not one

Roles operate at three scopes, and keeping them straight is most of the skill:

‍