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.
A user needs both: the right role to access platform features, AND a matching policy to call MCP tools.

​
Roles

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:

​
Separation of Duty

Certain role combinations cannot be assigned to the same user to prevent conflicts of interest: 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