> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orpheus.run/llms.txt
> Use this file to discover all available pages before exploring further.
# Security Model
> Understanding Orpheus container isolation and security features
Orpheus is designed for running **trusted internal code** in isolated containers. This document explains what security features are implemented and what the limitations are.
## Current Security Posture
### What Orpheus Protects Against
✅ **Container Escape Prevention**
* Seccomp syscall filtering (blocks 330+ dangerous syscalls including mount, ptrace, kernel modules)
* All Linux capabilities dropped (no CAP\_SYS\_ADMIN, CAP\_NET\_RAW, etc.)
* Critical paths masked (/proc/sys/kernel/core\_pattern, /proc/kallsyms, etc.)
✅ **Privilege Escalation Prevention**
* NoNewPrivileges flag blocks setuid/setgid privilege escalation
* Non-root execution (UID 1000, GID 1000)
* Mount options: nosuid on all mounts
✅ **Code Execution Restriction**
* noexec on /tmp, /proc, /dev (cannot execute binaries from writable mounts)
* Read-only /proc/sys and /sys (cannot modify kernel parameters)
✅ **Resource Exhaustion Protection**
* Memory limits (default: 512MB, configurable)
* PID limits (256 processes/threads max)
* Timeout enforcement (default: 60s, configurable)
✅ **Process Isolation**
* Separate PID namespace (cannot see host processes)
* Separate mount namespace (filesystem isolation)
* Separate IPC namespace (shared memory isolation)
* Separate UTS namespace (hostname isolation)
***
### What Orpheus Does NOT Protect Against
❌ **Network-Level Attacks**
* Containers share host network namespace (design decision for LLM API access)
* No egress filtering (agents can make arbitrary network requests)
* No inter-container network isolation
* **Mitigation**: Deploy on trusted networks, use firewall rules
❌ **User Namespace Remapping**
* Container root (UID 0) maps to host UID 1000 (non-root but not remapped)
* If container escape occurs, attacker has host UID 1000 permissions
* **Mitigation**: Non-root UID + seccomp + NoNewPrivileges provide defense-in-depth
❌ **Supply Chain Attacks**
* Orpheus does not scan agent dependencies for vulnerabilities
* Agent code and dependencies are user-controlled
* **Mitigation**: Users should vet their own code and dependencies
❌ **Data Exfiltration**
* Agents have full network access
* No DLP or egress monitoring
* **Mitigation**: Trust agent code, monitor network traffic externally
***
## Threat Model
### Intended Use Case: Trusted Code
Orpheus is designed for scenarios where:
* You control the agent code being deployed
* Agents are internal tools, not user-submitted code
* Single-tenant deployments (one organization per instance)
**Example safe use cases:**
* Internal automation agents
* Development and testing environments
* Proof-of-concept and demo applications
* AI agents you wrote and reviewed
### NOT Recommended For (Yet)
**Multi-tenant SaaS platforms**
Current security is insufficient for arbitrary user code. Network namespace isolation needed.
**Processing regulated data (HIPAA/PCI)**
Additional compliance features required including audit logging and encryption.
**Executing untrusted user-submitted code**
Current isolation is good but not maximum. Consider gVisor or Firecracker for untrusted code.
***
## Security Implementation
**Seccomp Filtering**: Blocks 330+ dangerous syscalls (mount, ptrace, kernel modules, etc.). Allows standard operations (file I/O, networking, process management). Tested with Python, Node.js, Go, and Rust.
**Mount Security**: Execution blocked on /tmp, /dev, /proc. Only /agent (rootfs) can execute binaries. /workspace is data-only.
**Masked Paths**: Critical kernel interfaces (/proc/kcore, /proc/kallsyms, core\_pattern) appear as empty read-only files.
***
## Reporting Security Vulnerabilities
We take security seriously. If you discover a vulnerability:
**Email**: [security@orpheus.run](mailto:security@orpheus.run)
**Response SLA**: 48 hours
**What to include**:
* Description of the vulnerability
* Steps to reproduce
* Impact assessment
* Suggested fix (if any)
**Disclosure policy**: We follow coordinated disclosure. We will:
1. Acknowledge receipt within 48 hours
2. Validate and investigate (1-7 days)
3. Develop and test fix (1-14 days)
4. Release patch and security advisory
5. Credit reporter (if desired)
***
## Best Practices for Secure Deployment
### 1. Keep Software Updated
```bash theme={null}
# Update Orpheus
git pull origin main
make build
sudo systemctl restart orpheusd
# Update runc
runc --version # Should be 1.1.12 or newer
```
### 2. Limit Network Access
```bash theme={null}
# Use firewall to restrict outbound traffic
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT # HTTPS only
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT # HTTP
iptables -A OUTPUT -j DROP # Block everything else
```
### 3. Monitor for Anomalies
```bash theme={null}
# Check for failed tasks (potential exploit attempts)
orpheus execlog list my-agent --status FAILED | grep -i "permission\|syscall"
# Monitor metrics for unusual patterns
curl http://localhost:7777/metrics | grep orpheus_task_
```
### 4. Run on Dedicated Infrastructure
* Use separate machines for Orpheus (not shared with critical services)
* Isolate agent workloads from production databases
* Use separate API keys for agents (not production keys)
***
## FAQ
### Is Orpheus safe for production?
**For trusted code**: Yes. The security posture is comparable to Docker default and suitable for internal tools.
**For untrusted code**: Not yet. Enhanced isolation features coming in future releases.
### What happens if an agent escapes the container?
The attacker would have:
* Host UID 1000 permissions (non-root)
* No Linux capabilities
* Limited syscall access (seccomp blocks most)
* Access to host network
**Blast radius**: Limited to files owned by UID 1000 and network access.
### Can I disable security features for performance?
No. Security features are always enabled and cannot be disabled. The performance overhead is minimal (under 2% CPU).
### How do I know if my agent code is blocked by seccomp?
Check logs for "permission denied" or "operation not permitted" errors:
```bash theme={null}
sudo journalctl -u orpheusd | grep my-agent | grep -i "permission\|permitted"
```
If a syscall you need is blocked, file an issue on GitHub.
***
Security-related errors →