Untrusted Code Execution Without the Risk | Edera

Untrusted Code Execution

Every integration you run is code you didn't write. Make sure it can't reach anything you care about.

See How It Works

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.

93%

Instance Coverage

No virtualization extensions required

5%

Build Overhead

gVisor: 59% slower. Kata: 52% slower

18ms

Near-Native Performance

12x faster than gVisor, Apache Bench

350+

Syscall Support

Real kernel per zone, no syscall gaps

0

Critical Findings

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.

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.

  1. Can containers safely run untrusted code?
    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.

  2. What's the difference between a sandbox and isolation?
    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.

  3. How does Edera differ from gVisor and Kata?
    gVisor covers 78% of syscalls and keeps the host kernel in trust boundary. Kata requires hardware virtualization unavailable on 93% of cloud instances. Edera needs neither — real kernel per zone, any instance type.

  4. How do you run AI agent code safely?
    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.

  5. Do container images need changes for Edera?
    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.

  6. How does Edera monitor untrusted workloads?
    Edera integrates with Falco via eBPF, streaming syscall events from each zone's kernel to a host instance. Standard rules evaluate process execution, file access, and network activity — without breaking isolation.

  7. What's the performance cost of Edera vs. containers?
    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.

  8. 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."

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.