Admin Handbook - Runlayer MCP Platform

What is the Admin Role?

As an Runlayer administrator, you have elevated permissions to:

Review and approve MCP requests from employees
Create access policies controlling who can use which MCPs
Monitor security alerts for suspicious activity
Manage users and permissions across your organization
View analytics to understand usage patterns
Configure system settings for your organization

Admin vs Regular Users

Regular Users	Administrators
Request MCPs	Approve/reject requests
Use approved MCPs	Grant access to MCPs
View their own audit logs	View all audit logs
See their usage	See organization-wide analytics
Cannot create policies	Create and manage policies

Understanding the Approval Workflow

MCP servers can access sensitive company data and perform actions on behalf of users. The approval process ensures:

Security: MCPs are vetted for potential risks
Compliance: Usage aligns with company policies
Data Protection: Sensitive data access is controlled
Audit Trail: All access is documented

How Requests Flow

Employee Submits Request
         ↓
Admin Receives Notification
         ↓
    Admin Reviews MCP
    ↙     ↘
Approve   Reject
   ↓         ↓
User can  Notification
use MCP      sent to user

Reviewing MCP Requests

Finding Pending Requests

You’ll also receive notifications:

Email alerts for new requests (if you’ve enabled them in email settings as an admin)
(Coming Soon) Unified Inbox experience with in-app notifications

Reviewing Request Details

Click on any pending MCP to see:

Requester Information

Who: Name, email, department
Role: Job title and team
Previous requests: History of approved/rejected MCPs
Current access: What MCPs they already use

MCP Configuration

Name and description: What the employee named it
Server URL: Where the MCP is hosted
Transport type: HTTP, SSE, or stdio
Authentication: OAuth, API key, or none
Environment variables: Configuration settings

Business Justification

Why needed: Employee’s explanation
Use case: What problem it solves
Expected value: Business impact
Alternatives considered: Why existing MCPs don’t work

Technical Details

Tools available: What the MCP can do
Resources exposed: What data it can access
Connection status: Test results
OAuth scopes: Permissions requested (if OAuth)

Security Review Checklist

Before approving any MCP request, complete this comprehensive security assessment:

Is the MCP from a trusted source?

For catalog MCPs:

Pre-vetted by Runlayer team
Generally safe to approve for appropriate use cases

For custom MCPs:

Known vendor or internal development team
Documentation is available and legitimate
Source code can be audited (if possible)
No known security vulnerabilities
Vendor has good security reputation
Recent updates and maintenance

Do the tools match expectations?

Tool names and descriptions are clear
No suspicious or obfuscated tool names
Tools match the MCP’s stated purpose
No unexpected permissions or capabilities
Tool metadata doesn’t contain malicious instructions
Parameter requirements are reasonable
No tools for shell execution or file system access (unless justified)

What data can this MCP access?

Data access scope is clearly defined
Access level is appropriate for the use case
No access to overly sensitive data (PII, financial, health)
Complies with data handling policies
Data retention is understood
No data exfiltration risks
Read-only access when possible

Is authentication properly configured?

Auth method is appropriate (OAuth, API key, none)
OAuth scopes are minimal and necessary
Credentials are stored securely
Token refresh is handled properly
No credentials in plain text
MFA required for sensitive MCPs

Can Runlayer reach the MCP server?

Server URL is valid and reachable
Firewall rules allow connection
TLS/SSL is properly configured (for external servers)
No proxy issues
Network path is secure
Connection test succeeds

Is there a legitimate business need?

Use case is clearly explained
Requester’s role justifies the need
No existing MCP can fulfill the need
Expected business value is reasonable
Not for personal use
Aligns with job responsibilities

Does this comply with company policies?

Aligns with data governance policies
Meets compliance requirements (GDPR, SOC 2, HIPAA, etc.)
Follows least-privilege principles
Will be documented in MCP inventory
No regulatory concerns
Legal has approved if needed

Testing the Connection

Before approving, test that the MCP works:

Click 'Test Connection'

Button appears on the MCP details page > Configure

Review Test Results

Success indicators:

✅ Connection successful
✅ Server responded correctly
✅ MCP protocol validated
✅ Tools list populated

Failure indicators:

❌ Connection timeout (network issue)
❌ Authentication failed (credential issue)
❌ Invalid response (protocol issue)
❌ No tools found (configuration issue)

Inspect Available Tools

Review what tools the MCP provides:

Do they match the description?
Are they reasonable for the use case?
Any suspicious or dangerous tools?

If the test fails, consider rejecting with instructions to fix the issues first.

Approval and Rejection Actions

Approving a Request

