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 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.
- User namespace isolation (no root required)
- Bind mount control for selective file access
- Network namespace support
- Resource limits via cgroups
- Minimal performance overhead
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
FUSE Requirements
Some applications require FUSE (Filesystem in Userspace) support:Configuration
Environment Variables
Configure sandboxing behavior through environment variables:Sandboxing Modes
- Bubblewrap Mode
- Firejail Mode
- No Sandboxing
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:Full Network Access (Default)
Full Network Access (Default)
- Servers can access external networks
- Suitable for API-based MCP servers
- Docker socket access allowed
Network Isolation
Network Isolation
- No network access
- Loopback interface only
- Suitable for compute-only servers
Custom Network Rules
Custom Network Rules
Security Considerations
Privilege Escalation Prevention
- Drop All Capabilities: Remove all Linux capabilities by default
- No New Privileges: Prevent privilege escalation via setuid
- User Namespace: Run in unprivileged user namespace
- Seccomp Filtering: Restrict system calls
Directory Traversal Protection
OAuth and Authentication
Special handling for OAuth-enabled MCP servers:Troubleshooting
Common Issues
Sandbox tools not found
Sandbox tools not found
Error: “bwrap: command not found”Solution:
Permission denied errors
Permission denied errors
Error: “Permission denied: /var/mcp-packages”Solution:
FUSE not available
FUSE not available
Error: “fusermount: fuse device not found”Solution:
Network isolation too restrictive
Network isolation too restrictive
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:- Documentation: docs.plugged.in
- Security Issues: security@plugged.in
- GitHub Issues: Report issues

