Four failures. Four layers. The architecture itself is the vulnerability.

A recent April 10, 2026 episode of the  New York Times’ Hard Fork podcast examined the cybersecurity implications of advanced AI systems and raised a question the industry has been avoiding: what if cybersecurity isn’t underperforming, but fundamentally misframed?

The episode aired weeks after a sequence of incidents made the answer hard to ignore. In a single month, an autonomous AI agent breached McKinsey’s internal AI platform in two hours. A supply chain attack on a widely used open-source AI library cascaded into downstream enterprises. Researchers showed that the hardware meant to be the last line of defense can be broken with off-the-shelf parts costing less than a thousand dollars. And Anthropic disclosed that a frontier model had autonomously found thousands of zero-day vulnerabilities in code the industry considered stable.

Four incidents. Four layers of the AI stack: application, orchestration, hardware, and operating system. Each revealed meaningful limitations in the controls designed to protect them.

The End of Perimeter Thinking

Traditional cybersecurity rests on a single premise: with enough controls, monitoring, and investment, systems can be secured. That premise shaped decades of architecture, including firewalls, identity management, endpoint security, and SIEM platforms, all built on the idea that visibility and tight management equal safety.

The industry’s shift toward Zero Trust Architecture reflects growing recognition that traditional network boundaries can no longer be assumed trustworthy. Yet even as trust models evolve, AI systems introduce a different challenge: sensitive data is routinely aggregated, processed, and shared across multiple layers of infrastructure.

That approach made sense when systems were relatively centralized and data remained within clearly defined boundaries. It becomes far less effective when data moves continuously across clouds, APIs, third-party vendors, and AI pipelines, while users and compute resources are distributed globally. The perimeter is no longer a boundary. It is a constantly shifting surface, and we are still applying control-based thinking to systems that cannot realistically be controlled.

Application Layer Failure: McKinsey’s Lilli

On March 9, 2026, security startup CodeWall published a disclosure that highlighted the risks facing organizations deploying AI internally. .

CodeWall’s autonomous offensive agent, with no credentials, no insider knowledge, and no human guidance, achieved read and write access to the production database behind Lilli, McKinsey’s internal AI platform, in under two hours. Lilli is used by more than 40,000 employees for strategy work, client research, and document analysis, generating hundreds of thousands of prompts per month.

The entry point was not sophisticated. The agent found publicly exposed API documentation listing more than 200 endpoints, 22 of which required no authentication. The vulnerabilities involved mirror risks highlighted in the OWASP Top 10 for LLM Applications, particularly around exposed interfaces, insecure integrations, and excessive trust in connected systems.

One of those endpoints contained a SQL injection vulnerability hidden in JSON field names rather than input values, where most automated scanners look. From there, the agent iterated through blind SQL injection until production data became accessible.

What it accessed: tens of millions of chat messages in plaintext, hundreds of thousands of files, tens of thousands of user accounts, and millions of RAG document chunks representing years of proprietary research. It also identified the system prompts that governed how Lilli behaved for every user.

The most alarming finding was not the volume. It was that the system prompts were writable. An attacker could have silently rewritten the instructions governing Lilli’s outputs, poisoning strategic advice, embedding confidential data into responses, or removing guardrails entirely, with a single database update. No deployment. No code change. No trace in application logs.

In a public statement, McKinsey said it remediated the issue within hours and, following an investigation by a third-party forensics firm, found no evidence that client confidential data was accessed. That response matters. But it does not change the structural lesson: a decades-old vulnerability class exposed the operational memory of a modern AI system because the data behind it existed in readable form.

Orchestration Layer Failure: The LiteLLM Attack

Three weeks later, the same pattern appeared from a different angle, and through a different layer.

LiteLLM is an open-source AI gateway used by thousands of companies to route requests across AI providers. Its position in the stack is critical: it sits at the orchestration layer, holding API keys for every provider it connects to. Any compromise at this layer exposes credentials across every integrated service.

According to a PyPI incident report, threat actor group TeamPCP exploited credentials tied to a dependency in LiteLLM’s CI/CD pipeline and used maintainer access to publish two backdoored versions of the LiteLLM package directly to PyPI. . The tainted versions were live for less than an hour before being removed. The operation was discovered only because the malware contained a bug that crashed a researcher’s machine.

