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, or roles for specific MCP servers: Applies To (Who gets access):
  • User: Individual employees by email/ID
  • Group: Teams synced from your SSO (Engineering, Marketing, etc.)
  • Role: Job functions or custom roles
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

Anysource supports two types of policies:

​
Server-Level Policies

Manage access to specific MCP servers. Navigate to MCPs → [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 User, Group, or Role, then select specific ones from the dropdown
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 all engineers access to the GitHub MCP 
Applies To: Group "Engineering"
Access Scope: Entire Server
Result: All engineers can use every tool in the GitHub MCP
When to use:
  • Teams need comprehensive access
  • Server tools are all appropriate for the group
  • 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

​
Individual User Access

Scenario: Give a contractor temporary access to specific Slack tools 
Applies To: User "[email protected]"
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

​
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.user.* - User email, roles, groups
  • meta.oauth.* - OAuth provider, scopes, verification
  • meta.server.* - Server name, deployment mode, auth type
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