Skip to main content

​
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 UsersAdministrators
Request MCPsApprove/reject requests
Use approved MCPsGrant access to MCPs
View their own audit logsView all audit logs
See their usageSee organization-wide analytics
Cannot create policiesCreate 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

Approvals 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

Review Click on any pending MCP to see:
  • Who: Name, email, department
  • Role: Job title and team
  • Previous requests: History of approved/rejected MCPs
  • Current access: What MCPs they already use
  • 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
  • Why needed: Employee’s explanation
  • Use case: What problem it solves
  • Expected value: Business impact
  • Alternatives considered: Why existing MCPs don’t work
  • 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:
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
  • 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)
  • 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
  • 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
  • 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
  • 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
  • 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

Test Connection Before approving, test that the MCP works:
1

Click 'Test Connection'

Button appears on the MCP details page > Configure
2

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)
3

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

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

Click 'Approve'

Green approve button on the MCP details page
2

Review Summary

Confirm you’re approving the right MCP
3

Add Notes (optional)

Document any special considerations or monitoring requirements
4

Confirm Approval

Click “Confirm” to finalize
What happens automatically:
  1. Status changes to “Active” - MCP is now usable
  2. Auto-policy created - Requester is granted access
  3. Notification sent - User receives email/in-app notification
  4. Connection initialized - Runlayer tests the MCP
  5. Audit log created - Approval is permanently logged

​
Rejecting a Request

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

Click 'Reject'

Red reject button on the MCP details page
2

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
3

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
4

Confirm Rejection

Click “Confirm” to finalize
What happens after rejection:
  1. Status changes to “Rejected”
  2. User receives detailed notification with your reason
  3. Audit log created for compliance
  4. 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

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

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

​
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

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

​
Advanced Scenarios

​
Emergency Access Revocation

If you detect suspicious activity:
  1. Go to the MCP’s Permissions tab
  2. Identify the user’s access rule
  3. Delete the rule immediately
  4. User’s active sessions are terminated
  5. Investigate in Audit Logs

​
Temporary Contractor Access

When contractors need temporary access:
  1. Create individual user rule (not group)
  2. Use specific tools only
  3. Set calendar reminder to revoke after project
  4. Document end date in rule notes
  5. 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:
  1. 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"]
  2. 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
  3. 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

Security 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

users

​
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

1

Select User

Click on user from the users list
2

Edit Role

Click “Edit” next to their role
3

Set to Admin

Change from “User” to “Admin”
4

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.

​
Managing Agent Accounts

Agent accounts are M2M (machine-to-machine) identities that allow AI applications to interact with MCP servers programmatically. As an administrator, you manage the full agent account lifecycle.

​
Creating Agent Accounts

1

Navigate to Agent Accounts

Go to Admin → Agent Accounts in the Runlayer UI
2

Click 'Add Agent Account'

Opens the agent account creation form
3

Fill in Agent Account Details

  • Name: A descriptive name (e.g., “CI/CD Automation Agent”)
  • Description: What the agent account does and who maintains it
4

Create and Save Credentials

After creation, you’ll see a one-time credential display:
  • Client ID: The agent account’s unique identifier
  • Client Secret: The authentication secret (shown only once!)
You must save these credentials immediately. They cannot be retrieved later.
Store agent account credentials in a secure secrets manager (1Password, AWS Secrets Manager, HashiCorp Vault). Never commit them to version control or share via insecure channels.

​
Rotating Credentials

Rotate agent account credentials periodically or after security events: When to rotate:
  • Every 90 days (recommended)
  • After a security incident or suspected exposure
  • When team members with access leave the organization
  • If unusual API activity is detected
How to rotate:
  1. Navigate to Admin → Agent Accounts
  2. Select the agent account
  3. Click Rotate Credentials
  4. Confirm the action
  5. Save the new client secret immediately
  6. Update your application with new credentials
Rotation immediately invalidates old credentials. Active sessions will fail until the application is updated with new credentials.

​
Managing Delegations

Delegations grant agent accounts permission to act on behalf of users. View and manage delegations from the agent account detail page. Viewing delegations:
  1. Navigate to Admin → Agent Accounts
  2. Select an agent account
  3. View the Delegations tab
Each delegation shows:
  • Delegator: The user who granted permission
  • Server Sessions: Which MCP servers are configured
  • Expiration: When the delegation expires (if set)
  • Status: Active, expired, or revoked
Revoking a delegation:
  1. Select the delegation
  2. Click Revoke
  3. Confirm revocation
Revoked delegations take effect immediately - the agent account can no longer request OBO tokens for that user.

​
Creating Policies for Agent Accounts

Agent accounts are PBAC (Policy-Based Access Control) subjects, just like users. Create policies to control what agent accounts can do. To create an agent account policy:
  1. Navigate to Admin → Policies
  2. Click Add Policy
  3. Set Principal Type to Agent Account
  4. Select the agent account from the dropdown
  5. Configure scope (servers, tools, resources)
  6. Add conditions if needed
  7. Save the policy
Example agent account policies:
PolicyConfiguration
Allow agent account to call all GitHub toolsPrincipal: Agent Account “CI Agent”, Scope: GitHub MCP (all tools), Action: Allow
Deny agent account from modifying dataPrincipal: Agent Account “Read-Only Agent”, Scope: Database MCP (write_* tools), Action: Deny
Allow agent account only specific toolsPrincipal: Agent Account “Slack Bot”, Scope: Slack MCP (send_message only), Action: Allow
When an agent account uses an OBO token, both the agent account’s policies AND the user’s policies must allow the action. This is the intersection (least privilege) model.

​
Viewing Agent Account Activity

Monitor agent account activity through audit logs:
  1. Navigate to Admin → Audit Logs
  2. Filter by:
    • Subject Type: Agent Account
    • Agent Account Name: Select specific agent account
    • Event Type: Token exchange, OBO calls, etc.
Key events to monitor:
EventDescription
agent_token_exchange_successAgent account successfully obtained OBO token
agent_token_exchange_denied_no_delegationAgent account attempted OBO without valid delegation
obo_call_grantedAgent account successfully called MCP tool on behalf of user
obo_call_deniedAgent account’s MCP call was blocked by policy
agent_credentials_rotatedAgent account credentials were rotated
Signs of issues:
  • High volume of token_exchange_denied events may indicate misconfiguration
  • Spikes in obo_call_denied may indicate policy issues or unauthorized access attempts
  • Failed authentication attempts may indicate compromised credentials

​
Viewing Analytics and Usage Patterns

Analytics 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 TypeTarget TimelinePriority
Catalog MCPs4-8 hoursHigh
Custom internal MCPs1-2 business daysMedium
Third-party custom MCPs2-3 business daysMedium
High-risk/sensitive MCPsUp to 1 weekReview carefully
Urgent business needSame dayCoordinate 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

  • 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)
  • Review all active MCPs quarterly
  • Audit policies semi-annually
  • Check for unused MCPs monthly
  • Review admin access list quarterly
  • Monitor MCP security advisories
  • Track new vulnerabilities
  • Update approval criteria as threats evolve
  • Participate in security training
  • Share learnings with other admins
  • 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)
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