When you’re satisfied the MCP is safe and appropriate:

Click 'Approve'

Green approve button on the MCP details page

Review Summary

Confirm you’re approving the right MCP

Add Notes (optional)

Document any special considerations or monitoring requirements

Confirm Approval

Click “Confirm” to finalize

What happens automatically:

Status changes to “Active” - MCP is now usable
Auto-policy created - Requester is granted access
Notification sent - User receives email/in-app notification
Connection initialized - Runlayer tests the MCP
Audit log created - Approval is permanently logged

Rejecting a Request

When a request doesn’t meet security or policy requirements:

Click 'Reject'

Red reject button on the MCP details page

Provide Detailed Reason (Required)

Explain clearly why the request is rejected:Be specific:

❌ Bad: “Security concerns”
✅ Good: “This MCP requests access to all customer data without clear justification for needing that scope. Please resubmit with a specific use case and narrower data access.”

Include:

What the specific issue is
What needs to be fixed (if resubmittable)
Alternatives if available

Suggest Next Steps

Help the employee understand what to do:

How to resubmit with fixes
Existing MCPs that might work
Who to contact for questions

Confirm Rejection

Click “Confirm” to finalize

What happens after rejection:

Status changes to “Rejected”
User receives detailed notification with your reason
Audit log created for compliance
User can submit a new request after addressing issues

Common Approval Scenarios

Scenario 1: Standard Catalog MCP ✅

Request: Marketing analyst requests Brave Search MCP from catalog Review:

✅ Pre-vetted catalog item
✅ Employee needs web search for market research
✅ Clear business justification
✅ Standard permissions
✅ No sensitive data access

Decision: Approve quickly (within 1-2 hours) Follow-up: None needed - standard approval

Scenario 2: Custom Internal MCP ⚠️

Request: Support engineer requests custom customer database MCP Review:

⚠️ Custom MCP needs deeper review
✅ Internal server, known development team
✅ Test connection successful
⚠️ Provides access to customer PII
✅ Requester has legitimate need (support role)
✅ Strong business justification

Decision: Approve with monitoring (within 1 day) Follow-up Actions:

Create policy limiting to support team only
Set up security alerts for unusual activity
Monitor usage patterns weekly
Document in high-risk MCP list

Scenario 3: Unknown Third-Party MCP ❌

Request: Developer requests third-party code analysis MCP Review:

❌ Unknown vendor with no documentation
❌ Cannot verify legitimacy
❌ Tool descriptions are vague
⚠️ Requests broad file system access
❌ Test connection fails
⚠️ Could access proprietary code

Decision: Reject with detailed feedback Rejection Message:

This MCP request cannot be approved due to:

1. Unknown vendor - no documentation or security information provided
2. Unable to verify server is safe and legitimate  
3. Connection test failed - server may not be properly configured
4. File system access scope is too broad for stated use case
5. Potential risk to proprietary code and IP

To resubmit, please provide:
- Official vendor documentation and security details
- Working server URL that passes connection test
- Clear justification for file system access scope
- Confirmation from IT security team

Alternatively, consider using our approved "CodeAnalyzer MCP" which provides similar functionality with proper security controls.

Contact me if you have questions: [email protected]

Scenario 4: Redundant MCP ❌

Request: Employee requests GitHub MCP (already exists) Review:

✅ Safe, known MCP
❌ GitHub MCP already active in organization
❌ Requester just needs access, not new server

Decision: Reject with alternative Rejection Message:

We already have an active GitHub MCP in our organization. Rather than creating a duplicate, I've granted you access to the existing server.

You can now use the GitHub MCP:
1. Go to MCPs page
2. Click on "GitHub Integration"  
3. Generate your API key
4. Follow installation instructions

The existing MCP is already configured and secure. Let me know if you need any help setting it up!

Follow-up Action:

Create access policy granting user access to existing GitHub MCP

Managing Access Policies

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

This design ensures you can easily grant appropriate access while maintaining security through least privilege. Advanced: Policy Conditions For sensitive resources, you can add conditions that evaluate at runtime:

Restrict SQL queries to specific tables (payload.table validation)
Enforce IP-based access (meta.request.ip checks)
Validate OAuth requirements (meta.oauth.user_verified)

Conditions are optional and should be used when scope alone isn’t sufficient. See Policies for detailed examples.

Creating Access Rules

Navigate to MCP Permissions

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

Click 'New Access Rule'

Opens the access rule creation dialog

Select Who Gets Access

Choose User, Group, or Role, then select specific ones from the dropdown

Define Access Scope

Choose between:

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

Add Rule

Click “Add Rule” to save - takes effect immediately

