By Luigi Caramico, Founder and CTO of DataKrypto

On March 9, 2026, CodeWall.ai published a consequential AI security disclosure: “How We Hacked McKinsey’s AI Platform.” Codewall’s autonomous offensive agent — with no credentials, no insider knowledge, and no human guidance — achieved full read and write access to the production database behind Lilli, McKinsey’s internal AI platform used by more than 43,000 employees.

The breach did not rely on exotic zero-days. It exploited plaintext.

This post is not about issues with McKinsey’s application security. SQL injection has existed for decades and still affects world-class engineering teams. The real question every organization deploying AI should be asking is different:

What happens to my data when the perimeter fails?

Perimeters will fail. The real test of security is whether your data survives the breach.

What Lilli Exposed

To be clear, CodeWall’s breach was not malicious; rather, it was an attempt to demonstrate the fragility of today’s agentic AI systems – with which nearly two-thirds of organizations are already experimenting, according to a recent report from McKinsey itself. Without proper security, this presents a huge vulnerability.

While the scale of the breach is staggering, the pattern is familiar. Lilli is a purpose-built AI platform supporting chat, document analysis, and RAG across more than 100,000 internal documents. Over 70% of McKinsey’s workforce use it, generating more than 500,000 prompts per month.

CodeWall’s agent discovered publicly exposed API documentation containing more than 200 endpoints, 22 of which required no authentication. One of them contained a SQL injection vulnerability hidden in JSON field names that traditional scanners missed.

From there, the agent iterated through blind SQL injection until production data began flowing.

What it found:

• 5 million chat messages in plaintext— every conversation was accessible, including strategy discussions, client engagements, financials, and M&A analysis.
• 68 million RAG document chunks — decades of proprietary McKinsey research with file paths and metadata.
• 728,000 files — PDFs, spreadsheets, presentations, and internal documents accessible through direct URLs.
• 95 system prompt configurations across 12 model types — revealing the entire behavioral configuration of the AI.
• 57,000 user accounts and 384,000 AI assistants — the organizational map of how McKinsey used AI internally.
• 1 million files and 217,000 agent messages flowing through external AI APIs, including more than 266,000 OpenAI vector stores.

Every piece of this data existed in readable form – making it invaluable to an attacker.

AI platforms concentrate organizational knowledge—chat history, internal documents, prompts, and analytical workflows—into a single system, meaning a single breach can expose the operational memory of an entire company.

The Prompt Layer: AI’s New Crown Jewel

One of the most important observations in the CodeWall report is that the prompt layer has become a critical security target.

System prompts control how AI behaves through guardrails, citations, refusal policies, and workflow instructions. In Lilli’s case, those prompts were stored in the same database accessed through SQL injection.

The attack was not read-only.

Not only was the data accessible, but an attacker could also have silently rewritten those prompts using a single database update.

The implications for 43,000 consultants relying on Lilli would be:

• Poisoned recommendations — subtle manipulation of financial analysis or strategy advice.
• Data exfiltration via output — embedding confidential data into AI responses.
• Guardrail removal — instructing the model to reveal internal documents.
• Silent persistence — unlike compromised code, prompt changes leave almost no operational trace.

Organizations have spent decades securing their code and infrastructure. The instructions governing AI behavior are now equally critical — yet they remain largely unprotected.

What Encrypted Execution Changes

Encrypted execution allows AI systems to process encrypted representations of prompts, documents, and embeddings without exposing the underlying plaintext during storage, retrieval, or inference. DataKrypto’s FHEnom for AI™ implements this through continuous encryption, keeping data encrypted across every stage of the AI lifecycle.

Encrypting AI data and models continuously would have prevented Codewall’s successful breach experiment – but not by preventing SQL injection. That is an application-layer vulnerability.

Rather, encrypted execution ensures that even a full infrastructure compromise does not expose the data behind it.

Here is how the Lilli breach would map to an encrypted architecture.

Chat Messages

When prompts are encrypted at the client and converted into encrypted token sequences before entering the inference pipeline, the model processes ciphertext tokens directly, and databases store encrypted data only.

Even with full database access, an attacker obtains information that is mathematically unusable.

RAG Knowledge Bases

The most dangerous exposure in the breach was the RAG knowledge base — structured representations of decades of proprietary research.

All contextual documents must be encrypted before they enter the retrieval pipeline. Stored RAG chunks are encrypted representations rather than readable text.

Exfiltrating the database yields nothing usable.

System Prompts and Model Configuration

System prompts flow through the same encrypted pipeline as user prompts.

An attacker accessing the database sees encrypted configuration data rather than readable instructions. Guardrails, model parameters, and workflow logic remain protected.

Prompt Layer Manipulation

The most damaging finding in the CodeWall report was the ability to modify prompts.

Encrypted execution addresses this at the cryptographic level.

All inputs must pass integrity validation before entering the encrypted tokenizer. Any modification to stored prompt data invalidates the signature and is rejected before execution.

Prompt poisoning via the database writes becomes structurally impossible.

Cross-User Data Access

The attack combined SQL injection with an IDOR vulnerability to read other users’ search histories.

Encrypted execution uses session-based encryption keys that rotate per interaction. Data from one session cannot be decrypted in another.

Even if records are accessed, they remain isolated ciphertext.

Third-Party AI APIs

The breach also exposed pipelines sending data to external AI services, including more than 266,000 OpenAI vector stores. This is where an important boundary applies. Encrypted execution can only protect this path if the third-party service also operates within the encrypted execution architecture. Where it does, embeddings flow as ciphertext and the third party processes data it cannot read. Where it does not, data must be decrypted before reaching the external model, and encryption cannot protect that path.

Raw Uploaded Files

Continuous encryption protects data inside the AI pipeline. Documents processed through RAG are encrypted before ingestion.

Raw uploads stored outside the pipeline remain part of the broader infrastructure security domain. In this scenario, exposure is mitigated rather than eliminated.

Security boundaries must always be stated honestly.

The Verdict

EXPOSURE	WITH ENCRYPTED EXECUTION
46.5M chat messages	Stopped — encrypted storage
3.68M RAG chunks	Stopped — encrypted ingestion
System prompts	Stopped — encrypted pipeline
Prompt poisoning	Stopped — cryptographic validation
Cross-user search history	Stopped — session isolation
External AI pipelines	Conditional — requires encrypted execution on both sides
Raw uploaded files	Mitigated
User account metadata	Mitigated
SQL injection itself	Not prevented

With continuous encryption enabled throughout the system, five consequences would be fully prevented while three would be conditional/mitigated.

The vulnerability itself remains an application issue — as it should.

Let’s be clear. Encryption doesn’t replace secure software. It ensures software failures don’t become data breaches.

The Structural Lesson

McKinsey did not lack proper security investment. Lilli had been running in production for years, and internal scanners had detected nothing.

The lesson is not simply “write better code.”

Instead, perimeter and application security are probabilistic defenses. When the data behind them exists in plaintext, a single failure exposes everything.

In traditional architectures, root access means full data access. Encrypted execution breaks that equation.

Even under a full system compromise — database access, root privileges, infrastructure control — prompts, models, RAG context, and responses remain encrypted and computationally unusable.

CodeWall concludes that autonomous agents will soon attack systems at machine speed. Most organizations are still defending with perimeters.

The choice is no longer between perfect security and acceptable risk. It’s between two architectures:

Traditional: Trust the perimeter. Pray the application layer holds. When both fail—and they will—everything is exposed.

Encrypted Execution: Assume the perimeter fails. Design so that failure doesn’t matter.

This is not a feature. It is architecture. And the organizations that deploy it first will own the AI era. Everyone else is betting on luck.