The supply chain was the vector. The orchestration layer was the target. By compromising a single dependency upstream, attackers reached the layer where every downstream company’s provider keys lived.

The LiteLLM team later detailed the incident and mitigation efforts in a public GitHub disclosure.

The blast radius became visible almost immediately. TechCrunch, Fortune, and The Register reported that Mercor, a $10 billion AI recruiting startup working with companies including OpenAI, Anthropic, Meta, and Google, was among the organizations affected. Attackers claimed to have obtained large volumes of data, including candidate profiles, personally identifiable information, contractor video interviews, source code, and API keys. Meta paused work with Mercor pending investigation. Subsequent reporting indicated similar malware patterns appearing in other developer tools and packages, suggesting the operation may have extended beyond a single project.

The LiteLLM incident was not an anomaly. It was the system behaving as designed. Every component in an AI pipeline requires access to usable data to function, which means every component is also a potential extraction point. Pinning dependencies and rotating credentials are necessary responses, but they address the incident, not the architecture.

Hardware Layer Failure: TEE.fail

If the McKinsey breach demonstrated that the application layer cannot be trusted, and the LiteLLM attack demonstrated that the supply chain cannot be trusted, the TEE.fail research demonstrated that the hardware intended to compensate for both cannot be fully trusted either.

On October 28, 2025, researchers from Georgia Tech, Purdue University, and Synkhronix published TEE.fail, a side-channel attack that extracts cryptographic keys from Trusted Execution Environments using physical memory bus interposition on DDR5 servers. The attack affects Intel SGX, Intel TDX, and AMD SEV-SNP, including on fully patched, trusted-status systems with AMD’s Ciphertext Hiding enabled. These are the technologies widely promoted as the foundation of confidential computing.

The researchers extracted attestation keys: the cryptographic material used to verify that workloads are running inside secure environments. With those keys, a compromised system can present itself as trusted while operating entirely outside expected protections. The researchers demonstrated this directly: they forged TDX attestations on Ethereum’s BuilderNet to access confidential transaction data, and faked Intel and NVIDIA attestations to run workloads outside any TEE while appearing legitimate.

The NVIDIA implication matters for AI specifically. Because GPU attestation depends on CPU attestation, a compromised CPU trust chain can undermine the guarantees provided by confidential AI inference environments. The hardware foundation of confidential AI inference is, in this threat model, conditional on a CPU TEE that has been demonstrably broken.

Hardware vendors responded with formal advisories. AMD stated that physical access attacks fall outside its standard threat model and indicated it would not issue firmware updates. Intel and NVIDIA acknowledged the findings and indicated ongoing mitigation work. These responses are reasonable within their threat models. They also highlight an important boundary: the guarantees of hardware-based security depend on assumptions, including physical control, that sovereign, regulated, and adversary-facing deployments cannot always make.

TEE.fail does not render hardware isolation irrelevant. It demonstrates that it is conditional.

 OS Layer Failure:  The Mythos Revelation

If the first three incidents called into question the application layer, the orchestration layer, and the hardware layer, a fourth disclosure in April 2026 called into question the layer underneath all of them: the operating systems and core libraries that every other layer runs on.

On April 7, 2026, Anthropic announced Claude Mythos Preview, a frontier model that it declined to release publicly because of its offensive security capabilities, and simultaneously launched Project Glasswing, a consortium with AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, the Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks. Anthropic reported that, in a matter of weeks, Mythos had autonomously identified thousands of previously unknown vulnerabilities across major operating systems and web browsers and was capable of producing working exploits for many of them.

The specific findings are harder to dismiss than any summary suggests. A 27-year-old bug in OpenBSD. A 17-year-old remote code execution flaw in FreeBSD’s NFS server, now tracked as CVE-2026-4747, which grants root access to an unauthenticated attacker. A 16-year-old vulnerability in FFmpeg, one of the most widely deployed media libraries on the internet. In one case, an Anthropic engineer with no formal security training asked the model to look for remote code execution flaws overnight and woke up to a complete working exploit.

These are operating system-level findings. OpenBSD and FreeBSD are kernels. NFS is a kernel networking subsystem. FFmpeg is a system library that ships with most Linux distributions and underpins media pipelines across the internet. The OS layer was assumed safe not because it had been proven secure, but because finding deep flaws in it required scarce and expensive human expertise. That assumption was the best available heuristic. It was never a guarantee.

