‍How SQL Injection Breached McKinsey's Lilli AI Platform: 46.5 Million Messages Exposed

On February 28, 2026, a security company called CodeWall pointed an autonomous offensive AI agent at the open internet and let it choose a target. It picked McKinsey & Company's Lilli — the consulting firm's internal AI platform used by more than 43,000 employees worldwide.

Two hours later, the agent had full read and write access to Lilli's production database.

‍

The damage surface: 46.5 million chat messages, 728,000 files, 57,000 user accounts, and 95 system prompts that governed how the AI behaved for every user. And the vulnerability that made it all possible? SQL injection — a bug class that's been documented since the 1990s.

What Is Lilli, and Why Did It Matter?

McKinsey launched Lilli in 2023, naming the platform after Lillian Dombrowski, the firm's first professional female hire in 1945. By the time of the breach, over 70% of McKinsey's workforce used it daily. The platform indexed more than 728,000 internal documents and ran retrieval-augmented generation (RAG) over decades of proprietary research, processing upwards of 500,000 prompts per month.

Lilli wasn't just a chatbot. Its database held user data alongside AI configuration — system prompts, RAG knowledge bases, and behavioral guardrails. Anyone with write access to that database could silently alter how the AI responded to every employee across the firm.

That distinction is what separates this from a conventional breach. A traditional database compromise steals data. An AI platform breach can corrupt the advice that thousands of professionals rely on — without leaving a trace in application logs.

How the Attack Unfolded

CodeWall's autonomous agent followed a methodical, three-step process — standard in structure, but executed at machine speed.

Step 1: Mapping the attack surface

The agent discovered that Lilli's API documentation was publicly accessible, revealing more than 200 endpoints. Of those, 22 required no authentication whatsoever. One of those unauthenticated endpoints accepted user search queries and wrote them directly to the database.

Step 2: Finding the injection point

The search endpoint had parameterized its query values correctly — the standard defense against SQL injection. But the JSON keys (the field names themselves) were concatenated directly into the SQL query without sanitization.

When the agent sent malformed key names, the database reflected them verbatim in its error messages. That reflection was all the agent needed. In just 15 blind iterations, it refined its injections, extracting progressively more data from each error response until production records started flowing back.

This is a pattern most automated security scanners miss entirely. Tools like OWASP ZAP check for injection in values, not in key names. The vulnerability sat in a blind spot.

Step 3: Chaining with IDOR

Once inside, the agent combined the SQL injection with an Insecure Direct Object Reference (IDOR) vulnerability. This allowed it to access individual user records by incrementing IDs, exposing each employee's search history and revealing what McKinsey's consultants were actively researching.

Together, these two vulnerabilities gave the agent unrestricted read-and-write access to the entire production database.

What Was Exposed

The scope of the breach was substantial:

• 46.5 million chat messages
• 728,000 files (Excel, PowerPoint, PDF, Word)
• 57,000 user accounts
• 95 system prompts
• 3.68 million RAG document chunks
• 94,000 AI workspaces

The 3.68 million RAG chunks represent McKinsey's intellectual foundation — proprietary frameworks, internal research, and client-engagement methodologies built over decades. Each chunk came with its S3 storage path and internal metadata intact, meaning an attacker would know exactly where the original documents lived.

The 95 system prompts contained the AI's behavioral rules: how to answer questions, which guardrails to enforce, and how to cite sources. They were stored in the same database as everything else, protected by the same (absent) authentication.

Why System Prompt Access Changes Everything

In a traditional application, database write access has a bounded impact. An attacker who can write to a users table can create accounts or change passwords. An attacker who can write to a sessions table can hijack logins. Serious, but scoped.

When an AI platform stores its behavioral configuration in a SQL database, write access takes on a different dimension entirely.

Consider what becomes possible: modify a system prompt to suppress certain response types, and the AI silently stops providing them. Add an instruction to include a specific URL in every financial recommendation, and the AI will do it reliably for every consultant who asks. Change the citation behavior, and years of accumulated professional trust in the system start pointing wherever the attacker wants.

None of these changes appear in a traditional audit trail. No code changed. No deployment happened. The application is behaving exactly as designed — it reads its instructions from the database and follows them. The instructions just aren't the original ones anymore.

This isn't hypothetical. The McKinsey breach demonstrated that production AI systems at major enterprises are storing behavioral configuration alongside user data in standard relational databases, behind the same authentication (or lack of it) that protects everything else.

The Broader Pattern

This is the third major incident in recent months where an API security failure in an AI system led to consequences well beyond a typical data breach. In each case — including reported distillation attacks and session takeover incidents at other firms — the underlying vulnerability wasn't novel. What was new was what those vulnerabilities enabled in an AI-specific context.

SQL injection remains one of the most frequently detected threat types across monitored APIs, decades after the exploit class was first documented. Enterprises building AI-native systems are deploying them with the same security debt that plagued their pre-AI APIs, plus entirely new attack surfaces — system prompts, RAG pipelines, model parameters — that traditional security tooling was never built to monitor.

McKinsey's Response

CodeWall sent its disclosure email to McKinsey's security team on March 1, 2026. The CISO acknowledged receipt and requested detailed evidence the following day. Patches for the unauthenticated endpoints were deployed shortly after, the development environment was taken offline, and public API documentation was restricted.

McKinsey stated there was no evidence that unauthorized parties had accessed client data.

What This Means for Anyone Building AI Platforms

The McKinsey breach will be categorized as an "enterprise AI security incident" in most analyses, but the root cause is older and simpler than that framing suggests.

A production system had 22 endpoints that skipped authentication. One of those endpoints had a SQL injection flaw in a place that scanners don't typically check. The database it connected to also held the AI system's behavioral configuration.

Three priorities stand out for teams building or operating AI platforms:

First, enforce authentication everywhere. Twenty-two unauthenticated endpoints in a system handling confidential data is a governance failure that any API inventory review would surface. Every endpoint needs authentication — no exceptions.

Second, separate AI configuration from user data. System prompts, RAG settings, and model parameters should not live in the same database as user records. They need stricter write controls and dedicated change logging.

Third, monitor API behavior in production. The blind SQL injection generated a distinctive pattern — 15 iterative requests to the same endpoint, each with modified key names, each producing error responses. That sequence doesn't look like legitimate user behavior. Sequential ID-based requests across user accounts (the IDOR exploitation) produce equally recognizable access patterns. Detection in production gives you a second line of defense when static analysis and scanners miss something.

The lesson from this breach is uncomfortable in its simplicity: if your AI platform stores its configuration in a relational database — and most do — then your AI security posture is only as strong as your database security. It's an old problem with entirely new consequences.

‍