McKinsey's Lilli Went Public on 9 March. The Record Carries No Harm.

On 9 March 2026, the security startup CodeWall published its account of how an autonomous agent it built reached full read and write access to the production database behind Lilli, McKinsey & Company's firmwide AI assistant, in roughly two hours and without a single credential. The intrusion itself happened on 28 February; what this entry in the AI incident archive records is the day it became public. According to CodeWall, the database it reached held 46.5 million chat messages in plaintext, 728,000 files, 57,000 user accounts and the 95 system prompts that govern how Lilli answers — and those prompts sat in the same database the agent could write to. The people in the data were McKinsey's own staff: the firm says 72 percent of its employees, upwards of 40,000 people, use Lilli, which handles more than 500,000 prompts a month. The full entry, with its severity and confidence grades and the neighbouring records it sits among, is in the Orca AI Incident Archive.

That opening is a compression of two very different kinds of claim, and the archive entry is careful about the difference. It grades the record as an incident, confidence A, not disputed, severity high, region US, type INFRA — infrastructure, not a model failure. It also records no real harm. That last field is the one worth reading twice, because it does not mean the exposure was harmless. It means that no harm was established on the record, and the article below separates what two parties agree on from what rests on one company's account of its own research.

Why the disclosure is its own dated event

The archive's summary for this entry points back to 28 February 2026, the day CodeWall's agent found the flaw, and the archive carries that earlier date as a separate record. The split is not bureaucratic. Before 9 March, the only parties who knew what had happened inside Lilli were McKinsey and the researcher who had told it. After 9 March, the shape of the failure, the firm's response and the claim about what was in the database were all on the public record, where other security researchers could argue with them.

Lilli is not a side project. The Register put its rollout at July 2023, over chat, document analysis and retrieval across the firm's internal research. CodeWall's writeup, which also records where the name comes from — the first professional woman the firm hired, in 1945 — describes more than 100,000 internal documents behind it. The Register, reporting the disclosure the same day, put adoption at 72 percent of employees and volume above 500,000 prompts a month — figures McKinsey has published itself in a public case study of the platform.

How the agent got in

CodeWall's account begins with documentation, not exploitation. Its agent found Lilli's API documentation publicly exposed and fully written up: more than 200 endpoints in all, most requiring authentication, and 22 that did not. One of those unauthenticated endpoints wrote user search queries into the database. The values were parameterised properly, but the JSON keys — the field names — were concatenated straight into SQL.

The agent noticed because database error messages reflected those JSON keys back verbatim. CodeWall says OWASP's ZAP scanner did not flag the issue, and that the agent then ran fifteen blind iterations, each error message teaching it a little more about the shape of the query, until live production rows began coming back. From there it chained the injection with an object-level authorisation flaw to read individual employees' search histories. The company describes the whole run as fully autonomous, from target selection to report, with no credentials and no human in the loop. Its founder and chief executive, Paul Price, told The Register that the process was "fully autonomous from researching the target, analyzing, attacking, and reporting."

What CodeWall says was inside

Every figure in this section comes from CodeWall's 9 March writeup. No payloads were published, so none of it can be reproduced or independently counted — a limit the next section deals with.

• 46.5 million chat messages, stored in plaintext, covering strategy work, client engagements, financials and mergers and acquisitions.

• 728,000 files, of which the writeup itemises 192,000 PDFs, 93,000 Excel spreadsheets, 93,000 PowerPoint decks and 58,000 Word documents — 436,000 in total, leaving the remaining 292,000 unclassified in the same sentence.

• 57,000 user accounts, 384,000 AI assistants and 94,000 workspaces, which CodeWall describes as the full organisational structure of how the firm uses AI internally.

• 95 system prompts and model configurations across 12 model types, showing how the assistant was instructed, what guardrails existed and which models sat underneath it.

• 3.68 million retrieval-augmented generation document chunks, with S3 storage paths and internal file metadata — the knowledge base feeding the assistant.

• 1.1 million files and 217,000 agent messages moving through external AI APIs, including more than 266,000 vector stores on OpenAI's platform.

The finding CodeWall treats as the headline is not the injection but where the injection landed. Lilli's system prompts were rows in the same database the agent could write to, which means an attacker with the same access could have rewritten the assistant's instructions with a single UPDATE statement wrapped in a single HTTP call — no deployment, no code change, no file on disk to diff. CodeWall says its own testing was verification-only: it read, it did not write, and it says no production service was disrupted.

What McKinsey said the same day

A McKinsey spokesperson told The Register on 9 March that the firm fixed all of the issues CodeWall identified within hours of learning about them. "Our investigation, supported by a leading third-party forensics firm, identified no evidence that client data or client confidential information were accessed by this researcher or any other unauthorized third party," the spokesperson said, adding that "McKinsey's cybersecurity systems are robust."

