Not long ago, Anthropic revealed that its latest AI model, Mythos, independently identified and weaponized zero-day vulnerabilities across every major operating system and web browser — including a 27-year-old flaw that had evaded decades of human audits and millions of automated checks. The model needed no specialized guidance or human experts directing its efforts.
If an AI model can autonomously chain together exploits to gain full kernel-level control of Linux, what does that say about an infrastructure paradigm in which thousands of workloads run on a single shared kernel with no structural barriers between them? Mythos didn’t create a new category of threat — it simply made the cost of an already-existing design flaw impossible to keep ignoring.
Dashboards of doom
Examine the mainstream security tools available today. With only a handful of exceptions, they amount to little more than flashy log generators and alarming dashboards. Runtime detection agents, vulnerability scanners, admission controllers — all of them operate under the same fundamental premise: prevent the breach, or catch it quickly enough, and you’re safe.
What they don’t actually do is make the underlying system any more resilient. A scanner flags a critical CVE, opens a ticket, and throws it over the wall to a development team that has a completely different set of priorities. The infrastructure can’t heal itself. It can’t limit the damage. It simply watches the fire spread and carefully logs everything.
Think about it in Kubernetes terms. Your pod crashes, and rather than automatically rescheduling it, the kubelet creates a Jira ticket: “Pod unhealthy. Recommended action: restart. Assigned to: platform team.” That would sound ridiculous — yet that’s precisely how security operations function in the vast majority of organizations today.
Proactive security controls also demand an unrealistic level of knowledge to configure properly. Every network policy, RBAC rule, and seccomp profile must be precisely calibrated to match the behavior of the workload it’s meant to protect. In a multi-tenant Kubernetes cluster with thousands of containers, someone has to know exactly which APIs each service calls, what ports it needs, which filesystem paths it touches, and what “normal” behavior looks like — for every single workload.
This isn’t a problem with the tools — it’s a problem with the information. The knowledge needed to properly configure proactive controls is scattered across teams and never centralized anywhere. Perfect configuration would require omniscience, and omniscience isn’t something you can package into a product.
That leaves the industry stuck in a never-ending loop of incremental hardening — patch this CVE, tighten that network policy, add yet another detection rule. Every incremental improvement places the burden squarely on the defender’s shoulders, permanently. The attacker just needs to find one viable attack path: initial access, privilege escalation, lateral movement. The defender has to do everything perfectly across thousands of workloads simultaneously. The odds are stacked impossibly against defense.
The design question
There’s one deceptively simple question that most security architectures can’t answer:
How would you design your systems if you assumed a workload was already compromised — the same way you accept that a pod could crash at any moment?
That’s precisely how SRE approaches reliability. You don’t build a distributed system relying on the assumption that every node will stay healthy. You accept that nodes will fail unpredictably, and you architect so that individual failures don’t cascade. Circuit breakers stop the chain reaction. Failure domains contain the blast radius. You don’t need every single node to survive in order for your service to keep running, because the architecture was designed with failure in mind.
Now imagine applying that exact philosophy to security. What if a single compromised workload were treated exactly the same way Kubernetes handles a crashed pod — as an anticipated failure that the system routes around on its own? Not a crisis. Not a dashboard alert. Not an all-hands incident response call. Just another ordinary Tuesday.
The Kubernetes irony
The irony is most glaring within the Kubernetes ecosystem itself.
Kubernetes represents the SRE revolution for infrastructure — the most successful embodiment of “design for failure” ever created. Pods crash and get rescheduled. Nodes go down and workloads migrate. The entire platform assumes any individual component can fail — and it handles all of that automatically.
Yet the security controls running on top of this very same platform constitute a catastrophic single point of failure.
Most Kubernetes clusters run every container against a single shared Linux kernel. Every workload on a node — every microservice, every sidecar, every batch job — from every team shares the exact same kernel address space. A kernel vulnerability doesn’t just compromise one container; it compromises every single container on that node. To make matters worse, all the security tools you’ve deployed to detect compromise — eBPF-based agents, LSM modules, seccomp-bpf filters — run on that very same kernel. A single kernel exploit doesn’t just breach every container; it simultaneously blinds every monitoring tool watching the breach. Your detection mechanism and your blast radius are one and the same.
We’ve built a platform that gracefully handles the failure of any pod, any node, any infrastructure component — and then we layer a security model on top of it with zero isolation, zero failure domains, and zero plan for what happens when the kernel — the single shared piece of infrastructure — is the thing that fails.
The structural fix
If the shared kernel is the reason a single exploit can cascade across every workload on a node, then the architectural remedy is the same one that distributed systems engineering figured out decades ago: remove the single point of failure.
Stop running every workload against one monolithic kernel. Instead, distribute independent kernel instances across workloads — the same way you’d replicate a monolithic database into multiple independent replicas. When one kernel instance is compromised, the damage is confined to a single workload — not because someone remembered to configure the right policy, but because the architectural boundary itself enforces containment.
This doesn’t mean you should abandon security policies altogether. Network segmentation, least-privilege IAM, and supply chain security all still matter. What changes is the fallout when those policies are misconfigured. With structural isolation in place, a policy mistake affects only the workload it’s tied to. Proactive controls become a best-effort hardening layer backed by a safety net — rather than the last and only line of defense.
The AI agents proof
Here’s what makes this particular moment unique: the AI industry has effectively already run the experiment for us.
Every major AI lab building autonomous agents arrived at the exact same architectural conclusion independently — containment first, hard boundaries, strongly sandboxed execution environments where policy misconfigurations can’t cascade past the sandbox’s walls. They still employ security policies, but they treat those policies as a layer inside the sandbox rather than as the boundary itself.
The reason is straightforward: you can’t possibly write a comprehensive security policy for a system whose next actions are unpredictable. An AI agent might legitimately need to install packages, write files to arbitrary locations, and initiate network connections — but it might do something catastrophic as well. The range of possible behaviors is simply too vast for policy alone to handle. So instead they built walls and placed the policies inside them.
The AI industry independently rediscovered something the mainstream security industry should have embraced decades ago. So why are we still running production workloads — the ones processing customer data, financial transactions, and critical infrastructure — on shared kernels that offer less isolation than a single browser tab? Google Chrome figured out more than ten years ago that a crashed or compromised tab shouldn’t bring down the entire browser. Yet your Kubernetes cluster running payment processing has weaker isolation guarantees than casually browsing Reddit.
The shift
I began my career as a systems administrator who believed the job was simply to keep servers alive. At Google, I learned that the real objective was to build systems that didn’t depend on me to stay alive. That mental model transformed infrastructure engineering. It gave birth to SRE, Kubernetes, and every self-healing distributed system we rely on today.
Security is still waiting to undergo that same transformation. We’re still building systems that depend on heroes — someone to notice the breach, decipher the dashboard, triage the alert, and mobilize the response team. We’re still approaching compromise as an event that shouldn’t happen rather than something the architecture was designed to absorb. At Edera, we believe security must undergo the same paradigm shift that transformed operations into reliability engineering — a discipline built on the acceptance that failure is inevitable, measured by blast radius instead of breach count, and engineered so that no single compromise can cascade beyond its failure domain. We’ve dedicated two years to building the isolation layer that makes this vision real for Kubernetes. Not another dashboard, not another detection tool — but an architectural default that turns a compromise into a non-event, just the same way Kubernetes turned a crashed pod into a non-event.