That constraint has now loosened. Anthropic itself framed this as a dual-use shift: the same capabilities that allow a frontier model to find and patch vulnerabilities at scale also allow it, in the wrong hands, to find and exploit them at scale. Anthropic’s decision to restrict access through Project Glasswing reflects that reality. It does not resolve it. Similar capabilities will, by the company’s own assessment, proliferate. The cost of auditing legacy code has collapsed, and with it the implicit defense that such code was too obscure, too old, or too widely reviewed to still contain critical flaws.

This is also where the four incidents compound. The hardware layer’s confidential computing protections do not run in isolation. They run as kernel code. Intel TDX runs in the kernel. NVIDIA’s GPU drivers run as kernel modules. The CPU TEE attestation chain depends on a trustworthy operating system to faithfully report what it is doing. If the OS layer underneath your TEE has decades of latent vulnerabilities, and a frontier model can now find them at machine speed, then the hardware layer’s conditional security depends on an OS layer whose security guarantees have just been weakened by the same disclosure cycle.

The three earlier incidents describe how AI systems are being breached today. Mythos describes the rate at which everything underneath them, including the operating systems, kernel modules, and system libraries, is about to be re-audited by machines. The McKinsey breach exploited a SQL injection class of vulnerability that has existed for more than two decades. Vulnerabilities of that vintage are precisely what models in the Mythos class are demonstrably capable of finding at industrial scale.

The Pattern

In every case, the data was in plaintext at the moment it mattered.

The application layer processed it in the clear. The orchestration layer routed it in the clear. The hardware layer, despite its protections, ultimately required decryption at the point of execution. The OS layer underneath all three operated on it in the clear by definition. Four layers, four failures, and at every layer the same condition held: when the breach happened, the data was readable.

This is not a collection of isolated failures. It is the architecture itself.

Modern AI systems are designed to operate on readable data. Every layer, including retrieval, routing, inference, and tool execution, requires plaintext access to function. That design choice means any breach at any layer exposes the data behind it.

The question is not whether a layer will be compromised. It is what the attacker finds when it is.

From Assumed Breach to Zero Exposure

The industry has already started shifting from “prevent breach” to “assume breach.” But most architectures have not followed through on the implications.

If breach is inevitable, then the real question is not how to keep attackers out. It is what happens when they get in. Right now, the answer is simple: they get the data. Because despite all the investment in security infrastructure, data is still exposed at the exact moment it becomes valuable, when it is being used.

The industry response has been predictable: more monitoring, faster detection, additional layers of confidential computing. These are improvements. But they do not solve the core issue. They still assume that some layer — whether software, hardware, or operational — can be trusted to keep plaintext safe.

The alternative is to remove the plaintext entirely. Not to secure the layers around the data, but to make the data itself inaccessible to anyone who reaches it. Computation on encrypted data, where prompts, model weights, and outputs remain encrypted throughout the pipeline, addresses the exposure that each of these incidents exploited.

Advances in fully homomorphic encryption and other privacy-preserving computing techniques are beginning to make architectures that minimize or eliminate plaintext exposure increasingly practical for real-world AI workloads. While significant performance, scalability, and implementation challenges remain, the objective is fundamentally different from traditional security controls: reducing the value of a successful compromise rather than simply making compromise less likely.

The shift is not from one security tool to another. It is from securing systems to reducing exposure. From trusted infrastructure to zero-trust data. From managing risk to minimizing the attack surface itself.

What Comes Next

The Hard Fork discussion raised the question of whether cybersecurity is fundamentally misframed. The evidence from the past several weeks suggests the answer is yes, at least for AI.

The old model assumed systems can be secured, breaches can be contained, and exposure can be managed. The emerging reality is that breaches must be assumed and exposure minimized. The incidents described here suggest that securing AI systems may increasingly depend on reducing the amount of sensitive data available when controls fail.

The vulnerabilities exposed across these four incidents are not confined to a single layer. They are systemic. Addressing them will require more than incremental improvements. It will require a shift from securing systems to reducing exposure, from defending the perimeter around the data to removing the plaintext the perimeter was built to protect.

AI security is no longer about keeping attackers out. It is about ensuring that when they get in, and they will, there is nothing readable for them to find.