Access Rule Examples

Example 1: 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

Example 2: 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

Example 3: 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

Example 4: Role-Based Access

Scenario: Give all users with “Support” role access to customer database

Applies To: Role "Support"
Access Scope: Entire Server
Result: Anyone assigned Support role gets full customer database MCP access

When to use:

Access tied to job function, not department
Roles managed centrally in your SSO
Dynamic team membership

Best Practices

Start with Specific Tools, Not Entire Server

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

Use Groups, Not Individual Users

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

Leverage SCIM for Automatic Group Sync

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

Regularly Audit Access

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

Advanced Scenarios

Emergency Access Revocation

If you detect suspicious activity:

Go to the MCP’s Permissions tab
Identify the user’s access rule
Delete the rule immediately
User’s active sessions are terminated
Investigate in Audit Logs

Temporary Contractor Access

When contractors need temporary access:

Create individual user rule (not group)
Use specific tools only
Set calendar reminder to revoke after project
Document end date in rule notes
Review in weekly admin checklist

Global Policies for Organization-Wide Security

For organization-wide restrictions that apply to all servers, use global policies (Admin → Policies): Common scenarios:

Corporate Network Only

Deny all access from outside corporate IP ranges
Condition: meta.request.ip NOT_IN_IP_RANGE ["10.0.0.0/8", "172.16.0.0/12"]

Restrict Access to Specific MCP Client Only

Allow only approved clients (e.g., restrict to Cursor only)
Condition: meta.request.user_agent NOT_BEGINS_WITH "Cursor"
Note: This denies all clients except Cursor

Require OAuth Verification

Block unverified OAuth sessions
Condition: meta.oauth.user_verified EQUALS false

Key differences from server-level policies:

Scope: All servers/tools/resources (*)
Action: Deny only (cannot grant access)
Location: Admin → Policies (not per-server)
Use for: Security, compliance, risk mitigation

Global policies block organization-wide. Test with a small group first, then expand to everyone after validating behavior in audit logs.

Monitoring Security Alerts

Navigate to Security to monitor access violations and security events.

Dashboard Components

Security Alerts - Click “Review” to see details in Audit Logs:

Policy Denied Actions
Failed Authentication Attempts
Authentication Error
Login Failed

Top Blocked Servers - MCPs with most access denials

High counts may indicate missing access policies

Top Blocked Users - Users with most blocked attempts

May need access or training

Policy Denials Timeline - Violations over time Security Violations Timeline - Security scanner detections:

Input: Suspicious requests to MCPs
Output: Suspicious responses from MCPs

Most Common Security Violation Reasons - Specific threats detected

Responding to Issues

High blocks for one user: Grant access or investigate unauthorized attempts High blocks for one server: Review if team needs access Spike in violations: Potential security incident - escalate Repeated auth failures: Fix credentials or detect attack

Managing Users and Permissions

Viewing Users

Navigate to Users to see:

All users in your organization (synced from SSO)
User roles: Admin or standard user
User status: Active, inactive, or suspended
Last login: When they last accessed Runlayer
MCP access: Which MCPs each user has permission to use

Assigning Admin Roles

Select User

Click on user from the users list

Edit Role

Click “Edit” next to their role

Set to Admin

Change from “User” to “Admin”

Confirm

User immediately gains admin privileges

Admin role grants:

Ability to approve/reject MCP requests
Access to all audit logs and analytics
Permission to create policies
User management capabilities

Only grant admin role to trusted personnel.

Viewing Analytics and Usage Patterns

Navigate to Analytics to view organization-wide usage and adoption metrics. Usage:

Users: Active vs inactive
Teams: Active vs inactive
Servers: Active, pending, and rejected counts

Security Alerts - Policy violations and authentication failures at a glance Tool Calls Over Time:

Total tool calls trend
Failed calls overlay
Filter by date range

Top Active Users - Users sorted by activity count

Identify power users and adoption leaders

Top Actions - Most invoked MCP tools

See which tools provide most value

Admin Best Practices

Approval Timelines

Set and communicate clear expectations:

MCP Type	Target Timeline	Priority
Catalog MCPs	4-8 hours	High
Custom internal MCPs	1-2 business days	Medium
Third-party custom MCPs	2-3 business days	Medium
High-risk/sensitive MCPs	Up to 1 week	Review carefully
Urgent business need	Same day	Coordinate escalation

Tips:

Respond to all requests within 1 business day (even if just acknowledging)
Set auto-reply if you’ll be unavailable
Delegate to backup admin when on vacation
Flag urgent requests in your notification settings

Security Practices

Protect Your Admin Account

