Skip to main content

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.

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 →