Skip to main content

​
Managing Access Policies

Permissions After approving MCPs, you control who can access them through access rules. Runlayer’s policy system combines fine-grained permissions with ease of use, achieving both accuracy and least privilege by default.

​
How Access Rules Work

Access rules grant permissions to users, groups, roles, or agent accounts for specific MCP servers. Each rule can include multiple principals of the same type — for example, several users or several groups in one rule. Applies To (Who gets access):
  • User: One or more individual employees by email/ID
  • Group: One or more teams synced from your SSO (Engineering, Marketing, etc.)
  • Role: One or more job functions or custom roles
  • Agent Account: One or more machine-to-machine identities (see Agent Accounts)
Access Scope (What they can access):
  • Entire Server: Full access to all tools in the MCP
  • Specific Tools & Resources: Fine-grained selection of individual tools
Conditions (Advanced - Optional):
  • Add runtime rules based on tool arguments (e.g., restrict SQL queries to specific tables)
  • Enforce network restrictions (e.g., corporate IP ranges only)
  • Validate OAuth session properties (e.g., require verified accounts)
  • Block specific MCP clients
This design ensures you can easily grant appropriate access while maintaining security through least privilege.

​
Policy Types

Runlayer supports two types of policies:

​
Server-Level Policies

Manage access to specific MCP servers. Navigate to Build → [Server Name] → Policies tab.
  • Scope: One or more specific servers
  • Action: Allow or Deny
  • Use for: Granting access, fine-grained tool restrictions
  • Example: Allow Finance group to use database query tools

​
Global Policies

Organization-wide restrictions that apply everywhere. Navigate to Admin → Policies.
  • Scope: All servers, tools, and resources (*)
  • Action: Deny only
  • Use for: IP blocks, client restrictions, compliance requirements
  • Example: Block all access from outside corporate network
Use global policies for organization-wide security controls, and server-level policies for granting and managing access to specific resources.

​
Creating Access Rules

1

Navigate to MCP Permissions

Go to the MCP you want to grant access to → Permissions tab
2

Click 'New Access Rule'

Opens the access rule creation dialog
3

Select Who Gets Access

Choose a principal type (User, Group, Role, or Agent Account), then select one or more from the dropdown. A single rule can include multiple principals of the same type.
4

Define Access Scope

Choose between:
  • Entire Server: Grant access to all tools (faster, simpler)
  • Specific Tools & Resources: Select individual tools (more secure, granular)
5

Add Rule

Click “Add Rule” to save - takes effect immediately

​
Access Rule Examples

​
Team-Wide Server Access

Scenario: Give engineering and devops teams access to the GitHub MCP 
Applies To: Group "Engineering", Group "DevOps"
Access Scope: Entire Server
Result: All members of both groups can use every tool in the GitHub MCP
When to use:
  • Multiple teams need comprehensive access
  • Server tools are all appropriate for the groups
  • Simplicity is preferred over granularity

​
Fine-Grained Tool Access

Scenario: Give finance analysts read-only access to the Database MCP 
Applies To: Group "Finance"
Access Scope: Specific Tools & Resources
Selected Tools:
  - list_tables
  - query_database
  - read_schema
Result: Finance can only query and read, not modify data
When to use:
  • Sensitive MCPs require least privilege
  • Only specific tools are needed
  • Different roles need different capabilities

​
Annotation-Based Access (Read-Only Tools)

Scenario: Give data analysts access to all tools, but only allow read-only ones at invocation time 
Applies To: Group "Data Analysts"
Access Scope: Entire Server
Conditions:
  - meta.tool.annotations.readOnlyHint EQUALS true
Result: Data Analysts can see all tools, but can only invoke
        tools annotated as read-only
When to use:
  • Restrict access based on tool capabilities (read-only, destructive, etc.)
  • Enforce safety boundaries at invocation time
  • Works across any server with annotated tools

​
Individual User Access

Scenario: Give a contractor temporary access to specific Slack tools 
Applies To: User "contractor@company.com"
Access Scope: Specific Tools & Resources
Selected Tools:
  - list_channels
  - read_messages
  - search_messages
Result: Contractor can read but not post or manage Slack
When to use:
  • Individual exceptions needed
  • Temporary access for specific users
  • Contractors or external collaborators
  • Testing new MCPs with a single user first

​
Conditional Access by Tool Arguments

Scenario: Allow finance team to query only sales and finance tables 
Applies To: Group "Finance"
Access Scope: Specific Tools
Selected Tools: query_sql
Conditions:
  - payload.table BEGINS_WITH ["sales_", "finance_"]
Result: Finance can query sales_* and finance_* tables only
When to use:
  • Database access needs table-level restrictions
  • File systems need path-based access control
  • APIs need parameter validation
  • Sensitive data requires fine-grained control

​
Global Policy: Block External IPs

Scenario: Require all users to access MCPs from corporate network 
Location: Admin → Policies (Global)
Applies To: Everyone
Action: Deny
Scope: All servers, tools, resources (*)
Conditions:
  - meta.request.ip NOT_IN_IP_RANGE ["10.0.0.0/8", "172.16.0.0/12"]
Result: Any access from outside corporate IPs is blocked
When to use:
  • Compliance requires network-based access control
  • Remote work must use VPN
  • Sensitive data needs IP restrictions
  • Organization-wide security policy

​
Restrict Gmail to Internal Recipients Only

