We all agree that the rise of containers reshaped modern infrastructure. Technologies like Kubernetes and Docker brought unmatched agility and portability, allowing teams to ship software faster than ever. But as someone who has spent over a decade in low-level systems, I can tell you this: containers do not contain. Not in the way that matters for modern security or operational reliability.

If we want real isolation in multitenant environments—especially in the era of AI—we need to stop treating containers as safe by default and start rooting trust boundaries below the operating system.

A Shared Kernel is Not a Boundary

Containers were never designed to be security enforcers. They are Linux processes, wrapped in namespaces and cgroups, all sharing the same kernel. That kernel becomes a massive shared surface. If one container is compromised, the attacker can potentially escalate privileges or move laterally to others on the same host.

This is not a theoretical concern. Container escapes are regularly discovered, often involving exploits in kernel subsystems like overlay filesystems, control groups, or networking. Worse, these vulnerabilities affect every container running on the node. One compromise can jeopardize an entire workload fleet.

The industry got lulled into a false sense of containment. The simplicity of Docker made containers feel like sealed units. They are not. They are fast and efficient, but they were never intended to be isolation primitives.

Isolation is About More Than Security

Too often, isolation is framed purely as a security measure. But it is also a performance and reliability tool. In multitenant environments, a lack of strict boundaries causes noisy neighbor issues, unpredictable latency, and inefficient bin-packing.

This becomes even more pronounced with AI workloads. These jobs often consume large amounts of GPU or CPU resources. When scheduling is left to the Linux kernel, there is no awareness of which workloads require consistent performance or strict separation. Even minor interference can degrade results, break SLOs, or increase cost.

True isolation enables confident co-location. If you can guarantee that one tenant’s workload cannot affect another’s, you can pack workloads more tightly, reduce infrastructure sprawl, and avoid overprovisioning. That is not just safer—it is more efficient.

Moving Isolation Below the OS

The solution lies in shifting isolation to the hardware layer. The Linux kernel was never designed to enforce trust boundaries across untrusted tenants. It cannot track precisely which container owns which kernel state or memory region. It cannot prevent privileged system calls from being abused if the attacker finds a way in.

This is where microkernels, para-virtualization, and minimal hypervisors come in. By using hardware-backed techniques to run each container or workload in its own virtualized zone, you eliminate the risks of a shared kernel. Each zone has its own kernel instance, its own drivers, and its own resource scheduler.

Importantly, these methods no longer come with the heavy cost of traditional virtual machines. Advances in lightweight virtualization and paravirtualization have enabled hypervisors that boot in milliseconds, with memory overhead measured in megabytes, not gigabytes. Some even support full Kubernetes compatibility while providing the kind of strict isolation containers were never meant to deliver.

This architecture also enables better observability. When the hypervisor controls memory and CPU allocation directly, it can trace workload behavior precisely—tracking file access, system calls, and network usage without relying on intrusive agents or privileged containers.

The GPU Problem

Nowhere is weak isolation more dangerous than with GPUs. These devices were never designed for secure multitenancy. Unlike CPUs, which zero out memory and provide process-level access control, GPUs often retain memory between jobs. This creates risk for AI workloads that deal with sensitive data or proprietary model weights.

In practice, one tenant’s model could finish running, and its memory remnants could be accessed by the next job on the same GPU. Traditional observability tools like eBPF do not help here, because GPUs operate outside the kernel’s purview. They are effectively their own computers, attached to your system without visibility or safeguards.

Any isolation model that leaves GPU workloads exposed is incomplete. Isolation boundaries must extend to device drivers and hardware. Virtualized environments that separate GPU access at the driver and bus level are becoming critical—not just for security but for auditability and regulatory compliance.

A New Operating Principle for ITOps

For IT operations teams, the takeaway is simple. Containers are an efficiency layer, not a trust boundary. Security must be established below the OS, using architectural controls that cannot be bypassed with a kernel exploit. If your platform depends on shared-kernel containment, it is living on borrowed time.

Start thinking of isolation as a foundation for everything else: security, performance, and cost efficiency. Adopt virtualization layers that enforce strict separation between workloads, even when running on shared infrastructure. Leverage runtime observability at the infrastructure level to catch unknown threats before they spread.

And above all, abandon the illusion that a container is a secure unit of execution. It is not. The boundary needs to be real, enforced, and visible—not assumed.

The systems that will survive are the ones that enforce isolation through architecture, not just rely on default container behavior.