Skip to main content
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
Multi-tenant SaaS platformsCurrent 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 codeCurrent 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 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

# 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

# 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

# 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: 
sudo journalctl -u orpheusd | grep my-agent | grep -i "permission\|permitted"
If a syscall you need is blocked, file an issue on GitHub.

Troubleshooting

Security-related errors →