RBAC for AI agents: roles, not keys

When you had three agents, configuring each one by hand was fine. At thirty, it’s a mess of copied configs that have quietly diverged. At three hundred, nobody can answer “which agents can move money?” without a spreadsheet that’s already out of date. Per-agent permissions don’t scale — for the same reason per-user permissions never did.

The answer is the one we already trust for people: role-based access control. Govern by job function, not by handing each agent its own key.

What goes wrong with per-agent keys

The default agent setup gives each agent its own credential and its own ad-hoc set of powers. Three failures follow predictably:

• Drift. Agent A and Agent B were “the same” six months ago. Then someone gave A one extra tool for a one-off, and never removed it. Now they’re snowflakes, and no one’s sure why.
• No single answer. “Who can call payments_pay?” requires inspecting every agent individually. There is no source of truth.
• Painful change. Tightening a policy means editing every agent that has it. You’ll miss some.

These are the exact problems RBAC was invented to solve for human identity. Agents are just a new kind of identity with the same need.

The RBAC model, applied to agents

RBAC has three moving parts:

1. Capabilities — the atomic actions an agent can take: mail_send, crm_read, payments_pay, deploy. Defined once, centrally.
2. Roles — named bundles of capabilities that map to a job: Support · L2, Billing, Ops · deploy, Read-only.
3. Assignments — which agents wear which role.

An agent’s effective permissions are simply the union of the roles assigned to it. Nothing is configured on the agent itself. The agent is “dumb” about its own powers — it asks the control plane, and the plane answers from the role.

Role	mail_send	crm_read	crm_delete	payments_pay	deploy
Support · L2	✓	✓	—	—	—
Billing	✓	✓	—	✓	—
Ops · deploy	—	✓	—	—	✓
Read-only	—	✓	—	—	—

Now “who can move money?” is one question with one answer: anyone wearing Billing. And changing the Billing role updates every agent that wears it, atomically, with no per-agent hunting.

Roles for agents need three things humans don’t

Agent RBAC isn’t a copy-paste of human RBAC. Three additions matter.

Invisibility, not just denial. For humans, a denied button is fine — they sigh and move on. For agents, a visible-but-denied tool is an attack surface: a prompt injection can keep trying it. So ungranted capabilities should be filtered out of the agent’s tool manifest entirely. Denied becomes nonexistent.

Roles bind guards, not just grants. A human role says “can issue refunds.” An agent role should say “can issue refunds up to $1,000; above that, require approval.” The constraints travel with the role, because agents won’t apply judgment on their own.

Least privilege as the literal default. A new agent should start with zero capabilities and earn each one deliberately. With humans you can lean on culture and review. With agents, the empty default is the only safe default.

Migrating from keys to roles

You don’t need a big-bang rewrite. The path is incremental:

1. Catalog the capabilities your agents actually call. (You’ll find a long tail nobody remembers granting.)
2. Cluster by job. Group agents that do the same work; their union of capabilities is your first draft of a role.
3. Define roles centrally and assign them — agents now inherit from the role instead of holding their own key.
4. Pull the raw keys. Once an agent gets its powers through a role via the control plane, its standalone credential becomes dead weight. Revoke it.
5. Review roles, not agents. Quarterly access review is now five roles to read, not three hundred agents.

The mental shift is small but total: stop asking “what can this agent do?” and start asking “what job does this agent have?” The role answers the rest.

Why this is how agent governance scales

Roles give you the three things per-agent keys can’t: a single source of truth for who can do what, a single place to make a change that lands everywhere, and an access review that a human can actually complete. It’s the model that let companies manage thousands of employees safely. It’s how you’ll manage thousands of agents — governed like the workforce they’ve quietly become.