McKinsey Lilli Breach: Old Vulnerability, New AI Risk

On March 9, 2026, security startup CodeWall published findings from a red-team exercise in which an autonomous AI agent gained full read-and-write access to the production database behind McKinsey's internal AI platform, Lilli, in approximately two hours. The claimed exposure includes 46.5 million chat messages, 728,000 files, 57,000 user accounts, and 95 writable system prompts. McKinsey states it patched the identified issues within hours of disclosure and that its forensic investigation found no evidence of unauthorized access to client data. This analysis examines what has been publicly reported, where claims diverge, and what the incident, regardless of disputed scope, reveals about enterprise AI security.

Key Takeaways

• CodeWall claims its AI agent accessed McKinsey's Lilli database via an unauthenticated SQL injection, a vulnerability class documented since 1998 and in the OWASP Top 10 since 2003
• The vulnerability was in JSON key names concatenated into SQL, not parameter values, a vector that standard tools like OWASP ZAP did not flag, according to CodeWall
• McKinsey states it patched all unauthenticated endpoints within hours of the March 1 disclosure and that no client data was accessed by unauthorized parties
• SQL injection accounts for approximately 19.52% of all critical and high-severity web application vulnerabilities (Edgescan 2025)
• Only 24% of ongoing GenAI projects incorporate security considerations (IBM)

What Happened

McKinsey launched Lilli in July 2023 as an internal generative AI platform for search and analysis across decades of proprietary research. According to McKinsey, 72% of the firm's employees, upwards of 40,000 people, use Lilli, which processes more than 500,000 prompts per month.

CodeWall, a red-team security startup that uses AI agents to continuously test customer infrastructure, states that its autonomous agent selected McKinsey as a target based on the firm's public responsible disclosure policy and recent updates to Lilli. The agent operated without credentials, insider knowledge, or human guidance.

The timeline, based on CodeWall's published account: the agent identified the SQL injection vulnerability on February 28, 2026. CodeWall sent a responsible disclosure email to McKinsey's security team on March 1, including a high-level impact summary. McKinsey states it patched all unauthenticated endpoints, took the development environment offline, and blocked public API documentation by March 2.

What remains unresolved: CodeWall claims access to 46.5 million chat messages, 728,000 files, and 3.68 million RAG document chunks. McKinsey's statement, supported by a third-party forensics firm, asserts that no client data or confidential information was accessed by CodeWall or any other unauthorized party. These two positions have not been publicly reconciled.

How It Happened

The technical chain CodeWall describes is straightforward and, according to independent security analyst Edward Kiledjian, "plausible and technically sound."

The agent found publicly exposed API documentation covering over 200 endpoints. Most required authentication. Twenty-two did not. One of those unauthenticated endpoints accepted JSON payloads and wrote user search queries to a database. The parameter values were safely parameterized, but the JSON key names, the field names themselves, were concatenated directly into SQL.

This is a meaningful technical detail. Most automated security scanning tools, including OWASP ZAP, test parameter values for injection. JSON key injection is a less common vector and falls outside the scope of standard automated testing. CodeWall states that OWASP ZAP did not detect the vulnerability.

When the agent submitted manipulated JSON keys, the database returned error messages that reflected the injected content. The agent used these error messages to enumerate the database schema over approximately 15 iterations, eventually extracting live production data.

The core vulnerability, SQL injection through unsanitized user input, has been documented since a 1998 Phrack Magazine article. It entered the OWASP Top 10 in 2003 and has remained there since. The prevention is well established: parameterized queries, input validation, and separating data from commands. The Edgescan 2025 Vulnerability Statistics Report found that SQL injection accounts for 19.52% of all critical and high-severity vulnerabilities discovered through their platform.

Old Vulnerability, Different Consequences

The technique is not new. The attack surface it hit is.

The distinction between SQL injection against a traditional database and an enterprise AI platform is qualitative, not just quantitative.

Factor	Traditional database (2014)	Enterprise AI platform (2026)
Data type exposed	Structured records: names, emails, transaction histories	Unstructured conversational data: strategy discussions, M&A deliberations, work-in-progress reasoning
Sensitivity classification	Classifiable by field type and access level	Difficult to classify, conversations capture implicit assumptions and reasoning not present in structured records
Write access impact	Data modification, record tampering	System prompt manipulation, silently altering how the AI responds across the entire organization
Blast radius	Bounded by database scope and record count	Amplified by platform adoption, 72% of workforce using a single tool means one vulnerability exposes collective working intelligence

People interact with internal chatbots the way they interact with colleagues, in unstructured, conversational language that captures reasoning, assumptions, and work-in-progress thinking. If CodeWall's claims are accurate, the exposed data would include strategy discussions, M&A deliberations, and client engagement details in plaintext.

Additionally, CodeWall reports that Lilli's system prompts, the instructions governing how the AI responds, were stored in the same database. Because the SQL injection allowed write access, an attacker could theoretically modify those prompts: altering how Lilli answers questions, what guardrails it follows, how it cites sources, or what it refuses to do. CodeWall describes this as requiring nothing more than a single SQL UPDATE statement in a single HTTP call.

Rewriting system prompts is not data theft, it is silent manipulation of a decision-support tool used across an organization. The distinction matters for how organizations assess risk in their own AI deployments.

What This Means for Organizations Running Internal AI

This incident is specific to McKinsey and Lilli, but the structural pattern is not. According to Thunderbit (2026), 78% of global enterprises now run AI chatbots in at least one internal workflow. Gartner predicts that by 2027, more than 40% of AI-related data breaches will stem from improper use of generative AI. And according to IBM, only 24% of ongoing GenAI projects incorporate security considerations.

Five factors contributed to the exposure CodeWall describes, none of which are unique to McKinsey:

Risk factor	What happened at McKinsey	Countermeasure
Unauthenticated API endpoints	22 endpoints required no authentication, including one that wrote user data to a database	Require authentication on every endpoint that reads or writes data, no exceptions
SQL injection in production	JSON key names concatenated into SQL without parameterization, live for over two years	Parameterized queries for all inputs, including non-standard vectors like JSON keys
System prompts in application database	AI behavioral instructions stored alongside user data	Isolate system prompts in a separate, restricted data store with integrity monitoring
Plaintext conversational data	46.5 million chat messages stored without encryption at rest (if claims are accurate)	Encrypt conversational data at rest and apply data classification before storage
Concentration risk	72% of workforce on a single platform creates a single point of failure	Segment data access, apply zero-trust architecture, limit blast radius through compartmentalization

None of these are exotic. Each has an established countermeasure. The challenge is that many organizations deploying internal AI platforms are applying them at speed without extending their existing security controls to cover the new attack surface these platforms create.

A Note on Sources and Verification

This analysis is based entirely on publicly available information: CodeWall's published blog post (March 9, 2026), independent reporting by Jessica Lyons at The Register, and McKinsey's public response. Independent commentary by Edward Kiledjian provides additional technical analysis. Where claims are made by CodeWall, they are attributed to CodeWall. Where McKinsey disputes or qualifies those claims, that is noted. The scope of actual data exfiltration versus theoretical access has not been independently verified.

The full Intelligence Brief covers the complete attack chain diagram, a comparative risk matrix for traditional versus AI platform SQL injection impact, an enterprise AI platform security checklist, and a board-level risk impact framework.