HiveKey
Glossary Access control

RBAC (role-based access control)

Govern agents by job function — bundle capabilities into roles and assign them, instead of per-agent keys.

Role-based access control (RBAC) grants permissions by role rather than to each actor individually. Applied to AI agents, it’s how governance scales past a handful of agents: instead of configuring capabilities on every agent, you define named roles — Support · L2, Billing, Ops · deploy — and assign them.

RBAC has three parts. Capabilities are atomic actions (mail_send, payments_pay). Roles bundle capabilities into a job. Assignments map agents to roles. An agent’s effective permissions are the union of its roles; nothing is configured on the agent itself.

The payoff is a single source of truth. “Who can move money?” becomes one question with one answer — anyone wearing Billing — instead of an inspection of every agent. And changing a role updates every agent that wears it atomically, with no per-agent drift or hunting.

Agent RBAC adds three things human RBAC doesn’t need: invisibility (ungranted tools are hidden, not just denied, since a visible-but-denied tool is an attack surface for prompt injection); guards bound to roles (a role says “can refund up to $1,000, then require approval,” because agents won’t apply judgment themselves); and least privilege as the literal default (new agents start at zero). It’s the model that let companies manage thousands of employees safely — now applied to thousands of agents.

Put every agent your company runs under one policy.

Watch HiveKey scope, guard, and block a live action on your own agents — 30 minutes, no slides, no commitment.