Skip to main content

​
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)
ControlsPlatform features (dashboard, API)MCP tool invocations
Enforced atAPI endpointsMCP proxy
Configured viaRole assignment or SCIM group-to-role mappingAccess policies
Example”Can this user view audit logs?""Can this user call query_database on the Snowflake MCP?”
A user needs both: the right role to access platform features, AND a matching policy to call MCP tools.

​
Roles

RoleDescription
Super AdminFull platform access. Manages roles, settings, and all features.
Security AdminMonitors security, manages policies, reviews audit logs and user info.
IT AdminManages connectors, policies, and user MCP access.
Analytics AdminViews org-wide metrics, audit logs, and exports usage data.
DeveloperDeploys MCPs, manages agent accounts, uses the management API.
HelpdeskViews user info and audit logs for support purposes.
UserUses assigned MCPs only. No admin features.
Users without any admin role are assigned the User role by default. They can only use MCPs they have been granted access to.

​
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 Settings → Roles in your Runlayer dashboard.
The capability matrix is updated as new features arrive. The live version in Settings → Roles is always the source of truth.

​
Where to Find Key Settings

Admin configuration lives under Settings in the Runlayer dashboard. Which pages a user can see and change depends on their role capabilities. Quick map:
Settings pageWhat it configuresDocs
Settings → UsersUser accounts and role assignmentsAssigning Roles
Settings → RolesLive capability matrix for each roleCapability Matrix
Settings → GeneralDirectory sync (SCIM), full session scanning, OAuth redirect URIs, agent run limitsSessions, Connectors
Settings → PoliciesGlobal access policies (PBAC)Policies
Settings → Security ScannersToolGuard scanners, PII rules, skill risk policy, session scanning (AgentGuard)ToolGuard Models, AgentGuard
Settings → AI ProvidersLLM providers and recommended model for agentsAgents
Settings → Agent AccountsAgent account credentials for programmatic accessAgent Accounts
Settings → IntegrationsSlack integration and Runlayer AssistantSlack Notifications
Settings → MDM ConfigurationAI Watch deployment via MDM, unresolved usernamesIdentity Mapping
Settings → Personal API keysAPI keys tied to your user identityManagement API
Settings → Organization API keysOrganization-scoped API keys (e.g. Deploy, AI Watch Scan roles)Management API
Settings → WorkspaceWorkspace-level options, e.g. showing admin setup instructions to all users—

​
Separation of Duty

Certain role combinations cannot be assigned to the same user to prevent conflicts of interest:
Forbidden combinationReason
Security Admin + IT AdminSeparates security oversight from infrastructure management
Security Admin + DeveloperSeparates security policy control from code deployment
If you attempt to assign a forbidden combination, the assignment will fail with an error. To resolve, remove one of the conflicting roles first. Role separation controls platform administration. It does not automatically prevent someone who creates an agent from later being granted permission to use that agent; agent usage is controlled by agent sharing, connector policies, and MCP access policies. For high-risk agents, keep creator/admin roles narrow, share the agent to a pilot group at Can use, and grant only the connector tools that group needs.

​
Assigning Roles

Use these steps when SCIM is not enabled.
1

Navigate to Users

Go to Settings → Users and select the user you want to manage.
2

Edit Roles

Click Edit next to the user’s current role(s).
3

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.
4

Save

Confirm the assignment. Changes take effect immediately.
Only users with the Manage Admins capability (Super Admin) can assign or remove roles.
If SCIM is enabled, roles cannot be assigned manually here. See the SCIM Role Sync section below for more details.

​
SCIM Role Sync

When SCIM is enabled, manual roles and groups assignments are not supported. Your identity provider (e.g. Okta, Azure AD, Google Workspace) becomes the source of truth.
  • Groups can be updated via the SCIM configuration in your identity provider.
  • Roles are determined by the groups-to-roles mapping. To configure this, go to Settings → General → Manage Directory Sync and scroll down to the “Role assignment” section.
Note: forbidden role combinations are enforced during sync: if the IdP assigns conflicting roles (e.g. Security Admin + IT Admin), the sync skips the conflicting assignment and logs a warning.

​
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
Recommended next step: Review your Super Admin users and consider whether a narrower role (Security Admin, IT Admin, etc.) would be more appropriate. Specialized roles reduce blast radius if an account is compromised.

​
Best Practices

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.
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.
People change teams. Remove roles that are no longer needed. Check that separation of duty rules are still appropriate.
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.

Policies

Configure PBAC policies for MCP tool access