How Authorization Works in Runlayer
Runlayer uses two independent authorization layers:Fine-Grained Access (FGA)
Controls who can access platform features — managing MCPs, viewing audit logs, creating policies, configuring settings. Enforced on every dashboard API endpoint. This is what roles and capabilities control.
Policy-Based Access Control (PBAC)
Controls what happens when users invoke MCP tools through the proxy. Policies evaluate conditions like IP range, tool name, or OAuth status at call time. See Policies.
| FGA (Roles) | PBAC (Policies) | |
|---|---|---|
| Controls | Platform features (dashboard, API) | MCP tool invocations |
| Enforced at | API endpoints | MCP proxy |
| Configured via | Role assignment | Access policies |
| Example | ”Can this user view audit logs?" | "Can this user call query_database on the Snowflake MCP?” |
Roles
| Role | Description |
|---|---|
| Super Admin | Full platform access. Manages roles, settings, and all features. |
| Security Admin | Monitors security, manages policies, reviews audit logs and user info. |
| IT Admin | Manages MCP servers, catalog, policies, and user MCP access. |
| Analytics Admin | Views org-wide metrics, audit logs, and exports usage data. |
| Developer | Deploys MCPs, manages agent accounts, uses the management API. |
| Helpdesk | Views user info and audit logs for support purposes. |
| User | Uses assigned MCPs only. No admin features. |
Server Admin is a special server-scoped role with no platform capabilities. It is assigned per-server, not org-wide.
Capability Matrix
Each role grants a fixed set of capabilities. Super Admin has all capabilities. To see the full, up-to-date matrix, go to Admin → Roles in your Runlayer dashboard.The capability matrix is updated as new features arrive. The live version in Admin → Roles is always the source of truth.
Separation of Duty
Certain role combinations cannot be assigned to the same user to prevent conflicts of interest:| Forbidden combination | Reason |
|---|---|
| Security Admin + IT Admin | Separates security oversight from infrastructure management |
| Security Admin + Developer | Separates security policy control from code deployment |
Assigning Roles
Select Role(s)
Choose one or more roles from the dropdown. Users can hold multiple roles — their capabilities are the union of all assigned roles.
Migration from Admin to Super Admin
Previously, Runlayer had a single Admin role with full permissions. This has been replaced by Super Admin and several specialized roles. What changed:- All existing Admin users have been automatically migrated to Super Admin
- No permissions changed — Super Admin has the same capabilities as the old Admin role
- No action is required from your side
Best Practices
Start with the narrowest role
Start with the narrowest role
Assign the most specific role that covers the user’s responsibilities. You can always add more roles later. A security analyst likely needs Security Admin, not Super Admin.
Prefer specialized roles over Super Admin
Prefer specialized roles over Super Admin
Super Admin should be limited to a small number of trusted users. Most admin tasks are covered by Security Admin, IT Admin, or other specialized roles.
Review role assignments quarterly
Review role assignments quarterly
People change teams. Remove roles that are no longer needed. Check that separation of duty rules are still appropriate.
Respect separation of duty
Respect separation of duty
The forbidden role combinations exist for good reason. If someone needs capabilities from both Security Admin and IT Admin, consider whether the tasks can be split between two people instead.