Silicon UK reported the same position on 13 March, in Matthew Broersma's account: McKinsey said it was "recently alerted to a vulnerability related to our internal AI tool, Lilli, by a security researcher," that it "promptly confirmed the vulnerability and fixed the issue within hours," and that no client data or client confidential information was accessed. That report also notes that Price is CodeWall's only employee, a detail worth carrying because it cuts both ways — a one-person research outfit found in two hours what the firm's own scanners did not, and a one-person outfit is also selling the tool that found it.

Two accounts of the fix, a day apart

CodeWall's own disclosure timeline runs like this: the agent identifies the SQL injection and begins enumerating the production database on 28 February; the full chain is confirmed the same day with 27 findings documented; a responsible-disclosure email goes to McKinsey's security team on 1 March with a high-level impact summary; the firm's chief information security officer acknowledges receipt and asks for detailed evidence on 2 March; and on 2 March all unauthenticated endpoints are patched and verified, the development environment is taken offline and the public API documentation is blocked. Public disclosure follows on 9 March.

McKinsey's account is that the fix came within hours of being told. CodeWall's timeline puts the patch on the day after its disclosure email. Both are on the record. Neither party has reconciled them, and this article does not try to: the difference is between a same-day fix and a next-day one, and the sequence that matters — told, then patched, then published — is not in dispute.

Established, single-source, and the gap between them

Established, agreed by both parties: there was an unauthenticated weakness in Lilli's public API surface; it was found by an outside security researcher rather than an insider; McKinsey confirmed it and patched it; the unauthenticated endpoints were closed, the development environment was taken offline, and the public API documentation was blocked.

Single-source, from CodeWall: every count above, the two-hour timeline, the fifteen blind iterations, the 27 documented findings, and the claim that the prompts were writable through the same injection. None of it is disproven. None of it has been independently verified either, because the payloads that would let someone check were not published, and Price declined to give The Register the exact prompts his team used.

Promptfoo, the AI security firm, published an assessment on 10 March that states the limit precisely: the public record "does not independently prove every reported row count or every step of exploitation," though it does support the shape of the incident. That is the correct reading of the material available. The class of bug is reconstructable; the scale is testimony.

The harm the record does not carry

This is where the archive's grading does real work. A two-hour path to read and write access inside the production database of a firmwide assistant sounds like a harm record, and the archive records none. The field rests on three things: McKinsey's statement that a third-party forensic investigation found no evidence client data was accessed; CodeWall's statement that its testing was verification-only and disrupted nothing; and the absence, in the coverage reviewed for this article, of any contradicting finding.

It does not rest on an independent technical audit, a regulator's determination or a breach notification. No CVE identifier was assigned in any coverage reviewed — Lilli is internal software rather than a distributed product, and no advisory names one — and no supervisory authority appears to have opened a matter. No public evidence surfaced, in the coverage reviewed for this article, that the data was used, sold or further exposed. That is what "no real harm recorded" means here: an evidence statement about a record, not a finding that the exposure was safe.

The gap matters because the interesting risk was prospective. Read access exposes what was there. Write access to the prompt layer exposes what the assistant would say next — poisoned advice, guardrail removal, confidential material folded into an answer a consultant then pastes into a client document. CodeWall described those consequences as available to anyone with the same access. Nobody has shown they were taken up. Both statements can be true at once: the capability was real, and the harm was not realised on the evidence anyone has published.

Why it is filed as infrastructure, not as a model failure

The archive tags this record INFRA, and the technical record supports the tag. Nothing in CodeWall's account required tricking the model. There was no jailbreak, no prompt injection from a document, no adversarial input the assistant was asked to swallow. The entry point was exposed documentation, a missing authentication check and unsafe SQL construction; the model was simply the most valuable thing behind the door.

Promptfoo's 10 March analysis makes the same distinction from the defensive side: Lilli "looks, on the public record, like an application-security incident that reached an AI system, not a model jailbreak," and much of what is called AI security is still software security, data security and configuration governance. The AI-specific part was the blast radius, not the breach — because prompts, routing rules and retrieval settings were mutable application data, database write access became the ability to change the assistant's behaviour without touching code.

What changed afterwards

The concrete changes are the ones both parties describe: the unauthenticated endpoints were closed and verified, the development environment was taken offline, and the public API documentation was blocked. McKinsey has said it found the vulnerability, confirmed it and fixed it, and its public position is that no client data was accessed.

What did not change is the wider exposure this incident described. CodeWall's writeup ends by arguing that prompts are stored in databases, passed through APIs and cached in config files, and that they rarely get access controls, version history or integrity monitoring — which is a claim about an industry, not a finding about McKinsey, and should be read as the argument of a company selling continuous automated testing. The firm is in early preview and looking for design partners; the disclosure doubles as a demonstration.

What the record leaves is narrower and more useful than the argument. A firmwide assistant, a production database, two hours, no credentials, and a harm line that reads false because the two parties with access to the facts both say the data was not used. The counts belong to one of those parties. The vulnerability belongs to both.