CyphrQ
Menu

McKinsey Lilli Security Test: What a Red-Team Agent Reached

In 2026 CodeWall's AI agent tested McKinsey's Lilli chatbot under its disclosure policy. What it reported, what McKinsey said, and what to check.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

Incident: February 202610 min read

The McKinsey Lilli security test was a red-team exercise run under McKinsey's public disclosure policy, not a criminal breach. In early 2026, the security firm CodeWall pointed an autonomous AI agent at McKinsey's internal chatbot, Lilli, and says it reached the production database behind it in about two hours. CodeWall reported the problem to McKinsey. McKinsey says it fixed the issues within hours and found no evidence that client data was accessed. Neither company claims the data was misused.

This is a case file. It sets out what the testers published, what McKinsey said, and what is still unverified. It ends with what to check on your own internal AI tools.

One note on "authorised". CodeWall says its agent chose McKinsey because the firm publishes a responsible disclosure policy, and that it stayed within it. No McKinsey statement found for this post describes the test as authorised in advance. So this post uses the word in the sense the testers do: a good-faith test under a public disclosure policy, with the findings reported to the company, not a theft.

Case file

Field Value
Organisation McKinsey & Company (internal AI platform "Lilli")
Type Good-faith red-team test: an autonomous AI agent run by CodeWall under McKinsey's public responsible disclosure policy, per CodeWall. Not a criminal breach
Region Firm-wide internal platform; CodeWall says over 70% of McKinsey's 43,000+ employees use it (CodeWall)
Test date 28 February 2026: CodeWall says the agent found the flaw and confirmed the full chain that day (CodeWall)
Disclosed Emailed to McKinsey's security team on 1 March 2026; public write-up on 9 March 2026 (CodeWall)
What the testers say they reached "Full read and write access to the entire production database" within 2 hours (CodeWall)
Data types (CodeWall's figures) 46.5 million chat messages; 728,000 files; 57,000 user accounts; 384,000 AI assistants; 94,000 workspaces; 95 system prompt and model configurations
Penalty/action None reported. No regulator action found
Status Fixed, per both parties. CodeWall's figures are not independently verified (Promptfoo)

What was the McKinsey Lilli security test?

Lilli is McKinsey's internal generative AI platform. Staff use it to ask questions and search the firm's knowledge. Behind a chat window like that sit ordinary things: web APIs, a database, stored documents and the instructions that shape the model's behaviour.

CodeWall is a security startup that builds autonomous attack agents. It says its agent started with no credentials, no insider knowledge and no human in the loop. The only input was a domain name. The agent suggested McKinsey as a target, citing the firm's public disclosure policy (The Register).

CodeWall also calls the work "verification-only": it says it took the minimum access needed to confirm each issue and document it (CodeWall).

How did the AI agent get into Lilli's database?

According to CodeWall, the entry point was not the AI model. It was the plumbing around it (CodeWall):

  1. Public API documentation. The documentation was exposed and listed over 200 endpoints.
  2. Unauthenticated endpoints. Most endpoints required a login. Twenty-two did not.
  3. One endpoint that wrote user search queries. The values it received were handled safely. The JSON field names were joined straight into an SQL query.
  4. SQL injection. SQL injection is a flaw where text sent to an application ends up being run as part of a database command. CodeWall says its agent used fifteen rounds of probing to pull out data.

CodeWall adds that the common scanner OWASP ZAP did not flag the issue. That claim was not tested for this post, and there is no way to say how a different scanner would have fared.

Promptfoo, an AI security company that reviewed the write-up, describes it as "a familiar AppSec chain" and says "The model became the interface to a compromised application" (Promptfoo). That reading is worth keeping. Nobody tricked the chatbot into saying something it shouldn't.

CodeWall has not published the exact payloads, so outsiders cannot reproduce the steps. That is a sensible choice for a post like this one, and it is also why the figures below rest on the testers' word.

What did the testers say they could reach?

These are CodeWall's figures, as it states them (CodeWall):

Item CodeWall's figure
Time to full read and write access Within 2 hours
Chat messages 46.5 million
Files 728,000 (192,000 PDFs, 93,000 Excel, 93,000 PowerPoint, 58,000 Word)
User accounts 57,000
AI assistants 384,000
Workspaces 94,000
System prompts and AI configurations 95, across 12 model types
Document chunks used for retrieval 3.68 million

The last two rows matter most for AI teams. The system prompts are the instructions that steer the model. Because CodeWall reports write access, a person with the same access could in principle have changed those instructions. CodeWall's write-up raises that risk. It does not say anyone did it.

CodeWall also reports 27 findings in total. This post draws on the write-up, not the evidence behind each one.

What did McKinsey say about the Lilli test?

McKinsey told The Register that its "investigation, supported by a leading third-party forensics firm, identified no evidence that client data or client confidential information were accessed." It also said it fixed the issues CodeWall identified within hours of learning about them (The Register).

CodeWall's own timeline is consistent with a fast response. It says McKinsey's CISO acknowledged the report on 2 March 2026, and that the same day McKinsey patched the unauthenticated endpoints, took the development environment offline and blocked the public API documentation (CodeWall).

McKinsey also published a statement on its own site. This post quotes only the version The Register reported.

What is confirmed, and what is not?

Question Status as of 25 October 2026
Was there a test, and was it reported to McKinsey? Yes, per CodeWall, and McKinsey confirmed to The Register that it fixed the issues
Did the agent reach the production database? Testers' claim. Not independently verified
Were the 46.5 million messages and other figures accurate? Testers' claim. Payloads unpublished
Was client data accessed? McKinsey: no evidence, after a third-party forensic investigation
Was any data misused? No claim from either party

One gap remains. McKinsey's statement speaks to client data. No McKinsey statement found for this post says whether employee chat messages or system prompts were reached, so this post makes no claim either way.

What should enterprise AI teams learn from the Lilli security test?

Three lessons, none of them exotic.

The AI app is an application first. Most of the attack surface was web APIs and a database. A chatbot inherits every old weakness of the system it runs on.

Internal does not mean private. If an API documentation page or an endpoint is reachable from the internet, it needs to demand a login. Twenty-two endpoints that did not are enough.

What the AI stores is as sensitive as what it answers. Chat history, uploaded files and system prompts all sit in the same backend. A breach of that backend exposes all of them at once.

I'd add one thing about the testers. An agent that can chain these steps in hours changes who can run this kind of test, and how often. Defenders can use the same approach on their own systems, with permission.

Going deeper: for security and IT teams

Threat model. The attacker is anyone who can reach your API from the internet: no account, no insider knowledge. What they need is an unauthenticated endpoint that passes input into a database query. What they get is whatever that database account can read and write, which for a RAG backend (retrieval-augmented generation, where the model answers from your documents) tends to be chat history, file metadata, embeddings and prompt configuration together.

Mapping to OWASP. The entry chain is API security, not LLM security. In the OWASP API Security Top 10 2023, the relevant categories are API2 Broken Authentication, API8 Security Misconfiguration and API9 Improper Inventory Management. The last fits an API documentation page listing endpoints nobody had reviewed. CodeWall's write-up also names broken authorisation, which maps to API1 Broken Object Level Authorization; its evidence for that point is not public.

The LLM layer matters for the impact. In the OWASP Top 10 for LLM Applications 2025, the categories that describe what an attacker could reach once inside are LLM02 Sensitive Information Disclosure, LLM07 System Prompt Leakage and LLM08 Vector and Embedding Weaknesses. LLM06 Excessive Agency applies when the AI itself holds broad rights.

SQL injection without a classic parameter. The bug as CodeWall describes it is a useful reminder. Parameterised queries protect values, but, as the OWASP SQL Injection Prevention Cheat Sheet notes, parameter markers represent data values, "not table names, column names, or SQL keywords." If your code builds identifiers such as column names or JSON keys from user input, binding the values does not help. The cheat sheet's advice is to keep identifiers fixed in code, or map the user's choice to application-owned tokens and reject anything not on the list.

Controls with specifics.

  • Inventory every endpoint. Compare the API documentation to what is deployed, and treat any endpoint with no authentication requirement as a finding to justify in writing. Do not publish API documentation for internal systems to the internet.
  • Deny by default at the gateway. Require authentication on every route, and make exceptions explicit.
  • Least-privilege service accounts for RAG backends. The application's database account should not have write access to prompt and configuration tables unless a specific function needs it. Split read-only retrieval from the admin path that edits system prompts.
  • Separate stores. Keep chat history, uploaded files and vector indexes under different credentials, so one injection point does not reach all of them.
  • Protect the prompts. Treat system prompts as code: version them, restrict who can change them, and alert on changes.
  • Test the whole stack. Scope internal AI application tests to APIs, authentication, data stores and prompt storage, as well as jailbreaks. Don't rely on one scanner: CodeWall says OWASP ZAP did not flag this bug.

Detection and evidence. On the API side, log and alert on:

  • requests to endpoints that normally require authentication but arrive without it
  • database errors or unusual query shapes from the application account
  • unusually large or repeated reads of chat or file tables by one session
  • any write to a prompt or configuration table outside a change window

To prove a control works, run a test with permission: request every documented route without credentials and confirm each one returns a refusal.

What to verify or ask.

  • Which of our AI app endpoints answer without a login, and who signed that off?
  • What can the AI platform's database account write, and does it need to?
  • Do we have a disclosure policy, and a named person who reads reports sent to it?
  • When did we last test the APIs behind our internal AI tools, not only the model?

How can you test your own internal AI apps safely?

  1. List every AI tool your staff use, including ones built in-house, and who owns each.
  2. For each, list the APIs and data stores behind it, not just the chat window.
  3. Check that each endpoint requires authentication, and that documentation is not public.
  4. Review what the application's database account can read and write.
  5. Test with written permission, in a non-production copy where possible.
  6. Publish a disclosure contact, so a researcher's report reaches a person.

For how hidden instructions in content can steer an AI tool, see Prompt Injection Explained. For the permissions an AI agent should and should not hold, see AI Agent Security Risks at Work.

Learn more

Key takeaways

  • CodeWall, a security firm, ran an autonomous AI agent against McKinsey's Lilli chatbot in early 2026, citing McKinsey's public disclosure policy. It was a test reported to the company, not a criminal breach.
  • CodeWall says the agent reached full read and write access to the production database in about two hours, and reports 46.5 million chat messages and 728,000 files. These figures are the testers' own and are not independently verified.
  • McKinsey says it fixed the issues within hours and that a third-party forensic investigation found no evidence of client data being accessed. No one claims data was misused.
  • The entry point was ordinary API and SQL weakness: unauthenticated endpoints and a query built from unsafe field names.
  • The cheapest checks: authenticate every endpoint, keep API documentation private, give RAG backends least-privilege accounts, and test the application, not just the model.

Sources