Modern cloud architecture is facing a massive identity crisis. We are asking infrastructure to run workloads that software engineers a decade ago would have deemed hopelessly ill-advised. Third-party user plugins executing arbitrary code, autonomous AI agents calling APIs and compiling dynamic scripts on the fly, and densely packed multi-tenant clusters where direct competitors share the exact same physical silicon. To cope, the industry defaulted to the same old, traditional security primitives like Kubernetes namespaces, seccomp profiles, AppArmor rules, and in some cases, complex system call allowlists. But all these tools rely on the same outdated assumption that we can easily predict what a workload is going to do before it does it.
Namespaces are an organisational abstraction, not a security boundary. Every standard Docker container share a single Linux kernel. This is the ultimate single point of failure and the broadest attack surface in modern computing. A single container escape or kernel panic doesn't just crash a pod, it also has the blast radius to compromise every tenant on that same node. To avoid this, teams usually default to heavy, expensive alternatives like cluster-per-tenant sprawl, dated VM overhead that destroys margins, or strict syscall allowlists that break non-deterministic AI agents. Thankfully, Edera was built to eliminate this tradeoff.
Operating as a Type-1 hypervisor, Edera gives every workload its own isolated Linux kernel in a lightweight execution boundary called a Zone. It delivers VM-grade architectural isolation at bare-metal speed (<1% CPU overhead, 766ms startup time) with zero hardware virtualisation dependencies (VT-x) required. The focus of this blog post was to discuss how Edera redefines the core value drivers of modern infrastructure for the workloads that many operations teams simply call "too risky."
Multi-tenancy for Kubernetes
Kubernetes namespaces give you a false sense of security. They organise your workloads, but at the system level, every container on a node communicates directly with the host Linux kernel. When a vulnerability like a kernel privilege escalation hits, namespace boundaries evaporate. A container escape provides a direct line to every other tenant sharing that node. To avoid this shared-kernel threat, enterprise engineering teams traditionally resort to cluster-per-tenant architectures. While this solves the security problem, it introduces massive operational friction:
- Endless patching cycles
- Doubling or tripling cloud control planes
- Splintered monitoring and/or logging stacks
- Escalating cloud infrastructure bills that decimate gross margins
Edera eliminates the shared host kernel entirely. By deploying as a hardened runtime in just two lines of YAML, Edera wraps every Kubernetes pod in its own isolated Zone powered by a dedicated Linux kernel.
If a workload panics, only its specific Zone crashes. If a malicious process attempts a container escape, it hits a Type-1 hypervisor boundary with no host on the other side. Network traffic is similarly hardened: every workload receives a cryptographic identity via SPIFFE/SPIRE, paired with private networking that ensures packets never touch the host interface. The result is a 60% reduction in node sprawl and total immunity against shared-kernel CVEs. This design achieves true multi-tenant density on shared hardware without taking on shared risk.
Multi-tenancy for GPUs
GPUs are the most expensive, underutilised asset in the modern datacentre. The vast majority of enterprise GPU clusters operate at a dismal 20% to 30% resource utilisation. Inference workloads idle while waiting for requests, model development tasks consume full cards for basic interactive research, and multi-tenant sharing is routinely blocked by security and compliance teams. Why? Because traditional GPU sharing mechanisms (like MIG or process-level slicing) lack hard isolation boundaries. If two competing teams or customers share a single physical GPU, a driver-level exploit or memory leak in one application can crash the entire card or read sensitive model weights from adjacent memory.
Edera extends hypervisor-level isolation directly down to physical accelerator hardware, allowing organisations to securely partition GPUs into right-sized virtual GPUs (vGPUs) across multiple tenants. Edera allows teams to safely drive GPU utilisation from 20–30% up to 60–80% by co-locating dense inference models and fractional development environments on the same card.
In traditional systems, all containers must share the host’s exact GPU driver and kernel version. Edera allows different kernel versions to run per Zone. You can run legacy ML frameworks requiring older drivers alongside cutting-edge setups on the same physical server. Likewise, memory and compute partitions are isolated at the hypervisor boundary. If an ML job triggers a CUDA out-of-memory error or driver panic, it is contained inside its Zone without impacting neighbouring workloads on the GPU.
AI agent execution
AI agents are fundamentally changing software architecture. Unlike legacy microservices that execute predictable, pre-compiled code paths, autonomous agents are non-deterministic by nature. They write and run dynamic scripts, execute terminal commands, browse the web, parse unpredictable web inputs, and chain complex tools together in real time. This introduces a massive security dilemma. Traditional container security relies on predicting behaviour:
- system call allowlists block unexpected behaviours.
- seccomp profiles dictate the allowable system calls.
- AppArmor / SELinux restrict filesystem access based on known paths.
Attempting to enforce rigid system call allow-lists on an autonomous agent running tools like Claude Code, LangChain, CrewAI, or AutoGen will inevitably break the agent. But running agents with unrestricted host kernel access invites severe prompt injection, arbitrary code execution, and lateral network movement. Edera shifts this paradigm from restricting agents to rightfully containing them.
Instead of trying to predict every system call an agent might make, Edera grants the agent an isolated Zone with a complete, fully functional Linux kernel supporting 350+ standard system calls. The agent gets complete operational autonomy to compile code, invoke binaries, and manage processes. However, because the Zone is structurally isolated by Edera’s hypervisor, the blast radius of a compromised or rogue agent is mathematically bounded to exactly one workload.
With a rapid 766ms Zone startup time, developers can dynamically spin up an isolated environment for a single agent execution step and tear it down immediately after. This ends up delivering near-native speed without risking your host infrastructure.
Untrusted code execution
Whether processing customer-submitted Python scripts, executing webhooks, running third-party plugins, or compiling LLM-generated code snippets, running untrusted code is a core requirement for modern SaaS platforms. Historically, engineering teams faced three bad choices for untrusted code execution:
- The shared kernel in Docker and Kubernetes offered fast performance, but extreme security risk since a single kernel vulnerability can lead to an entire host takeover.
- The system call interception approach seen in gVisor worked. It's safe, but incurs heavy performance penalties (up to 59% build overhead) and frequent application breakages due to missing syscalls.
- The traditional MicroVM isolation method, as seen with Kata containers, provides a secure VM boundary, which is a significant improvement, but requires nested hardware virtualisation (VT-x), incurring high cold-start times (~2.5x slower) and blocking deployment on 93% of public cloud instances.
In this context, Edera eliminates the trade-off between performance, security, and cloud portability:
1) Near-native speeds:
Operates with less than 1% CPU overhead and somewhere around 5% build overhead.
Delivers up to 12x faster performance than gVisor under heavy network and I/O stress.
2) Support for over 350 syscalls:
Complete syscall compatibility means zero application debugging or allowlist maintenance.
The code runs exactly as you would expect it to run on bare metal.
3) Extensive cloud compatibility:
Because Edera does not require hardware VT-x extensions, it offers 93% cloud instance coverage.
Runs natively on standard public cloud VMs, bare-metal nodes, and edge devices alike.
Trust, compliance, and confidential computing (Cryptographic proof of isolation)
In highly regulated sectors such as fintech, healthcare, and the defence sector, security controls must be provable to auditors, auditors' tools, and prospective customers. Claiming that "our software is isolated by policy" no longer passes vendor risk assessments. Furthermore, traditional cloud security models protect data at rest and in transit, but leave data exposed in use inside host memory. While hardware-based Trusted Execution Environments (TEEs) and Confidential Computing solve parts of this puzzle, they often demand specialised hardware, proprietary SDKs, and significant application refactoring.
Every Edera Zone is assigned an immutable, cryptographic identity via SPIFFE/SPIRE. Security teams can generate verifiable cryptographic audit trails proving that workloads executed inside isolated, untrusted boundaries. TEEs (like AMD SEV or Intel SGX) protect workloads from a compromised host hypervisor. Edera protects the infrastructure and neighbouring tenants from a compromised workload. Together, Edera and TEEs provide complete, end-to-end confidential computing without requiring specialised hardware for every standard pod. Furthermore, Edera’s core architectural isolation primitives achieved zero critical findings during a comprehensive 4-week public security audit conducted by Trail of Bits.
Observability & tuning
A major downside of traditional virtualisation and sandboxing technologies is the "black box" effect. When you wrap a container inside a heavy VM, you frequently lose deep observability. Standard host-level agents (like eBPF probes, Prometheus exporters, or APMs) struggle to see inside the guest environment, forcing teams to inject monitoring sidecars into every single tenant container. This again increases the memory overhead and telemetry complexity.
Edera delivers enhanced runtime observability that gives platform operators deep, real-time visibility into workload behaviour without sacrificing security boundaries. See exactly what system resources, memory channels, and I/O operations every workload is consuming in real time from the hypervisor layer. Instead of drowning in thousands of noisy runtime alert logs ("Alert: suspicious /etc read attempt" from Falco), Edera’s structural isolation prevents lateral movement and privilege escalation at the boundary layer. Finally, track true CPU/RAM consumption per Zone to right-size multi-tenant pods, optimise GPU memory allocation, and eliminate waste across cloud fleets with total confidence.
My closing statement is this - the next decade of cloud computing will definitely belong to platform teams that are able to run complex, untrusted, and non-deterministic workloads safely at scale. Choosing between developer velocity, cloud spend margins, and foundational security is a false choice born from the legacy way of thinking when everyone relied on a shared-kernel architecture. By replacing the shared host kernels with cryptographically verified, hypervisor-isolated Zones, Edera lets you move fast, cut cloud spend, and run the next-gen AI workloads without the fear of unexpected behaviour.