Skip to Content
GuidesRunners Security Model

Runners Security Model

Managed runners operate within a defense-in-depth security model with multiple isolation layers.

Isolation Layers

1. Compute Isolation

Each runner session runs in an isolated E2B cloud sandbox — a micro-VM with its own filesystem, network namespace, and process space. Sandboxes are ephemeral and destroyed on session termination.

2. Organization Isolation

Runners are scoped to organizations. API keys authenticate to a specific org, and all runner operations enforce org_id matching. No cross-org access is possible.

3. Tool Profile Restrictions

ProfileFilesystemNetworkSystem ToolsUse Case
lockedRead-only (except /tmp)NoneMinimalSafe code execution
web_automationRead-writeHTTP/HTTPS onlyBrowser, curlWeb tasks
full_vm_toolsFullFullAllSystem admin

4. Egress Policies

Configurable network egress rules control which external domains a runner can reach. Policies are enforced at the network level within the sandbox.

{ "default_action": "deny", "allowed_domains": ["api.openai.com", "*.github.com"], "denied_domains": ["*.internal.company.com"], "max_request_size_bytes": 10485760 }

5. PII Scanning

Command inputs and outputs are scanned for PII patterns (emails, SSNs, API keys, credit cards). Findings are logged to the audit trail and can trigger policy actions (warn, block, require approval).

6. RBAC + HITL Approvals

Three gateway roles control runner access:

  • Viewer: Read-only access to runner state and events
  • Operator: Can create runners, start/stop sessions, execute commands
  • Admin: Full access including terminate and policy management

High-risk operations (e.g., full_vm_tools profile, large file downloads) can require human-in-the-loop approval before execution.

Audit Trail

Every runner action generates an immutable audit event:

  • Runner creation and state transitions
  • Session start/stop/expire
  • Command execution with argv and exit codes
  • Policy evaluations and denials
  • HITL approval decisions

Events are stored in MongoDB and accessible via the /events API endpoint and the dashboard event timeline.

Best Practices

  1. Use locked profile by default — only escalate when needed
  2. Set strict TTLs — shorter sessions reduce exposure window
  3. Configure egress policies — whitelist only required domains
  4. Enable PII scanning — especially for customer-facing agents
  5. Review audit trails — regular compliance checks via dashboard
  6. Use HITL for sensitive ops — require approval for full_vm_tools