# Securing Your AI Agents: RBAC in Solace Agent Mesh Enterprise **URL:** \ **Category:** Solace Agent Mesh\ **Created:** [April 7, 2026, 4:00pm UTC](https://community.solace.com/t/securing-your-ai-agents-rbac-in-solace-agent-mesh-enterprise/4802 "2026-04-07T16:00:50Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![rey](https://yyz1.discourse-cdn.com/solace/user_avatar/community.solace.com/rey/32/2192_2.png) [@rey](https://community.solace.com/u/rey)\ **Post date:** [April 7, 2026, 4:00pm UTC](https://community.solace.com/t/securing-your-ai-agents-rbac-in-solace-agent-mesh-enterprise/4802/1 "2026-04-07T16:00:50Z")
As AI agent systems grow more powerful, the question of “who can access what” becomes critically important. Role Based Access Control (RBAC) is the ideal solution for this, and Solace Agent Mesh Enterprise has it baked right in. Let’s dig a bit deeper into how it works and how to implement. ## The Three-Tier Authorization Model Solace Agent Mesh Enterprise uses a clean three-tier model that separates identity (Users), roles, and permissions (Scopes): | Concept | Description | Example | | --- | --- | --- | | **Users** | Identities in the system, typically email addresses | `rey.riel@solace.com` | | **Roles** | Named collections of permissions assigned to users | `data_analyst`, `enterprise_admin` | | **Scopes** | The actual permissions granting access to features/resources | `tool:data:*`, `agent:report_agent:delegate` | ## How Authorization Works ![rbac_sam_diagram](https://canada1.discourse-cdn.com/solace/original/2X/7/7d6be2d6940a04adbe5cbc2bcac7e7a245baf822.jpeg) Users, Roles and Scopes are connected together to authorize or deny access to tools and agents. After a user is authorized, when attempting to execute an action, the list of roles the user is given in the system are identified, and based on those roles a list of scopes for the user is detailed. These scopes tell the agent mesh whether to grant or deny the users request. * * * ## Authorization Types Agent Mesh supports four authorization modes. This is specified in your `enterprise_config` yaml file as the `type` parameter in the `authorization_service` section: | Type | Description | When to Use | | --- | --- | --- | | `deny_all` | Denies all access (default when unconfigured) | When you haven’t set up auth yet | | `default_rbac` | Full RBAC using config files | **Recommended for production** | | `custom` | External authorization service integration | Advanced enterprise setups | | `none` | Disables authorization entirely | **Development only — never in production** | * * * ## Understanding Scopes Scopes are the building blocks of RBAC in Agent Mesh. There’s three different types of scopes you can define: tool scopes, agent scopes and monitoring scopes. ### Tool Scopes A tool scope (like the name suggests) provides access to a specific tool. They have a standard pattern of `tool::`. Tool scopes are defined in two places: the tool and the user. You indicate a tool needs a particular scope with the `required_scopes` property of the python tool definition or in the tool information in your agents yaml file. A perfect example of this can be seen by looking at the [built in artifact tools](https://github.com/SolaceLabs/solace-agent-mesh/blob/682bacedf395f9905357f347ff44cb1b13d24f21/src/solace_agent_mesh/agent/tools/builtin_artifact_tools.py#L1697). ```auto required_scopes=["tool:artifact:list"] ``` The built in artifacts management tools have the following scopes, which are a great example of defining scopes for a particular category: ```auto tool:artifact:list # List artifacts tool:artifact:load # View/download artifacts tool:artifact:create # Create artifacts tool:artifact:append # Append to artifacts tool:artifact:delete # Delete artifacts tool:artifact:* # All artifact permissions ``` But you can define your tool categories in whatever way fits your tools. Here’s an example of separating tools by `basic`, `data` and `advanced`: ```auto tool:basic:read # View basic tools tool:data:read # Tools that view data tool:advanced:read # View advanced tools ``` Once you’ve defined what scopes a tool requires, you then define for a particular role what scopes that role has access to. We’ll show more examples later, but each role has a `scopes` list that you use to provide the list of scopes they are given: ```auto roles: agent_operator: description: "Can access all non-admin agents" scopes: - "tool:artifact:list" - "tool:basic:*" ``` As you can see above, wildcards are supported with the asterisk character (`*`). In the scope defined above, the `agent_operator` role has the ability to list artifacts, and access all tools that are defined in the `basic` category. ### Agent Delegation Scopes An agent scope provides access to a specific agent, and follows the pattern `agent::delegate`. The only part that is modified in this scope is the name of the agent, and these scopes aren’t created like tools are with the `required_scopes` parameter. With any agent defined in Agent Mesh there is an implicit scope created, so you only need to define for roles what agents they have access to. Here’s a good example of agent scopes defined for a role: ```auto agent:report_agent:delegate # Access to a specific agent agent:customer_*:delegate # Access to all customer-prefixed agents agent:*:delegate # Access to ALL agents ``` ### Monitoring Scopes Monitoring scopes, like agent scopes, are implicitly created based on the namespace for the system messages being sent, and are defined for roles with the pattern of `monitor/namespace/:a2a_messages:subscribe`. Here’s an example of two different scopes, for monitoring: ```auto monitor/namespace/production:a2a_messages:subscribe monitor/namespace/*:a2a_messages:subscribe ``` One provides access to only production system messages, while the other provides access to all system messages. * * * ## Setting Up RBAC All components for RBAC live in 4 places. ### 1. Tool definitions As indicated above, each tool created has a `required_scopes` parameter in their python definition or in the tool information in your agents yaml file. This is where you define which scopes are needed for that specific tool. It’s important to know that an empty `required_scopes` array means that no scopes are required for that tool, so anyone can access it. Here’s an example where you can limit the use of the built in mermaid image generator tool: ```auto tools: - tool_type: "builtin" tool_name: "mermaid_diagram_generator" required_scopes: ["tool:mermaid_diagram_generator:use"] ``` ### 2. `role-to-scope-definitions.yaml` — Define Your Roles `role-to-scope-definitions.yaml` is the name of the file we’re giving here for an example, but it can be anything. You just need to make sure you provide the proper name for that file in your enterprise config. This is your role definition file, where you create all the roles for your agent mesh and define what scopes those roles have access to. This is also where you would be able to define wildcards, giving users access to multiple tools or even multiple agents, with just one line. Here’s a good example that provides 3 different roles and what they have access to. ```yaml roles: enterprise_admin: description: "Full access for enterprise administrators" scopes: - "*" standard_user: description: "Standard user with basic access" scopes: - "tool:artifact:load" - "tool:basic:read" - "tool:basic:search" data_analyst: description: "Data analysis and visualization specialist" scopes: - "tool:data:*" - "tool:artifact:load" - "tool:artifact:create" - "tool:basic:read" - "tool:basic:search" - "monitor/namespace/*:a2a_messages:subscribe" ``` ### Role Inheritance Roles can inherit from other roles in order to reduce duplication. In the above example, the `data_analyst` role has access to the same tools as the `standard_user` role, plus more. We can simplify this using inheritance: ```yaml roles: enterprise_admin: description: "Full access for enterprise administrators" scopes: - "*" standard_user: description: "Standard user with basic access" scopes: - "tool:artifact:load" - "tool:basic:read" - "tool:basic:search" data_analyst: description: "Data analysis and visualization specialist" inherits: - "standard_user" scopes: - "tool:data:*" - "tool:artifact:create" - "monitor/namespace/*:a2a_messages:subscribe" ``` * * * ### 3. `user-to-role-assignments.yaml` — Assign Users to Roles Now that we have our scopes and users defined, it’s time to assign these roles to our users. This involves a new yaml file, where each user is defined by their identity (typically their email address) and the roles they are given. ```yaml users: admin@example.com: roles: ["enterprise_admin"] description: "Enterprise Administrator Account" data.analyst@example.com: roles: ["data_analyst"] description: "Senior Data Analyst" user1@example.com: roles: ["standard_user"] description: "Standard Enterprise User" ``` > 📝 **Note:** Email identities are normalized to lowercase before matching. Users can have multiple roles — they receive the combined permissions of all assigned roles. * * * ### 4. `enterprise_config.yaml` — Wire It Together With our tools providing their required scopes and our two files created above defining our roles and users, we need to let Agent Mesh know exactly where these definitions are. ```yaml authorization_service: type: "default_rbac" role_to_scope_definitions_path: "config/auth/role-to-scope-definitions.yaml" user_to_role_assignments_path: "config/auth/user-to-role-assignments.yaml" ``` With these lines SAM can take control and ensure users only have the access and information they’re allowed to. * * * ## Best Practices So what makes for a good implementation of Role-Base Access Control? Anyone can create some files with some lines of code, but that doesn’t always lead to a secure implementation. But if you follow these tips and tricks when implementing, you can be sure your data will be properly secured. 1. **🔐 Principle of Least Privilege** — Assign only the minimum permissions necessary. Start restrictive and open up as needed. 2. **🚫 Never use `type: none` in production** — This disables all authorization. 3. **👥 Use role inheritance** — Reduces duplication and makes role management maintainable. 4. **🔍 Minimize wildcard usage** — Reserve `*` for admin roles only. Use specific scopes everywhere else. 5. **🔑 Protect config files** — Restrict read/write access to administrators only. 6. **🔄 Regular audits** — Review role assignments and permissions periodically. 7. **🔒 Use environment variables** for sensitive credentials (e.g., MS Graph secrets). 8. **💾 Backup RBAC config files** regularly. * * * ## Administrative RBAC Beyond the runtime‑level RBAC configuration that governs the users ability to access agents and tools, Agent Mesh also exposes specific scopes dedicated to administering the mesh itself. These administrative scopes control access to operations such as creating and modifying connectors or leveraging the agent builder. ```yaml roles: sam_administrator: description: "User with access to modify the agent mesh" scopes: - "sam:connectors:create" # Create new connectors in the Connectors section - "sam:connectors:read" # View connector configurations and list available connectors - "sam:connectors:update" # Modify connector configurations and credentials - "sam:connectors:delete" # Remove connectors from the system - "sam:agent_builder:create" # Create new agents through Agent Builder interface - "sam:agent_builder:update" # Edit existing agent configurations - "sam:agent_builder:delete" # Delete agents (must undeploy first) - "sam:deployments:create" # Deploy agents to make them available in Chat - "sam:deployments:read". # View deployment status and history ``` * * * \*Want to learn more? Check out the [Solace Agent Mesh RBAC Setup Guide](https://solacelabs.github.io/solace-agent-mesh/docs/documentation/enterprise/rbac-setup-guide), which includes important examples of setting RBAC up with Docker and Helm, as well as integration with Microsoft Graph