Securing Your AI Agents: RBAC in Solace Agent Mesh Enterprise

Solace Agent Mesh
1

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
rbac_sam_diagram1264×848 107 KB

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:<category>:<action>.

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.

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:

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:

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:

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:<agent_name>: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:

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/<namespace>:a2a_messages:subscribe. Here’s an example of two different scopes, for monitoring:

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:

      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.

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:

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.

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"

:memo: 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.

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. :locked_with_key: Principle of Least Privilege — Assign only the minimum permissions necessary. Start restrictive and open up as needed.
  2. :prohibited: Never use type: none in production — This disables all authorization.
  3. :busts_in_silhouette: Use role inheritance — Reduces duplication and makes role management maintainable.
  4. :magnifying_glass_tilted_left: Minimize wildcard usage — Reserve * for admin roles only. Use specific scopes everywhere else.
  5. :key: Protect config files — Restrict read/write access to administrators only.
  6. :counterclockwise_arrows_button: Regular audits — Review role assignments and permissions periodically.
  7. :locked: Use environment variables for sensitive credentials (e.g., MS Graph secrets).
  8. :floppy_disk: 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.

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, which includes important examples of setting RBAC up with Docker and Helm, as well as integration with Microsoft Graph