Skip to main content
Archestra uses a role-based access control (RBAC) system to manage user permissions across every resource in the platform. Permissions follow a resource:action format — for example, agent:create allows creating agents, mcpGateway:update allows modifying MCP gateway configuration, and llmProxy:read allows viewing LLM proxies. This model gives platform administrators precise control over what each user can see and do without granting blanket elevated access.

Predefined Roles

The following roles are built into Archestra and cannot be modified or deleted.

Admin

Full access to all resources including user management, roles, identity providers, and platform settings. The admin role has all permissions on every resource.

Editor

Full access to core resources — agents, MCP gateways, LLM proxies, knowledge bases, and organization settings — but cannot manage users, roles, or identity providers.

Member

Can create and manage their own agents, tools, and chat sessions, with read-only access to most platform-wide resources.

Editor Permissions

Member Permissions

Custom Roles

Users with the ac:create permission can create custom roles by selecting specific permission combinations. Custom roles enable fine-grained access control tailored to your organization’s needs. You can only grant permissions that you already possess — this prevents privilege escalation.
Use clear, descriptive names for custom roles that indicate their purpose, such as Agent-Manager, Read-Only-Analyst, or Tool-Developer.

Available Permissions

Scoped Resources

Some resources use a two-step authorization model. RBAC grants a base action (read, create, update, delete), and then runtime scope rules further restrict which records a user can actually see or modify. The most common scopes are:
  • personal — owned by one user
  • team — shared with one or more teams
  • org — shared across the entire organization

Agents, MCP Gateways, and LLM Proxies

These three resources share the same scope model:
agent:delete alone does not allow deleting every agent — it only applies to agents within the user’s permitted scope. Use agent:admin to bypass scope restrictions entirely.

Visibility-Scoped Credentials

llmProviderApiKey and llmVirtualKey support personal, team, and org scope but use different elevated permissions. Team records require membership in the selected team; organization-wide records require the resource-specific admin permission such as llmProviderApiKey:admin. These resources do not use :team-admin.

Chat Access

Chat access requires both chat:read and agent:read because chat is agent-backed — a user must be able to access at least one agent or profile context to start or use chat. The chatAgentPicker:enable, chatProviderSettings:enable, and chatExpandToolCalls:enable permissions are UI toggles only and do not grant access to provider credentials or model catalogs on their own.

Team-Based Access Control

Teams allow you to share agents, MCP gateways, LLM proxies, and MCP servers with specific groups of users. Team-based access works alongside RBAC — roles control what actions a user can perform, and teams control which records they can see.
1

Create teams for different groups

Navigate to Settings > Teams and create teams that reflect your organizational structure, such as “Data Scientists”, “Developers”, or “Security”.
2

Assign resources to teams

When creating or editing an agent, MCP gateway, LLM proxy, or MCP server, set its visibility to the relevant team.
3

Add users to teams

Add users to teams based on their role and responsibilities. Users will automatically see the resources assigned to their teams.

Default Team

New users are automatically added to the Default Team when they accept an invitation. This ensures all users have immediate access to any Archestra resources assigned to this team.

Team Access Rules

MCP Gateways, LLM Proxies & Agents

Users can only see resources assigned to teams they belong to. Exceptions: users with the :admin permission see all records; resources with no team assignment are visible to all users.

MCP Servers

Users can only access MCP servers assigned to their teams. Exceptions: users with mcpServerInstallation:admin see all servers; servers with no team assignment are accessible to all users.
Team-based access also extends to related artifacts such as interaction logs, policies, and tool assignments — members can only view these for agents and MCP servers they have access to.

Best Practices

Start new users with the Member role and add specific permissions as needed. This principle of least privilege reduces the blast radius of accidental or malicious actions.
  • Principle of Least Privilege — Grant only the minimum permissions necessary for a user’s role.
  • Team-based organization — Combine roles with teams for fine-grained resource access rather than granting broad org-wide permissions.
  • Regular review — Periodically review custom roles and team memberships to ensure they align with current needs and security requirements.
  • Clear naming — Use descriptive names for custom roles that indicate their purpose, such as Agent-Manager, Read-Only-Analyst, or Tool-Developer.