Every message deserves
its own kernel.
Your AI agent runs inside a Firecracker microVM — the same technology that powers AWS Lambda. Hardware-level isolation means no other user can ever access your data, even in theory.
One VM per agent. No exceptions.
Most hosting platforms run your AI agent in a container — a lightweight process that shares the operating system kernel with every other container on the same machine. If one container is compromised, an attacker with a kernel exploit can reach all others.
OmniClaw takes a different approach. Each agent boots inside a Firecracker microVM: a minimal virtual machine with its own Linux kernel, its own memory space, and its own network stack. The host machine cannot see inside the VM, and the VM cannot see outside its boundary.
Firecracker was built by Amazon to isolate AWS Lambda functions from each other. The Firecracker project cites boot times of around 125ms and under 5 MiB of memory overhead per microVM. We use the same technology to give every OmniClaw agent the isolation that used to require a dedicated server.
What we protect against.
Container escapes
In shared hosting, a vulnerability in one container can expose all others on the same machine. MicroVMs eliminate this by placing a hardware boundary between tenants.
Credential leaks
API keys stored as environment variables can be logged, dumped, or exfiltrated. Our vault stores them encrypted and writes them into a sandbox only when it requests them. Code in that sandbox can read them, so store only the keys your agent needs.
Cross-tenant data access
Each VM has its own filesystem, network namespace, and process tree. There is no shared state between agents — not even a shared /tmp directory.
How OmniClaw compares.
| Feature | OmniClaw | Container hosting | Self-hosted |
|---|---|---|---|
| Isolation level | Dedicated Linux kernel (hardware boundary) | Shared kernel (process boundary) | Full machine (you manage it) |
| Breakout risk | Requires hypervisor exploit | Kernel exploit sufficient | Depends on your setup |
| Credential storage | Encrypted vault, written into the sandbox on request | Environment variables or secrets manager | Your responsibility |
| Network policy | Own network namespace per VM; traffic between VMs blocked | Open by default | Your responsibility |
| Data residency | EU (Finland) | Varies by provider | Wherever you host |
| Auto-destroy | 24h TTL, zero leftover state | Persistent by default | Manual cleanup |
| Setup effort | 60 seconds, no code | Docker + K8s knowledge needed | Full server administration |
Hosted in the EU.
OmniRun infrastructure runs on servers in the EU (Finland). Your agent's VM and the credential vault are hosted there.
We do not use US-based cloud providers for compute or storage. Message content you send to an LLM is processed by the provider you choose (e.g. OpenAI, Anthropic, Google), which may be outside the EU.
| Region | FI · Helsinki, Finland |
|---|---|
| Hosted there | Your agent's VM and the credential vault |
| LLM processing | At the provider you choose, which may be outside the EU |
Encrypted at rest, delivered on request.
When you store an API key in the OmniClaw vault, it is encrypted at rest with AES-256-GCM, under a key held by the OmniRun gateway, in a per-account vault sandbox with internet off.
When a sandbox requests vault credentials, the gateway decrypts them and writes them into that sandbox as an environment file, which the agent loads into the environment of the commands it runs. Code inside that sandbox can read those keys, so store only the keys your agent needs.
The vault is write-only from the dashboard. After storing a key, you can update or delete it, but the API only ever returns key names, not values.
Security without complexity.
Connect WhatsApp and your agent runs in its own isolated VM. No infrastructure to configure.