Skip to main content

MCP Server Sandboxing

Plugged.in implements robust sandboxing for all STDIO MCP servers to ensure security and resource isolation. This guide covers the sandboxing architecture, configuration, and best practices.

Overview

Sandboxing is enabled by default for all STDIO MCP servers. Never disable sandboxing in production environments unless absolutely necessary.
Sandboxing provides:
  • Process Isolation: Each MCP server runs in its own isolated environment
  • Filesystem Protection: Restricted access to system files and directories
  • Resource Limits: CPU, memory, and I/O constraints
  • Network Control: Optional network isolation for untrusted servers
  • Privilege Dropping: Servers run with minimal privileges

Sandboxing Technologies

Bubblewrap (Primary)

Bubblewrap is the preferred sandboxing technology due to its lightweight nature and user-namespace support.
Features:
  • User namespace isolation (no root required)
  • Bind mount control for selective file access
  • Network namespace support
  • Resource limits via cgroups
  • Minimal performance overhead
Installation:

Firejail (Fallback)

Firejail provides SUID-based sandboxing with extensive security profiles. Features:
  • Extensive security profiles
  • AppArmor/SELinux integration
  • X11 sandboxing support
  • Network filtering capabilities
  • Comprehensive logging
Installation:

FUSE Requirements

Some applications require FUSE (Filesystem in Userspace) support:

Configuration

Environment Variables

Configure sandboxing behavior through environment variables:

Sandboxing Modes

Default and recommended mode

Implementation Details

Filesystem Isolation

The sandboxing system creates isolated filesystem views:

Resource Limits

Resource constraints applied to sandboxed processes:

Network Isolation

Control network access for sandboxed servers:
  • Servers can access external networks
  • Suitable for API-based MCP servers
  • Docker socket access allowed
  • No network access
  • Loopback interface only
  • Suitable for compute-only servers

Security Considerations

Privilege Escalation Prevention

  1. Drop All Capabilities: Remove all Linux capabilities by default
  2. No New Privileges: Prevent privilege escalation via setuid
  3. User Namespace: Run in unprivileged user namespace
  4. Seccomp Filtering: Restrict system calls

Directory Traversal Protection

OAuth and Authentication

Special handling for OAuth-enabled MCP servers:

Troubleshooting

Common Issues

Error: “bwrap: command not found”Solution:
Error: “Permission denied: /var/mcp-packages”Solution:
Error: “fusermount: fuse device not found”Solution:
Error: “Cannot connect to API endpoint”Solution:

Debug Mode

Enable debug logging for sandboxing:

Testing Sandboxing

Verify sandboxing is working:

Best Practices

1

Always Use Sandboxing

Never disable sandboxing in production. If a server requires it, investigate alternatives.
2

Principle of Least Privilege

Grant minimal permissions required for functionality.
3

Regular Updates

Keep sandboxing tools updated for latest security fixes.
4

Monitor Resource Usage

Track CPU, memory, and I/O usage to tune limits.
5

Test Thoroughly

Test MCP servers in sandbox before production deployment.
6

Document Exceptions

If sandboxing must be disabled, document the reason and compensating controls.

Performance Impact

Sandboxing overhead is minimal:

Platform-Specific Notes

Docker Containers

For Docker deployments:

Kubernetes

For Kubernetes deployments:

Support

For sandboxing assistance: