CNCF: AI sandboxing has reached its Kubernetes moment — isolated kernel per workload as the new security standard

Jed Salazar, Field CTO at Edera, published an analysis on the CNCF blog on April 30, 2026, arguing that Kubernetes infrastructure is going through the same inflection point that the AI industry already experienced when developing secure agentic systems.

Why is the shared kernel a structural security problem?

The problem lies in the fundamental architecture of Kubernetes: all workloads within a cluster share a single Linux kernel. This means that isolation between containers is not complete at the operating system level — it only exists at higher layers of abstraction.

According to Salazar’s argument, a single kernel compromise cascades to all workloads. An attacker exploiting a vulnerability in kernel space can bypass all container-level security mechanisms and gain access to sensitive data or processes running in entirely different applications.

What do AISI findings say about the severity of the threat?

Salazar draws on findings from the AI Safety Institute (AISI) documenting that AI models autonomously discover zero-day vulnerabilities in software systems. This is not a theoretical threat: the automation of attacks on kernel vulnerabilities is becoming accessible to a broader range of actors.

Salazar argues that detection-based security — the approach that detects an attack after it occurs — is insufficient in this context. Once an attacker compromises the kernel, the damage is already done.

How does the AI sandboxing principle address Kubernetes isolation?

The solution Salazar proposes is isolated kernel instances per workload — each Kubernetes pod or deployment gets its own kernel instead of sharing it with the rest of the cluster.

This principle is not new: the AI industry already applies it for sandboxing agentic systems to prevent a compromised AI session from affecting infrastructure or other agents. Salazar’s argument is that the same logic should be applied to all cloud native infrastructure, not just AI workloads.

Broader context for the cloud native community

Publication on the CNCF blog — which is the voice of the Cloud Native Computing Foundation, the organization maintaining Kubernetes, Prometheus, and dozens of related projects — gives the argument specific weight within the cloud native ecosystem.

Edera develops tools for kernel-level workload isolation, so Salazar has a commercial position in this discussion. Regardless, the structural argument about the shared kernel as a single point of failure remains a technical consensus within the security research community.