Security

A virtual machine per sandbox. Not a container.

Every sandbox runs in its own Firecracker microVM with its own guest kernel. This page explains how that isolation works, what you control, what we consider in scope, and where the limits are.

Isolation layers

From your code, down to the shared host.

  1. Your codeUntrusted: runs as root in its own VM by default
    guest userspace
  2. Guest kernelA Linux kernel per sandbox, never the host's
    per VM
  3. FirecrackerMinimal VMM, run under its jailer
    per VM
  4. KVMHardware virtualisation in the CPU
    host kernel
  5. HostNamespace, tap device and thin disk per sandbox
    host
Isolation

Layer by layer, from your code to the host.

A compromised guest kernel is still inside a VM: escaping onto the host needs a bug in KVM or Firecracker. Containers share the host kernel; a microVM does not. Network reachability is a separate question, covered under the limits.

  • Separate disks. Each sandbox gets a copy-on-write LVM thin snapshot of its template, deleted when it is killed.
  • Separate networks. Each VM gets its own network namespace, tap device and bridge, and traffic between sandboxes is blocked.
  • Jailed VMM. On the managed service each Firecracker process runs under its jailer: its own chroot and PID and mount namespaces, as a shared unprivileged user.
What you control

Controls that do what they say.

Each one is described as it works today, including where it stops.

Network

Internet on or off

Base templates (python-3.11, node-20) start with internet off, and with internet: false the VM has no route out. Agent templates always have internet on today.

Allowlists

Hostname allowlists

Turn on the SNI proxy to let a sandbox reach only the HTTPS hostnames you list. It is opt-in and filters TLS on port 443 only.

Payloads

Payload encryption to the worker

Optional. Command, code and file read/write payloads are encrypted with AES-256-GCM (ECDH P-256 key agreement) between the SDK and the worker, which decrypts them.

Tokens

API tokens

Tokens start with omr_, are stored only as salted HMAC-SHA256 hashes, compared in constant time, and can be revoked at once. Sign-in is passwordless, with optional TOTP.

Files

Signed file links

Upload and download URLs are signed with HMAC-SHA256, bound to one sandbox and one path, and expire after 15 minutes.

Audit

Audit log

A hash-chained audit log of API calls: which token did what, and when. On in managed; on a self-hosted node, switched on in config.

no-network.ts
const sbx = await Sandbox.create({
  template: "python-3.11",
  internet: false,   // no route out of the VM
  timeout: 300,     // seconds, then it is torn down
})

When a sandbox ends

Kill it, or let the timeout run out. Either way the VM process is stopped, its network namespace is removed and its copy-on-write volume is deleted. If a step fails, the sandbox stays tracked and teardown is retried rather than silently forgotten.

Lifecycle in the API reference
Threat model

What we defend, and what we do not.

We assume the code inside a sandbox is hostile. The job is to keep it inside its VM and away from other accounts.

In scope

  • Escaping a sandbox to the host, or reaching another sandbox from inside one.
  • Reading or controlling another account's sandboxes, files, API tokens or vault credentials through the API.
  • Authentication or authorization bypass on api.omnirun.io, the dashboard, or the gateway.
  • Forging or replaying signed file URLs beyond their scope or expiry.
  • Bypassing the SNI egress proxy in a way not listed under the limits.

Out of scope

  • Anything code can do inside its own sandbox, including gaining root there. The boundary is the VM, not the guest user.
  • Outbound traffic from sandboxes that have internet access switched on.
  • The limits listed on this page.
  • Denial of service, volumetric testing, spam, and social engineering of staff or users.
  • Testing against other people's accounts or sandboxes. Stay inside your own.
Limits

What OmniRun does not do.

Security pages usually stop at the strengths. These are the things to know before you rely on us.

  • Not end-to-end encryption. Payloads are encrypted to the worker, which decrypts them to run your code, so its operator can read them. File paths, listings, streams and binary transfers are not covered, and there is no replay protection yet.
  • Default egress depends on the template. Agent templates (claude-code, codex, desktop and others) always have internet on; internet: false does not switch it off for them today. With internet on, egress is open unless you add the SNI proxy.
  • Host-level filtering is still being hardened. Filtering that stops a sandbox with internet on from reaching services on the host or on private network ranges has not been verified yet. Sandboxes with internet off have no route out.
  • Allowlists are hostname filtering, not a firewall. The SNI proxy checks the server name in the TLS handshake on port 443. Other ports are not filtered by it, and domain fronting can get past it. Treat it as a guard rail, not as a control against deliberate exfiltration.
  • Guest commands run as root by default. They can run as a non-root user when you ask for one. There is no privilege boundary inside a sandbox that you should rely on.
  • Hardware is shared. Sandboxes on one host share its CPUs and memory. A VM boundary is strong, but it does not remove every hardware side channel.
  • No compliance certifications. OmniRun has no SOC 2, ISO 27001 or HIPAA attestation. The managed service runs in Hetzner data centers in Finland (EU).
  • Self-hosted means self-patched. On your own box, the host kernel, KVM and Firecracker updates are yours to apply.
Disclosure

Found a vulnerability? Tell us first.

We aim to acknowledge reports within three business days and keep you updated until the issue is fixed. Give us reasonable time to fix it before you disclose it. We will not pursue research done in good faith within these rules.

Emailsecurity@omnirun.io
Please includeThe affected endpoint or component, steps to reproduce, and what an attacker gains
In scopeThe API, gateway, in-VM agent, omnictl, SDKs and the managed service. See the threat model.
Please do notTest against other people's accounts or sandboxes, access data that is not yours, or degrade the managed service

Read the code that isolates your code.

Everything on this page will be in the Apache-2.0 repository when the source opens. Or read the docs and talk to us about running it for your team in Finland.

Keep a sandbox offlineSandbox.create({ internet: false })Report a vulnerabilitysecurity@omnirun.io