Security
Agents run code nobody has reviewed. We assume every sandbox is hostile and isolate it with hardware virtualization, not a shared kernel. This page explains the model and is upfront about what is still missing.
Each sandbox is a Firecracker microVM with its own Linux kernel on KVM. A kernel exploit inside the guest compromises the guest, not the host or its neighbours. Firecracker exposes only a handful of virtio devices, keeping the attack surface small.
Every Firecracker process is started by the jailer: a chroot, an unprivileged user (never root on the host), a seccomp filter restricting syscalls, and cgroups capping CPU and memory so one VM cannot starve another.
Each VM gets its own network namespace and tap device. VMs cannot reach the host's control API or each other. Traffic leaves through our edge gateway over WireGuard tunnels.
The host talks to the in-VM agent (exec, files, screenshots) only over vsock, not over the network. There is no SSH daemon listening on a public IP: SSH goes through an authenticated gateway.
Desktop viewer links are signed, expire (10 minutes by default), can be read-only and can be revoked. The VNC port is never exposed without a valid token. Event webhooks are HMAC-signed so you can verify they came from us.
API keys carry scopes, so a key used by an agent can be limited to what it needs. Spend limits cap the damage of a leaked key or a runaway loop.
Data location
Sandboxes, disks and snapshots run and are stored on dedicated servers in the EU: machines we operate ourselves and machines we rent from an EU hosting provider. We do not run regions outside the EU today. Servers are dedicated machines, not shared cloud VMs.
Free accounts are limited by plan quotas (2 concurrent VMs and a one-time allowance of active hours). Account verification at sign-up is not built yet. Port 25 is blocked for every VM, and outbound scanning, mail floods and traffic floods are detected from network counters and throttled, paused or suspended automatically. What is prohibited is listed in our acceptable use policy. Egress allowlists, which let you restrict where a VM can connect, are planned. We do not support anti-bot evasion, CAPTCHA solving or residential IPs.
Honest status
We are a private-beta product. If your procurement process needs any of these today, we are probably not the right choice yet.
| Item | Status |
|---|---|
| SOC 2 report | Not yet. Planned for year two. We will not claim it before an auditor has issued a report. |
| SSO and audit logs | Not yet. On the roadmap for enterprise customers. |
| Account verification at sign-up | Not yet. Free accounts currently rely on plan quotas and automatic abuse detection. |
| Egress allowlist | Planned for the beta, not shipped. |
| HIPAA, ISO 27001, other certifications | None. |
| Self-hosting | Not yet. Open-sourcing the core with a self-host option is on the roadmap. BYOC is available on Enterprise contracts. |
| Regions outside the EU | Not yet. |
| Independent penetration test | Not yet published. VM escape and cross-tenant network tests are part of our acceptance criteria. |
Email security@dormo.dev (also listed in /.well-known/security.txt) with details and steps to reproduce. We will acknowledge your report and keep you updated while we fix it. Please do not access other users' data or degrade the service while testing. We do not run a paid bug bounty yet.