What is RBAC for AI agents?
RBAC for AI agents is role-based access control applied to an agent platform. It governs which people may use which agents, based on their role. It is distinct from the agent's tool permissions: RBAC controls who can talk to an agent, while tool permissions control what that agent may do.
Two axes, not one
Section titled “Two axes, not one”A complete governance model needs both:
- Identity axis (RBAC). Map users and groups to roles. The finance group can use the finance agent; the support group cannot even see it.
- Capability axis (tool permissions). Allow-list the tools each agent may call. The finance agent may read accounting data but not write it.
Confusing the two is a common mistake. Letting the right people use an agent that can do too much is just as dangerous as locking down an agent that the wrong people can reach.
Why shared logins break it
Section titled “Why shared logins break it”If everyone shares one login or one gateway token, the system cannot tell who is calling. That breaks RBAC at the root:
- No per-user access control: access is all-or-nothing.
- No attribution: the audit trail cannot name a user.
RBAC requires that each person has their own identity, so both access and accountability tie back to a real user.
Basic vs. granular RBAC
Section titled “Basic vs. granular RBAC”- Basic RBAC distinguishes a small set of roles, such as admin and member, plus groups for visibility.
- Granular RBAC adds custom roles, per-resource permissions (who may view the audit log, who may manage providers), and enterprise identity via SSO/SAML.
Most teams start with basic RBAC and grow into granular as the deployment matures.
In Pinchy
Section titled “In Pinchy”Pinchy provides admin and member roles, plus groups that scope which users can see and use which agents, separately from each agent's tool allow-list. Granular RBAC (custom roles, SSO/SAML) is on the roadmap.