AI Agent Sandboxing
AI Agents are the future.
Run them like it with our production-ready sandbox.
AI Agents are a competitive advantage, and Edera is what lets you treat them like one. Teams that figure out how to run them safely at scale will move faster than everyone else. Teams that don't will spend the next year explaining incidents.
The bottleneck isn't capability. AI Agents can already call APIs, write code, spin up processes, browse the web, and chain tools together in ways nobody anticipated. The bottleneck is infrastructure that was never designed for workloads this non-deterministic. Seccomp profiles, AppArmor policies, syscall allowlists — these tools ask you to enumerate what your agent will do before it does it. That's not a security model for agents. That's a way to make agents useless.
Edera doesn't restrict agents. It contains them. Every agent runs in its own isolated environment with a dedicated Linux kernel — any syscall, any tool, any framework, full autonomy. A compromised agent stays in its zone. Your other agents keep running. Your host is unreachable. You don't need to predict what the agent will do to know the blast radius stays at one. Ship faster. Security doesn't have to be the thing that slows you down.
Claude Code, LangChain, CrewAI, AutoGen
Spin up, tear down, repeat
VM isolation at bare-metal speed
Trail of Bits, 4-week public audit
Existing images, no code changes
Life's a Beach
Let's Play in the Sand
How process-level sandboxes fail for non-deterministic workloads, why the host kernel can't be in your trust boundary, and what fault isolation actually means for AI agents running in production.
RELATED READS
MCP Vulnerability Exposes AI Dev Security Gaps
AI Agent Sandboxing FAQ
Common questions about sandboxing AI agents in Kubernetes: why seccomp and AppArmor can't contain non-deterministic behavior, how Edera compares to gVisor, Kata Containers, and process-level sandboxes, and what changes when every agent runs in its own kernel.
These tools require enumerating allowed behavior in advance. Agents are non-deterministic — same prompt, different syscalls each run. You can't policy-gate what you can't predict. Edera isolates at the hypervisor, not the syscall layer.
Process sandboxes (Landlock, Seatbelt, seccomp) depend on the host kernel for enforcement. A kernel vulnerability breaks the sandbox — Dirty Pipe, Leaky Vessels, cr8escape. Edera gives each agent its own kernel. Kernel exploit stays zone-local.
Edera prevents container escapes, lateral movement between agents, kernel privilege escalation, and host compromise. It doesn't cover credential misuse or network exfiltration — scope those with per-agent credentials and network policies.
Any framework that runs in a container. Claude Code, Gemini, MCP servers, LangChain, CrewAI, AutoGen, and custom agents all work unmodified. Edera operates at the Kubernetes runtime layer — no SDK, no agent integration, no code changes.
gVisor supports 78% of Linux syscalls — the 22% gap breaks agents that install packages, compile code, or use system tools. Nginx: 220ms vs. Edera's 18ms. gVisor doesn't eliminate the shared host kernel. Edera runs a full kernel per agent.
Kata needs hardware virtualization extensions — on most cloud instances, that's VMs inside VMs. Startup: 1,934ms vs. Edera's 766ms. For rapid agent spin-up/tear-down, that latency compounds. Edera uses paravirtualization, any instance type.
The report on the Trail of Bits penetration test is available in Edera's Trust Center. You can also read more about the process in our blog post on the audit. In their executive summary, Trail of Bits concluded: "The security posture of Edera and its surrounding infrastructure is generally robust, with no medium or high severity findings identified in this audit."
Interested in general Edera FAQs?
AI Agent Sandboxing Glossary
Key terms for understanding AI agent containment — from non-deterministic behavior and blast radius to zone architecture, process-level sandboxes, and trusted computing boundaries.
Running AI agents in contained environments to limit blast radius. Most solutions use process-level restrictions on a shared kernel. Edera provides VM-level isolation with per-agent kernels.
The scope of impact from a failure or breach. A kernel panic in standard Kubernetes affects every container on the node. In Edera, the blast radius is one zone — one workload.
When the same inputs produce different outputs and actions. Agents break security models that depend on predicting valid behavior, like syscall allowlists and seccomp profiles.
Containment using OS features (Landlock, Seatbelt, seccomp) where the host kernel enforces restrictions. A kernel vulnerability breaks the sandbox. Suitable for dev, not production isolation.
All hardware and software components critical to system security. Smaller TCB means less to trust and audit. Edera's TCB: Xen microkernel. Containers trust the entire Linux kernel (30M+ lines of code).
A hypervisor running directly on hardware, beneath the OS, with no host OS in the trust boundary. Edera's is based on Xen, written in MISRA C. A Type-1 hypervisor provides stronger isolation than Type-2 (hosted) hypervisors.
An isolated environment giving each Kubernetes pod its own Linux kernel, backed by a hypervisor-managed VM. Kernel failures and escapes cannot cross zone boundaries.
Book a Meeting
Ready to move fast?
We'll help you safely ship AI agents in production at scale.