McKinsey's internal AI platform, Lilli, was compromised in a controlled security test by a startup called CodeWall. Their autonomous AI agent found a very old kind of bug in a very modern system and, within a couple of hours, reportedly had full read-write access to a production database containing extremely sensitive client data, and lots of it.
The story is striking not because it involves some novel AI vulnerability. It is striking for almost the opposite reason.
A decades-old web security flaw was sitting inside a flagship enterprise AI platform that tens of thousands of employees rely on daily. An automated agent found it quickly and cheaply. And the scale of what sat behind that vulnerability illustrates how much strategic information modern companies now concentrate inside internal AI systems. And how vulnerable it can be if not set up properly.
What follows is less a story about McKinsey specifically than about the security posture of the entire emerging category of "enterprise AI copilots."
What got "hacked," exactly?
McKinsey has spent the last few years promoting Lilli, its internal generative AI platform used by more than forty thousand employees. The system sits on top of the firm's accumulated knowledge base: decades of research, frameworks, and client work. Public descriptions suggest the platform indexes well over one hundred thousand internal documents and sees hundreds of thousands of prompts each month. [1]
Usage appears to be widespread. Roughly seventy percent of the firm reportedly interacts with the system in some form.
Lilli is therefore not a novelty chatbot tucked inside an innovation lab. It is closer to an operating layer for the firm's internal knowledge. Consultants use it to search past project work, summarize internal research, draft presentations, and assemble material that eventually finds its way into client deliverables.
CodeWall, a security startup building what it calls an autonomous offensive-security agent, decided to test Lilli under McKinsey's public responsible disclosure policy. The agent was given minimal starting information: a domain name and instructions to probe the system without credentials or human guidance.
Within roughly two hours and about twenty dollars (!) of API usage, the agent had mapped the platform's external attack surface, discovered publicly accessible endpoints, and chained together a series of weaknesses that culminated in read-write access to the production database behind Lilli. [2]
The speed is notable. The technique is not.
The old bug hiding in a shiny system
The vulnerability at the center of the incident is one of the most familiar problems in web security: SQL injection.
SQL injection dates back to the late 1990s. It has appeared on security risk lists such as the OWASP Top 10 for decades. Entire generations of developer education have been built around avoiding it.
Yet it still appears regularly in production systems.
According to CodeWall's disclosure and follow-up reporting, the attack path unfolded in a fairly methodical way.
First, the agent located publicly accessible API documentation describing more than two hundred endpoints associated with Lilli.
Most required authentication. Twenty-two did not.
One of those unauthenticated endpoints accepted search queries and wrote them into a database. The values inside the JSON request body were properly parameterized. The keys of that JSON object were not. They were concatenated directly into a SQL query string.
That distinction turned out to matter.
By crafting unusual JSON field names and observing the resulting database error messages, the agent was able to infer the structure of the underlying queries. The probing gradually escalated from generating harmless errors to retrieving live records.
This class of issue can be surprisingly hard for automated scanners to detect. CodeWall reported that common tools, including OWASP ZAP, initially missed the problem because it occurred in an unusual corner case: SQL injection through JSON field names rather than values. [3]
The AI component here played a role, but not in the way popular narratives tend to imagine.
The agent did not "break" the AI system through some clever jailbreak prompt. Instead, it behaved like a tireless junior security researcher. It crawled documentation, tried strange inputs, analyzed error messages, and repeated the process at machine speed until something worked.
A human red-teamer could have done the same thing. The difference is that an autonomous agent will happily run thousands of experiments without boredom or budget pressure.
What was exposed (at least in theory)
Once the agent obtained database access, the scope of what sat behind Lilli became visible.
CodeWall's disclosure, echoed by several outlets covering the incident, suggests the database contained extremely large volumes of internal material connected to the platform's operation.
The accessible data reportedly included:
- Approximately 46.5 million chat messages between McKinsey employees and the Lilli system
- Roughly 728,000 internal files, including PDFs, spreadsheets, slide decks, and Word documents
- Records tied to about 57,000 user accounts
- Around 3.7 million retrieval-augmented generation (RAG) chunks, the indexed fragments of documents used to generate answers
- System prompts and configuration settings governing how the AI behaved
- Metadata associated with millions of interactions between the platform and external AI APIs
In addition, CodeWall claims the agent could chain the injection vulnerability with an insecure direct object reference issue. That allowed it to view individual user search histories and identify what employees were actively working on.
It is important to distinguish between data that was technically accessible and data that was actually exfiltrated.
The technical write-up indicates the agent retrieved real records as proof of access. But the disclosure understandably emphasizes worst-case exposure scenarios. CodeWall also has a commercial incentive to demonstrate the effectiveness of its product.
Still, the underlying point is difficult to dismiss. If a production database containing tens of millions of internal AI conversations is reachable through a query, the practical distinction between "exfiltrated" and "easily exfiltrated" becomes somewhat academic.
McKinsey's response
McKinsey's public response has been relatively consistent across multiple reports.
According to company statements, the firm was notified through its responsible disclosure channel in early March 2026. Engineers disabled the exposed endpoints, restricted public API documentation, and took the affected environment offline within hours.
A third-party forensics firm was then engaged to review the incident. That investigation reportedly found no evidence that client data or confidential client information was accessed by CodeWall or by any other unauthorized party. [4]
The wording is typical of incident-response disclosures. It signals that investigators did not identify concrete signs of data theft. It does not necessarily rule out every theoretical path the vulnerability might have enabled.
In other words, this appears to have been a near-miss rather than a confirmed breach.
But it was a near-miss involving a system that aggregates a remarkable amount of institutional knowledge.
The quiet star of the story: prompts
One aspect of the disclosure deserves more attention than it has received.
The same database that stored chat logs and files also contained system prompts and AI configuration data.
Those prompts effectively function as the control layer of an enterprise AI system. They define how the model answers questions, what policies it enforces, how it cites sources, and what requests it refuses.
With write access to the database, an attacker could theoretically modify those prompts directly.
That opens the door to several subtle attack scenarios.
An adversary might adjust prompts so that the system quietly biases financial analysis or strategic recommendations. They could weaken guardrails, allowing the assistant to answer questions it previously declined. Or they could embed instructions that cause the model to leak fragments of internal documents inside otherwise ordinary responses.
Because prompt configuration often lives outside the traditional software deployment pipeline, these changes might look like minor configuration edits rather than code modifications. Monitoring systems may not treat them as suspicious events.
In practice, that means the behavior of the AI system itself can become an attack surface.
Enterprise AI architectures increasingly treat prompts, embeddings, and knowledge-base indices as operational metadata. In reality, they function more like source code for the system's reasoning process.
The structural problem with enterprise AI platforms
Viewed from a distance, the McKinsey episode looks less like a unique failure and more like an early illustration of a broader pattern.
Many organizations are currently building internal AI systems that resemble Lilli in several ways.
They sit on top of large proprietary knowledge bases. They expose APIs so other internal tools can interact with them. They evolve quickly as new use cases appear.
At the same time, they accumulate an enormous amount of sensitive operational data: internal strategy discussions, pricing models, draft reports, project documents, and the entire conversational history of employees interacting with the system.
In effect, companies are concentrating vast volumes of institutional knowledge inside a single searchable interface.
From a productivity perspective, this is powerful. From a security perspective, it creates an unusually attractive target.
Historically, sensitive knowledge was fragmented across document systems, email archives, and internal repositories. Access patterns were messy and inconsistent.
Enterprise AI platforms unify all of that information into a single environment designed explicitly for retrieval.
If an attacker gains access to that environment, the payoff is correspondingly large.
The rise of agentic attackers
There is another dimension to the story that security teams are beginning to grapple with.
The CodeWall agent did not exploit a mysterious new weakness in large language models. It simply automated the tedious work of reconnaissance and experimentation.
But that automation changes the economics of security testing.
Traditional penetration tests involve skilled human researchers exploring an application for a limited period of time. Autonomous agents can explore the same surface continuously, probing thousands of edge cases without fatigue.
They read documentation, enumerate endpoints, construct unusual inputs, and learn from error responses.
The result is not superhuman intelligence. It is relentless persistence.
Systems that were "secure enough" against sporadic manual probing may behave differently when confronted with agents capable of performing millions of micro-experiments.
This dynamic has been visible in other domains for years. Spam filtering, fraud detection, and advertising systems all experienced similar shifts once automated adversaries entered the picture.
Enterprise software is now beginning to face the same environment.
A few practical implications
The McKinsey incident highlights several lessons that apply broadly to organizations building internal AI tools.
First, internal AI systems should be treated as critical infrastructure. When a platform becomes the default interface for knowledge work across a company, it stops being an experimental project.
Second, prompt configuration and knowledge-base indices deserve the same protection as application code. They shape the behavior of the system and can be manipulated if left unguarded.
Third, chat logs and usage telemetry are not harmless metadata. They contain strategy discussions, financial analysis, and operational decisions. In many organizations they may be as sensitive as the documents they reference.
Fourth, security tooling still struggles with unusual application patterns. Traditional scanners may miss vulnerabilities that arise from creative uses of JSON structures, query generation, or AI-specific pipelines.
Finally, security assumptions built around manual attackers are aging quickly. Automated agents can explore attack surfaces far more systematically than humans typically do.
Finally finally - a key lesson here is to fight fire with fire. If LLMs have lowered the cost to scan and detect vulnerabilities, the same benefit is available to teams building these systems. Teams should "red team" their own production systems regularly, not just with one frontier model, but different ones - probing and scanning. It literally costs cents or a few dollars to do so - and you may be surprised at what you find.
For example, I am building an application (VerbaGPT) that lets users ask questions of databases. Here is me simply pointing the LLM at this attack and asking it to scan my code repo for any similar vulnerabilities. It did an extremely thorough scan, which also shows how IT security is going to look very different in the imminent future. Not a rigid checklist, but a dynamic, evolving, never-ending scan.
From one perspective, McKinsey handled the situation responsibly. The firm maintained a disclosure channel, responded quickly once notified, and engaged external investigators.
From another perspective, the episode reveals how fragile some modern AI stacks still are.
A flagship internal platform at a firm known for advising corporations on risk and transformation operated for years with a vulnerability class that security engineers have been warning about since the early days of the web.
It took an autonomous agent, pointed at a domain with minimal instructions, to demonstrate how much could sit behind a single overlooked query.
The technology may be new. The underlying lesson is not.
Footnotes
- McKinsey, "Rewiring the way McKinsey works with Lilli," 2023.
- CodeWall, "How We Hacked McKinsey's AI Platform," March 2026.
- OWASP Foundation, OWASP Top 10 Web Application Security Risks.
- Reporting on the disclosure in outlets including The Register and Inc. describing McKinsey's response and remediation steps.