Scenario: Prevent outgoing Gmail messages to external recipients, allowing only emails sent to your internal domain (e.g., @runlayer.com) 
Location: MCP -> Connectors → Gmail → Policies tab
Applies To: Group "Everyone" (or specific teams)
Action: Deny
Access Scope: Specific Tools
Selected Tools:
  - send_email
  - send_draft
Conditions:
  - payload.to NOT_ENDS_WITH "@runlayer.com"
Result: Users can only send emails to @runlayer.com addresses; 
        attempts to email external domains are blocked
You can extend this policy to also check payload.cc and payload.bcc fields using additional condition rules to ensure internal-only communication across all recipient types.
When to use:
  • Prevent data exfiltration via email in AI agent workflows
  • Enforce internal-only communication for sandbox or development environments
  • Provide guardrails for agents with Gmail access
  • Meet compliance requirements for regulated data
  • Test new AI workflows safely before allowing external communication

​
Block Tools That Accept Sensitive Parameters

Scenario: Prevent any tool that requires a password parameter from being invoked 
Location: Admin → Policies (Global)
Applies To: Everyone
Action: Deny
Scope: All servers, tools, resources (*)
Conditions:
  - meta.tool.input_schema.required LIST_CONTAINS password
Result: Any tool whose JSON Schema lists "password" as a
        required field is blocked at invocation time
When to use:
  • Prevent credential-handling tools from running without approval
  • Block tools with dangerous parameter shapes (e.g., sql, command)
  • Works with any meta.tool.input_schema.* subfield (e.g., type, required)
input_schema is the tool’s JSON Schema object. Use dot-path subfields like meta.tool.input_schema.required with the list_contains operator, or meta.tool.input_schema.type with equals.

​
Block Destructive Tools Organization-Wide

Scenario: Prevent all users from invoking tools that may delete or overwrite data 
Location: Admin → Policies (Global)
Applies To: Everyone
Action: Deny
Scope: All servers, tools, resources (*)
Conditions:
  - meta.tool.annotations.destructiveHint EQUALS true
Result: Any tool marked as destructive is blocked at invocation time
When to use:
  • Enforce safety boundaries across the organization
  • Protect production data from accidental deletion
  • Compliance requirements for data preservation
  • Gradual rollout (start with deny-all, grant exceptions)

​
Condition Value Matching

When writing conditions, keep these matching rules in mind:
BehaviorDetails
String comparisons are case-sensitiveequals, contains, begins_with, ends_with, and regex all match exact casing. "Cursor" does not match "cursor".
Boolean values are case-insensitiveFields like meta.tool.annotations.readOnlyHint or meta.subject.is_active accept true, True, or TRUE interchangeably.
Tool and resource names are case-sensitiveScope entries (tools, resources) must match the exact name from the MCP server.
IP ranges use CIDR notationip_range / not_ip_range operators accept single or comma-separated CIDRs (e.g., 10.0.0.0/8, 172.16.0.0/12).

​
Best Practices

When in doubt, grant access to specific tools first. You can always expand later if needed.Why?
  • Easier to add permissions than remove them
  • Users won’t miss tools they didn’t know existed
  • Reduces attack surface if credentials are compromised
Create access rules for groups whenever possible, even if the group only has one member initially.Why?
  • Scales better as teams grow
  • Easier to audit (who’s in “Engineering” vs 50 individual rules)
  • Syncs automatically with SSO changes
  • Simplifies onboarding/offboarding
Runlayer automatically syncs groups from your identity provider (IDP) via SCIM, mirroring your org structure.What this means:
  • Groups from Okta, Azure AD, or Google Workspace sync automatically
  • New employees added to groups get access immediately
  • Employees removed from groups lose access instantly
  • No manual group management needed
Best practice:
  • Create access rules using your existing IDP groups
  • Engineering, Sales, Finance groups work out of the box
  • Changes in your IDP reflect in Runlayer instantly
Review access rules quarterly:
  • Who has access to sensitive MCPs?
  • Are there users who no longer need access?
  • Can we tighten tool permissions?
Why?
  • Prevents scope creep
  • Maintains least privilege
  • Required for compliance
Add conditions when scope alone isn’t enough:Good use cases:
  • Restrict database queries to specific tables
  • Limit file access to certain paths
  • Validate API parameters
  • Enforce network restrictions
Available context:
  • payload.* - Tool arguments (e.g., payload.table, payload.path)
  • meta.request.ip - Client IP address
  • meta.request.user_agent - HTTP User-Agent header for client identification
  • meta.subject.* - Subject email, roles, groups, type (user or agent)
  • meta.user.* - Alias for meta.subject.* (backward compatibility)
  • meta.oauth.* - OAuth provider, scopes, verification
  • meta.server.* - Server name, deployment mode, auth type
  • meta.tool.name - Tool name being invoked
  • meta.tool.description - Tool description
  • meta.tool.annotations.* - Tool annotations (e.g., meta.tool.annotations.readOnlyHint)
  • meta.tool.input_schema - Tool input JSON schema
Start simple: Begin without conditions, add them only when needed for sensitive data or compliance.
Apply security controls across all resources:Common use cases:
  • Block access from outside corporate network
  • Restrict access to approved clients only (e.g., allow only Cursor)
  • Require OAuth verification
  • Enforce compliance requirements
Remember:
  • Global policies can only DENY (not allow)
  • They apply to all servers, tools, and resources
  • Manage them in Admin → Policies
  • Test with small groups before applying to everyone
Combine with server policies: Use global denies for security, server-level allows for access grants.

Admin Handbook

Complete policy management guide

Security

Monitor security alerts

Approvals

Review MCP requests

Security Best Practices

Security guidelines