Once more than a couple of people use your agents, “everyone can do everything” stops being fine. Here’s how I set up role-based access control in Solace Agent Mesh, plus the two gotchas that cost me an afternoon.
Roles are lists of scopes
A scope reads <category>:<resource>:<verb>. Here’s a support operator role that can chat with agents, run workflows and review activity, and nothing else:
kind: rbacRole
name: Support Operator
spec:
scopes:
- agent:*:invoke
- workflow:*:invoke
- activity:*:read
- project:_:share
- prompt:_:share
users:
- { type: email, value: hannah.cole@example.com }
Gotcha number one: agent:*:invoke does not cover workflows. If a role should run workflows, it needs workflow:*:invoke too.
Map identity provider groups instead of listing people
Listing emails works for a demo. In production, map a group claim from your OIDC provider to a role:
kind: rbacClaimMapping
name: customer-service-desk
spec:
oidcProvider: azure
claimValue: nw-customer-service
roleNames:
- Support Operator
Machines get their own identity
Webhooks, MCP clients and other automated callers run as system users through runAs, each with their own role. An integration should never borrow a human’s permissions.
Gotcha number two: turning enforcement on
Authorization is off by default, so everyone is effectively an admin. When you enable it with AUTHORIZATION_TYPE=default_rbac, also set TRUST_MANAGER_ENABLED=true. Without the trust manager, enforcement is silently skipped and every caller is allowed. On Kubernetes, sam.authorization.enabled: true in the Helm values is the switch.
Docs:
Download the Solace Agent Mesh desktop app to model your roles locally before you roll them out.
How are you splitting roles today: by team, by agent, or by environment? Share your layout in the replies.