Orpheus is designed for running trusted internal code in isolated containers. This document explains what security features are implemented and what the limitations are.

✅ 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)

❌ 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

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 platforms

• Current security is insufficient for arbitrary user code
• Network namespace isolation needed
• See roadmap for v0.2.0 enhancements

⚠️ Processing regulated data (HIPAA/PCI)

• Additional compliance features required
• Audit logging and encryption needed
• See roadmap for v0.3.0 compliance features

⚠️ Executing untrusted user-submitted code

• Current isolation is good but not maximum
• Consider gVisor or Firecracker for untrusted code
• See roadmap for v0.3.0 enhanced isolation

Default action: Block (SCMP_ACT_ERRNO)

Allowed syscalls (~211):

• File I/O: read, write, open, close, stat, etc.
• Memory: mmap, munmap, mprotect, brk
• Process: fork, clone, execve, exit, wait4
• Networking: socket, connect, bind, listen, send, recv
• Signals: rt_sigaction, rt_sigprocmask, kill

Blocked syscalls (~330+):

• Administrative: mount, umount2, reboot, sethostname
• Kernel modules: init_module, delete_module, finit_module
• Debugging: ptrace, process_vm_readv, process_vm_writev
• Capabilities: capset, capget
• Time manipulation: clock_settime, settimeofday
• Namespace manipulation: unshare, setns
• ASLR bypass: personality
• Device creation: mknod

Compatibility: Tested with Python 3.x, Node.js 18+, Go 1.20+, Rust 1.70+

Note: Agents cannot execute binaries from /tmp or /proc, only from /agent (rootfs).

These paths appear as empty read-only files:

• /proc/kcore - Kernel memory dump
• /proc/kallsyms - Kernel symbols
• /proc/sys/kernel/core_pattern - Core dump handler (can execute commands)
• /proc/sys/kernel/modprobe - Module loader path
• /sys/firmware - BIOS/UEFI information
• /sys/kernel/debug - Kernel debug interfaces

These paths are visible but cannot be modified:

• /proc/sys - Kernel parameters
• /sys - System interfaces

✅ Seccomp profile (Docker default) ✅ NoNewPrivileges flag ✅ Mount hardening (nosuid, nodev, noexec) ✅ /proc and /sys masking ✅ Timeout enforcement (60s default) ✅ Crash recovery

• Network namespace isolation
• Egress filtering (allowlist for LLM APIs)
• User namespace remapping
• Enhanced audit logging

• gVisor integration (optional, for untrusted code)
• Compliance certifications (SOC 2, HIPAA)
• Multi-tenant isolation hardening

# Inspect OCI config
cat /tmp/orpheus-bundles/*/config.json | jq '.linux.seccomp'

# Should show: DefaultAction: "SCMP_ACT_ERRNO"

cat /tmp/orpheus-bundles/*/config.json | jq '.process.noNewPrivileges'

# Should show: true

# Try to mount (should fail with EPERM)
orpheus exec my-agent --cmd "python3 -c 'import os; os.mount(\"/dev/sda\", \"/mnt\", \"ext4\")'"

# Expected: OSError: [Errno 1] Operation not permitted

Recommendation: Keep runc and kernel updated to latest stable versions.

We take security seriously. If you discover a vulnerability:

Email: security@orpheus.run

Response SLA: 48 hours

PGP Key: Available at https://orpheus.run/security.asc

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)

# Update Orpheus
git pull origin main
make build
sudo systemctl restart orpheusd

# Update runc
runc --version  # Should be 1.1.12 or newer

# 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

# Check for failed tasks (potential exploit attempts)
orpheus execlog list my-agent --state FAILED | grep -i "permission\|syscall"

# Monitor metrics for unusual patterns
curl http://localhost:7777/metrics | grep orpheus_task_

• 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)

For trusted code: Yes. The security posture is comparable to Docker default and suitable for internal tools.

For untrusted code: Not yet. Wait for v0.2.0 with network namespace isolation.

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.

No. Security features are always enabled and cannot be disabled. The performance overhead is minimal (<2% CPU).

Check logs for "permission denied" or "operation not permitted" errors:

orpheus logs my-agent | grep -i "permission\|permitted"

If a syscall you need is blocked, file an issue at https://github.com/orpheus-ai/orpheus/issues

Comparison:

• Docker default: 75/100
• Kubernetes default: 72/100
• gVisor: 95/100
• Firecracker: 98/100

Last Updated: 2026-01-27 Version: aurora-0.1.2