Edera Is Closing the GPU Security Gap for Autonomous AI

The friction between high-performance AI and traditional security boundaries is emerging as a major challenge in open-source development.

The software industry views agentic AI sandboxing as the answer to safely deploying autonomous systems. However, current approaches are fundamentally incomplete and fail to work when businesses run them at scale in production.

Alex Zenla, founder and CTO of cloud-native security firm Edera, sees this situation as the missing piece of the story about the shift from AI experimentation to real-world deployment. Edera is taking a different approach to securing open-source AI environments.

While others are bolting sandboxing onto AI agents as an afterthought, Edera has built a container-native, hypervisor-based isolation layer that delivers the same security guarantees and scales across multi-tenant, GPU-heavy infrastructure. The company’s approach assumes systems will be compromised and enforces isolation at the runtime level with near-zero overhead.

Edera is partnering with next-gen cloud providers and AI infra teams on how to safely operationalize AI without introducing catastrophic risk.

“What we’ve built is what we call a hardened runtime — isolation that assumes compromise from the start — so that when an agent does something unexpected, the blast radius is already contained,” Zenla told LinuxInsider.

Fixing Userspace Isolation Limits

Most current AI sandboxing relies on userspace isolation or basic containers. This approach fails when an agent has high-level permissions or access to sensitive toolsets.

Zenla explained that userspace and basic container isolation are predicated on Linux kernel primitives — namespaces, cgroups, LSMs. A critical bug in the Linux kernel can undermine process and container isolation, as well as any other container runtime defenses such as eBPF, seccomp, and AppArmor.

“Agents are very capable of finding bugs. If you ask an agent to break out of a container, it can find the bugs to do it,” she said.

To prove this point, Zenla cited a SandboxEscapeBench paper test of nine frontier large language models (LLMs) against 18 container escape scenarios. Claude Opus 4.5 and GPT-5 each escaped containers roughly half the time in controlled test environments. In common misconfigurations such as exposed Docker sockets, privileged containers, and writable host mounts, frontier models achieved a 100% escape rate.

Frontier LLMs are the most capable, cutting-edge AI models available today. Massive scale and general-purpose capabilities in reasoning, coding, and multimodal understanding characterize their performance.

Where Sandboxing Breaks at Scale

A common failure scenario occurs when a developer tries to move a sandboxed AI agent from a single-user experiment to a production environment with thousands of concurrent, multi-tenant sessions. In production, multi-tenant environments rely on the Linux kernel as a security boundary between tenants.

“Every agent shares the same kernel, so at thousands of concurrent sessions, every co-tenant becomes another attacker against the same kernel,” Zenla added.

The so-called key to the security kingdom lives in production in a container’s — and therefore the Linux kernel’s — memory, she explained.

“A single bug exploited in the shared kernel has a blast radius that affects every secret, encryption key, and customer data across an entire node. Often, those secrets lead to a takeover of the entire cluster environment,” Zenla warned.

Organizations running at scale need continuous compute delivery. That capability requires running inference workloads uninterrupted, even when an agent is compromised.

“That’s impossible when your security boundary is the shared kernel,” she said.

This limitation becomes even more pronounced in GPU-heavy environments. GPU (graphics processing unit) passthrough enables a virtual machine to directly access a physical PCIe GPU, bypassing the host OS to provide near-native performance.

GPU Security Lags Behind CPUs

According to Zenla, GPU security is a decade behind where CPU (central processing unit) virtualization is today. Cloud providers are racing to deploy GPU capacity without the corresponding isolation primitives.

“Edera for GPUs was built specifically to close that gap, bringing hardware-enforced isolation to GPU workloads the same way hypervisors transformed CPU security,” she offered.

To do this, Edera uses a type-1 hypervisor that runs directly on the hardware to reduce the number of hops required to enable passthrough. This approach simplifies GPU configuration and setup.

Edera also controls access to the I/O Memory Management Unit (IOMMU) at a low level, enabling faster boot times and lower overhead. This hardware component translates device-visible virtual addresses to physical addresses.

“By doing this in the hypervisor layer as opposed to on the host system and in userspace, we maintain great performance while running on a very small attack surface. No longer do you have a large attack surface like QEMU in the pathway of handling the GPU,” Zenla added.

Reducing Multi-Tenant Risk

In a world where AI agents share physical infrastructure, Edera’s hypervisor-based layer addresses a key security element that current sandboxing methods overlook. Noisy neighbor or side-channel attacks occur when a tenant in a shared (multi-tenant) environment monopolizes resources, degrading performance for other users on the same infrastructure.

Zenla noted that a malicious tenant can infer what other tenants are doing by observing the shared state. Hypervisor resource allocation mitigates these. Any accidental or malicious agent that begins consuming compute resources is met with vCPU and memory allocation barriers that saturate the workload without impacting the rest of the tenant’s resources.

“With Edera, we eliminate this class of attack because every workload gets its own kernel. A hypervisor can pin tenants to specific CPU cores and provide them with their own Linux kernel. This mitigates cross-tenant cache and branch-predictor attacks,” she said.

Hidden Risks in AI Infrastructure

Zenla warned that as cloud providers rush to stand up AI infrastructure, the security trade-off they quietly accept is that GPU isolation is less mature than CPU isolation. Providers are racing to ship GPU capacity for AI, and GPUs are essentially their own distributed systems that circumvent standard OS protections.

When she hears product descriptions that claim to bypass the CPU and OS, Zenla notes the absence of core safeguards, including virtual memory protection, kernel security controls, firewalls, network policies, and eBPF visibility. On top of that, many GPU drivers operate as large, proprietary, closed-source components with kernel-level privileges (ring 0), the highest privilege level on the CPU.

“A bug in any of those kernel modules gives an attacker full kernel memory access on the host,” she concluded.