Enable MFA (required)
Use strong unique password
Don’t share admin credentials
Log out when not in use
Use separate account for admin vs regular work (if possible)

Regular Audits

Review all active MCPs quarterly
Audit policies semi-annually
Check for unused MCPs monthly
Review admin access list quarterly

Stay Updated

Monitor MCP security advisories
Track new vulnerabilities
Update approval criteria as threats evolve
Participate in security training
Share learnings with other admins

Principle of Least Privilege

Grant minimum necessary access
Review and tighten policies over time
Remove access when no longer needed
Use tool-specific restrictions when possible
Use conditions for sensitive data (table-level, path-based restrictions)

Choose Server-Level vs Global Policies

Use the right policy type for your use case:Server-level policies (MCPs → [Server] → Policies):

Grant access to specific servers/tools
Allow or Deny actions
User/group/role-specific rules

Global policies (Admin → Policies):

Organization-wide security controls
Deny-only (no grants)
IP blocks, client restrictions, compliance

Example combination:

Global: Block all non-VPN IPs
Server-level: Allow Finance to query specific tables
Result: Finance accesses from VPN with table restrictions

Continuous Improvement

Monthly reviews:

What MCPs are most requested?
What are common rejection reasons?
Where are approval bottlenecks?
Are timelines being met?

Quarterly improvements:

Add commonly-requested MCPs to catalog
Streamline approval for low-risk MCPs
Update security checklists
Train new admins

Annual planning:

Review MCP strategy with leadership
Plan for new capabilities
Budget for additional resources
Update policies for new regulations

Employee Handbook

Guide for employees requesting and using MCPs

Security Best Practices

Comprehensive security guidelines and threat prevention

Adding Custom MCPs

Technical guide for creating custom MCP servers

Quick Start

Deploy and configure Runlayer

Support

Email: [email protected]
Documentation: Full docs at your Runlayer instance
Audit Logs: Track all admin actions and decisions
Security Team: Escalation contact for incidents

Getting Started

Platform

Cookbook

Integrations

Resources

​What is the Admin Role?

​Admin vs Regular Users

​Understanding the Approval Workflow

​How Requests Flow

​Reviewing MCP Requests

​Finding Pending Requests

​Reviewing Request Details

​Security Review Checklist

​Testing the Connection

​Approval and Rejection Actions

​Approving a Request

​Rejecting a Request

​Common Approval Scenarios

​Scenario 1: Standard Catalog MCP ✅

​Scenario 2: Custom Internal MCP ⚠️

​Scenario 3: Unknown Third-Party MCP ❌

​Scenario 4: Redundant MCP ❌

​Managing Access Policies

​How Access Rules Work

​Creating Access Rules

​Access Rule Examples

​Example 1: Team-Wide Server Access

​Example 2: Fine-Grained Tool Access

​Example 3: Individual User Access

​Example 4: Role-Based Access

​Best Practices

​Advanced Scenarios

​Emergency Access Revocation

​Temporary Contractor Access

​Global Policies for Organization-Wide Security

​Monitoring Security Alerts

​Dashboard Components

​Responding to Issues

​Managing Users and Permissions

​Viewing Users

​Assigning Admin Roles

​Viewing Analytics and Usage Patterns

​Admin Best Practices

​Approval Timelines

​Security Practices

​Continuous Improvement

​Related Documentation

Employee Handbook

Security Best Practices

Adding Custom MCPs

Quick Start

​Support

What is the Admin Role?

Admin vs Regular Users

Understanding the Approval Workflow

How Requests Flow

Reviewing MCP Requests

Finding Pending Requests

Reviewing Request Details

Security Review Checklist

Testing the Connection

Approval and Rejection Actions

Approving a Request

Rejecting a Request

Common Approval Scenarios

Scenario 1: Standard Catalog MCP ✅

Scenario 2: Custom Internal MCP ⚠️

Scenario 3: Unknown Third-Party MCP ❌

Scenario 4: Redundant MCP ❌

Managing Access Policies

How Access Rules Work

Creating Access Rules

Access Rule Examples

Example 1: Team-Wide Server Access

Example 2: Fine-Grained Tool Access

Example 3: Individual User Access

Example 4: Role-Based Access

Best Practices

Advanced Scenarios

Emergency Access Revocation

Temporary Contractor Access

Global Policies for Organization-Wide Security

Monitoring Security Alerts

Dashboard Components

Responding to Issues

Managing Users and Permissions

Viewing Users

Assigning Admin Roles

Viewing Analytics and Usage Patterns

Admin Best Practices

Approval Timelines

Security Practices

Continuous Improvement

Related Documentation

Support