AI Agent Sandboxing

AI Agents are the future.

Run them like it with our production-ready sandbox.

See How It Works

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.

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.

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.

1. Why can't seccomp/AppArmor sandbox agents?
   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.

2. How is Edera different from process sandboxes?
   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.

3. What does Edera protect against?
   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.

4. Which AI agent frameworks does Edera support?
   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.

5. How does gVisor compare to Edera for AI agents?
   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.

6. Why not Kata Containers for AI agents?
   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.

7. How can I learn more about the Trail of Bits public audit of Edera?
   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."

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.

• Blast Radius: 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.
• Non-deterministic Behavior: 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.
• Process-level Sandbox: 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.
• Trusted Computing Base (TCB): 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).
• Type-1 hypervisor: 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.
• Zone: 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.