Untrusted Code Execution
Every integration you run is code you didn't write. Make sure it can't reach anything you care about.
The moment you let a customer run their own code, whether human or AI-generated, on your infrastructure, you've handed them a potential path to everything else. Integrations, plugins, user-submitted workloads – each one is untrusted code sharing a kernel with every other tenant, every internal service, every piece of data you're responsible for.
The standard fix is a sandbox. Sandboxes work until they don't: syscall filters break workloads that need calls outside the approved list. VM-based isolation requires hardware virtualization that most cloud instances don't support. You end up choosing between what your customers can actually run, how secure it is, and where you're allowed to deploy it.
Edera removes the tradeoff. Every workload runs in its own isolated environment with a complete Linux kernel – all 350+ syscalls available, no allowlist to maintain, no compatibility gap to debug. Isolation comes from the hypervisor boundary, not a policy someone has to keep current. Customer code runs fully capable. Your kernel stays out of reach. Two lines of YAML to deploy, existing images unchanged.
No virtualization extensions required
gVisor: 59% slower. Kata: 52% slower
12x faster than gVisor, Apache Bench
Real kernel per zone, no syscall gaps
Trail of Bits, 4-week public audit
Untrusted Code Execution Resources
Untrusted code execution isn't a new problem — but the scale has changed. These pieces cover the business case for isolation, the real-world consequences of shared kernels, and how Edera compares to the alternatives you're already evaluating.
RELATED READS
Why Cloud Data Warehouses Must Run Untrusted Code in Isolation
Securing Agentic AI Systems with Hardened Runtime Isolation
MCP Vulnerability Exposes AI Dev Security Gaps
When "Virtual" Doesn't Mean "Secure": The False Promise of Namespace-Based Isolation
The RCE-cipe for Platform Security: Isolation Without Compromise
Containers That Actually Contain: A New Era in Kubernetes Trust Boundaries
Running Untrusted Code FAQ
Common questions about running untrusted workloads in Kubernetes — how Edera compares to gVisor, Kata Containers, and Firecracker, what full syscall compatibility means in practice, and why hypervisor isolation holds where sandboxes fail.
Not with a standard runtime. Linux containers share the host kernel — a vulnerability in one container is a path to the host and every other tenant. Real isolation requires a separate kernel per workload.
A sandbox restricts code on a shared kernel — a kernel exploit breaks through it. True isolation gives each workload its own kernel behind a hypervisor. Edera's blast radius is one zone: no host access, no lateral movement.
AI agents are non-deterministic — you can't write syscall allowlists for code that doesn't exist yet. Edera gives each agent its own kernel. Any syscall, any framework, any tool. Blast radius stays at one zone.
No. Existing images run unmodified. Add runtimeClassName and a kernel annotation to the pod spec. No recompilation, no syscall allowlist, no special base images. The workload doesn't know it's in a zone.
Near-native. CPU: 0.9% overhead vs. Docker. Memory: 0–7% faster. Nginx: 18ms vs. Docker's 15ms. Kernel builds: 5% slower. Published benchmarks at arXiv:2501.04580. Real kernel per zone, not syscall emulation.
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?
Trust Our Untrusted Glossary
Key terms for understanding syscall compatibility, kernel isolation, and trusted computing boundaries: from zone architecture and paravirtualization to CRI integration and driver isolation.
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.
The Kubernetes API that runtimes implement to integrate with the kubelet. Edera implements CRI — drop-in replacement, no changes to orchestration, CI/CD, or deployment workflows.
An attack exploiting a kernel bug to break out of a container and reach the host. Examples: Dirty Pipe, Leaky Vessels, CVE-2025-23266, cr8escape. Edera eliminates this class — no shared kernel to escape to.
Separating hardware drivers (GPU, network, storage) into isolated zones so driver vulnerabilities can't reach the hypervisor or other workloads. Unique to Edera among container runtimes.
When an attacker pivots from a compromised container to other workloads or the host. Possible on shared-kernel Kubernetes. Architecturally prevented in Edera — zones share no kernel to traverse.
A technique where the guest OS uses optimized hypercalls to the hypervisor instead of emulated hardware. Edera's PV mode runs at near-native speed without virtualization extensions.
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 trust the untrusted?
Let us help heal your trust issues...at least with your code base.