By Folu Adebayo
The firm that teaches the Fortune 500 how to deploy AI safely just learned, in 120 minutes, that it had not been listening to its own advice.
On the evening of February 28, 2026, an autonomous AI agent built by a little-known security firm called CodeWall was pointed at the open internet and given a single instruction: pick a target and probe it. It chose McKinsey & Company. Two hours later, the agent had read-and-write access to Lilli, the consulting giant’s internal generative AI platform the very system that 72% of McKinsey’s 43,000 employees use daily, that processes more than half a million prompts a month, and that the firm has been quietly using as a showcase for clients buying its AI advisory services.
The damage surface, when finally disclosed in March, was almost theatrical in its scale: 46.5 million chat messages, 728,000 sensitive file names, 57,000 user accounts, and most consequentially 95 system prompts, the behavioural DNA that governs how Lilli answers every question put to it.
The exploit? SQL injection. A class of vulnerability first documented in 1998. A bug so old it predates the iPod.
This is not a story about a clever hack. It is a story about what happens when the most sophisticated buyers of technology in the world build AI systems with the same architectural assumptions they used to build CRM portals. And it is, more than anything, a warning about the next twenty-four months.
How It Happened
Strip away the mystique and the attack is almost embarrassingly readable. The CodeWall agent began with what every attacker now begins with: reconnaissance. Lilli’s API documentation was publicly accessible. Of the 200-plus endpoints it described,
22 required no authentication at all wide-open doors into a production system. The agent walked through them.
From there, the agent identified an injection vector that standard scanners do not test for: while user values in SQL queries had been parameterised correctly (the textbook defence), JSON field names were being concatenated directly into queries without sanitisation. When the agent began malforming those field names, the database obligingly returned error messages laced with live production data. Classic error-based SQL injection but found by a machine, in minutes, at a cost measured in dollars rather than person-weeks.
What it found in the database is where this stop being a 1998 story and becomes a 2026 story. Sitting in the same tables as the chat messages were Lilli’s system prompts and RAG configuration the instructions that tell the model how to behave, what to cite, what to suppress, what to recommend. With write access, an attacker could silently rewrite those prompts. No code deployment. No release notes. No application log entry. The next morning, 30,000 consultants would log in and receive subtly altered advice and neither they nor McKinsey would know.
The Architectural Failures Were Not Exotic,
They Were Cultural
Engineers will, rightly, list the technical flaws: missing authentication, unsafe string concatenation, no Web Application Firewall on ingress, no schema validation at the gateway, no segregation between AI configuration and application data, no defence in depth.
But the deeper failure is architectural philosophy. Three assumptions, broadly held across the enterprise AI build-out, all wrong:
First, the assumption that AI platforms are just “another web app.” They are not. A traditional database compromise steals data. An AI configuration compromise corrupts judgement at scale, invisibly, for as long as nobody notices. The threat model is fundamentally different.
Second, the assumption that scanners and pen-test cycles will catch what matters. The CodeWall agent did not exploit a novel vulnerability, it exploited an unusual location for an old vulnerability that human red-teamers and OWASP ZAP both routinely miss. Scanners are pattern-matchers. AI attackers are explorers.
Third, the assumption that the application code is where security lives. Application code will always have bugs. Defence in depth means policy enforcement at the infrastructure layer the gateway, the WAF, the network sits independently of, and in front of, the inevitably buggy app. Lilli had none of that.
The Governance Implications Are Larger Than McKinsey
For boards, CROs and CTOs, three uncomfortable truths now sit on the table.
System prompts are the new crown jewels. They are corporate IP, behavioural policy, and regulatory artefact rolled into one. Yet most enterprises store them next to chat logs in a single relational database, behind a single auth layer. They should be encrypted at rest, separated from operational data, version-controlled with cryptographic signing, and changes should require multi-party approval the same controls we apply to production database schemas.
Audit trails designed for human attackers are obsolete. A human breach unfolds over weeks and leaves footprints. A machine-speed breach completes before your SIEM has aggregated the morning’s logs. Worse, a configuration breach leaves no footprint at all, the application is doing exactly what its (now-tampered) instructions tell it to. GRC teams must now monitor AI outputs for behavioural drift, not just AI inputs and infrastructure logs.
Asymmetry has flipped. For thirty years the attacker had to find one hole and the defender had to plug all of them a brutal asymmetry, but a known one. Autonomous offensive agents collapse the attacker’s cost curve. CodeWall’s chief executive said the quiet part loud in his post-disclosure interview: AI agents autonomously selecting and attacking targets will be the new normal. Defenders are not yet running AI agents that continuously red-team their own production systems. They will need to.
What Actually Has to Change
Let me be specific, because vague calls for “AI governance” are how we got here in the first place.
1. Treat every AI platform as a privileged application from day one. That means least-privilege data access, scoped retrieval, and segregation of duties between the model, the prompt store, and the knowledge base. If your AI agent has the same database role as your chat history table, you have already lost.
2. Implement defence in depth across the AI execution path. Three independent gates: an HTTP gate (authentication, rate limiting, WAF, schema validation) before any request touches the application; an LLM gate (prompt-injection detection, content policy enforcement, output filtering) between the application and the model; and an agent gate (tool-call authorisation, scope limits, behavioural monitoring) for any system that lets the AI take actions. None of these can live inside the application code itself.
3. Mandate AI-specific threat modelling before deployment. STRIDE was designed for a world of forms and CRUD operations. It does not catch prompt injection, indirect data exfiltration via RAG, system prompt manipulation, or context poisoning. Your security review template needs an AI-native section. If your CISO cannot describe how your organisation tests for these, that is a board-level finding.
4. Monitor outputs for behavioural drift. Build expected-output baselines. Sample responses continuously. When the AI starts citing a new domain, recommending a new vendor, or suppressing a category of advice, somebody needs to know in hours not when a journalist calls.
5. Make AI configuration changes a board-visible control. System prompts are policy. They should be versioned, signed, dual-authorised, and reportable. The audit committee already reviews changes to the financial close process; it should review changes to the instructions governing the AI tools that influence client-facing work.
6. Run continuous, autonomous red-teaming against your own AI estate. If the threat is now an AI agent that probes endlessly at machine speed, the defence has to be an AI agent that audits endlessly at machine speed. Annual pen tests are not a control; they are a compliance ritual.
The Real Lesson Is About Trust
The most chilling sentence in the entire CodeWall disclosure is the one nobody is quoting. The researchers noted that, having gained write access, they could have rewritten Lilli’s prompts to subtly steer the advice given to McKinsey’s consultants and through them, to clients running critical infrastructure, treasuries, and public services across the world. They chose not to.
We will not always be that lucky.
The McKinsey breach is not really a story about SQL injection. It is a story about how quickly the asymmetry between attackers and defenders has shifted, about how recklessly we have built AI systems that mediate professional judgement at scale, and about how unprepared most enterprise governance frameworks are for a world in which the most sensitive thing inside the firewall is no longer the data, but the instructions that shape how that data becomes advice.
The firms that will earn the right to be trusted with AI in the next decade are not the ones moving fastest. They are the ones who recognise, before the breach disclosure email arrives, that an AI platform is not a productivity tool. It is a piece of decision-making infrastructure and infrastructure has to be governed accordingly.
McKinsey will recover. The next firm may not.
Folu writes on AI governance, Strategy and architecture. Folu is the founder of AIExpertsPro, advising boards and executive teams on AI risk, security and assurance.
