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
View full Editor permission matrix
View full Editor permission matrix
Member Permissions
View full Member permission matrix
View full Member permission matrix
Custom Roles
Users with theac: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
Access Control
Access Control
Agents & Skills
Agents & Skills
LLM Proxy
LLM Proxy
MCP Gateways & Registry
MCP Gateways & Registry
Knowledge Base
Knowledge Base
Users, Teams & Organization
Users, Teams & Organization
API Keys, Secrets & Chat
API Keys, Secrets & Chat
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 userteam— shared with one or more teamsorg— shared across the entire organization
Agents, MCP Gateways, and LLM Proxies
These three resources share the same scope model: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 bothchat: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.Best Practices
- 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, orTool-Developer.