Access control

Access to an agent passes two checks, one from each access-control model Exo uses. RBAC (role-based) asks whether the user holds the right permission (e.g. agents:read, agents:invoke) — a property of the user's role, regardless of which agent. ABAC (attribute-based) then decides from attributes of the specific request. Per-agent access lists are one such ABAC policy: they ask whether, for this agent, the user is on the list. Both must pass.

Open vs restricted

• Open: an agent with no access-list entries is visible to anyone with agents:read.
• Restricted: add the first principal and the agent becomes visible only to listed users, teams, and roles. Remove the last entry and it flips back to open.

Principals are user, team, or role. A user sees a restricted agent if they're granted directly, are a member of a granted team, hold a granted role, or hold agents:admin (which bypasses the list). Agents a user can't see return 404, not 403, so their existence doesn't leak.

Grant & revoke

Manage the list from the dashboard's Access tab. Each grant adds one principal; each revoke removes one. To reopen an agent, revoke its last entry. This requires agents:admin.

Permission matrix

The full RBAC catalogue — every key Exo's built-in handlers gate, mirroring model.SystemPermissions — against the two seeded roles. ✓ means the role holds that permission. Admin carries the entire catalogue (rebuilt from the system list on every release, so it never misses a new key); Member is the narrow read-plus-invoke seed. Tenant-authored roles mix and match any of these, and custom permissions add rows your own code gates on.

Visibility & permissions

Grant and revoke are admin-only; each records who granted access (granted_by) and when (granted_at). See Roles & permissions for the permission catalogue and how teams differ from IdP groups.