On March 9, 2026, security startup CodeWall published a report that sent shockwaves through the tech and consulting world: their autonomous AI agent had breached Lilli - McKinsey & Company’s internal AI platform - in just two hours, gaining full read-and-write access to a production database holding tens of millions of records.
The headlines wrote themselves. “AI agent hacks McKinsey.” “AI vs. AI.”
But if you strip away the buzzwords, the story is far less futuristic - and far more alarming for a different reason.
What Actually Happened
Lilli is McKinsey’s purpose-built generative AI platform, launched in 2023 and adopted by over 70% of its 43,000+ employees. It processes more than 500,000 prompts a month. By any measure, it’s a high-value target.
CodeWall’s agent - with no credentials, no insider knowledge, and no human guidance - mapped Lilli’s attack surface and discovered that over 200 API endpoints were publicly documented, and 22 of them required no authentication whatsoever.
One of those unprotected endpoints had a flaw: while the values in its JSON payloads were properly parameterized against SQL injection, the JSON field names (keys) were concatenated directly into SQL queries. That’s it. That was the door.
The agent iterated 15 times through blind SQL injection, guided by overly verbose error messages that reflected the keys verbatim - until live production data started flowing back. It then chained this with an IDOR (Insecure Direct Object Reference) vulnerability to access individual employee search histories.
The result was staggering:
- 46.5 million chat messages - in plaintext
- 728,000 files - PDFs, spreadsheets, presentations
- 57,000 user accounts
- 3.68 million RAG document chunks - decades of proprietary McKinsey research and frameworks
- 95 AI model configurations with full system prompts
- 384,000 AI assistants and 94,000 workspaces
And because it was write access too, an attacker could have silently rewritten Lilli’s system prompts - the instructions that control how the AI behaves for every consultant in the firm - without leaving a trace.
This Was Not an AI Vulnerability
SQL injection has been in the OWASP Top 10 since the list was created. It is one of the oldest, most documented, most preventable vulnerability classes in software security. Every junior developer learns about it. Every security scanner claims to detect it.
There was no novel AI exploit. No adversarial machine learning. No prompt injection. No jailbreak. The AI platform was not compromised because it was AI. It was compromised because basic input sanitization was missing on a public-facing endpoint - the same way a banking app or an e-commerce site could be compromised.
The agent that found the vulnerability was AI-powered, yes. But it automated what any competent penetration tester would have done manually. It just did it faster and without coffee breaks.
So Why Does This Feel Different?
Because AI changes the blast radius, not the attack vector.
Traditional applications store transactional data - orders, accounts, session tokens. An AI platform like Lilli stores everything: the questions people ask, the documents they analyze, the strategies they discuss, the reasoning they rely on. It’s a concentration of intellectual output at a scale that didn’t exist before.
When you breach a CRM, you get customer records. When you breach an enterprise AI platform, you get the way an entire organization thinks.
That’s what makes this story significant - not because AI was the vulnerability, but because AI was the amplifier. The same old bug, behind a door that now opens into a vault a thousand times larger than anything we’ve seen before.
The Negligence Question
McKinsey is not a startup with three engineers and a free-tier cloud account. It is a firm with world-class technology teams, significant security investment, and the resources to do things properly. It advises Fortune 500 companies on topics including - yes - cybersecurity and AI risk.
The facts are uncomfortable:
- A 25-year-old vulnerability class went undetected
- 22 endpoints left without authentication on a platform handling ultra-sensitive data
- The platform ran in production for over two years without this being caught
- McKinsey’s own internal scanners failed to identify the issue
- Chat messages were stored in plaintext with no application-level encryption
- System prompts - the instructions controlling AI behavior for 43,000 people - were stored in the same database without access controls, versioning, or integrity monitoring
This wasn’t a sophisticated zero-day exploit. This was a failure of basic security hygiene at an organization that has both the obligation and the resources to get it right.
The Real Lesson
The narrative the industry wants to tell is: “AI is so new and so complex that these things are inevitable.”
The narrative the evidence actually supports is: Organizations are deploying AI platforms without applying the same security rigor they would - or should - apply to any other production system.
As The Register reported, AI platforms are not magical. Under the hood, they are web applications with APIs, databases, authentication layers, and input handling - all the same components we’ve spent decades learning to secure. The difference is that these platforms are being shipped at startup speed inside enterprise organizations, often by teams more focused on model performance than on security fundamentals.
The McKinsey incident exposes a pattern that will repeat:
- AI concentrates data - conversations, documents, reasoning, and institutional knowledge flow into a single system
- AI inherits traditional vulnerabilities - because the infrastructure underneath is the same infrastructure we’ve always built
- AI amplifies the consequences - a single breach now exposes not just records, but the entire intellectual fabric of an organization
- The prompt layer is unprotected - system prompts are the new crown jewels, yet they sit in databases without the access controls, versioning, or monitoring we’d demand for any other critical asset
What Should Change
For organizations deploying AI platforms
Treat your AI platform like any other production system. Penetration testing, input validation, authentication on every endpoint, encryption at rest - none of this is optional just because the word “AI” is on the label. The OWASP Top 10 exists precisely for this.
Protect the prompt layer. System prompts need access controls, version history, integrity monitoring, and change detection. They control what your AI says to your people. Guard them accordingly.
Audit your blast radius. Understand exactly how much data flows through your AI platform and what a breach would expose. If the answer makes you uncomfortable, your security posture needs to match that discomfort.
For the industry
Stop framing every AI security incident as an “AI problem.” When the root cause is a classic web vulnerability, say so. Mystifying the issue delays the fix.
Recognize that AI is an amplifier. The threat model hasn’t fundamentally changed. The consequences of failure have.
Final Thought
Old vulnerability. New blast radius. The AI is the amplifier, not the cause.
The McKinsey hack is a wake-up call - not because AI is uniquely dangerous, but because we are uniquely careless about the infrastructure we build around it. We know how to prevent SQL injection. We’ve known for a quarter of a century. The question is whether we’ll apply what we already know to the systems that now matter most.
McKinsey patched the endpoints within two days of receiving the disclosure. That’s commendable response time. But the real question isn’t how fast you patch - it’s why the patch was needed in the first place.
Sources: Financial Times, CodeWall research disclosure (March 9, 2026), The Register, Inc. Magazine.
By: Cesar Rosa Polanco - Based on a real case, with editorial support from artificial intelligence.