An autonomous AI agent breached one of the world's most sophisticated professional services firms in 120 minutes — using a vulnerability class that has been documented since 1998. If McKinsey can't secure its AI platform, the question every bank board should be asking is: can we?

 

What happened

​

On February 28, 2026, security startup CodeWall pointed an autonomous offensive AI agent at McKinsey & Company's internal AI platform, Lilli. The agent had no credentials, no insider knowledge, and no human guidance. It selected the target itself, citing McKinsey's public responsible disclosure policy and recent updates to the platform.

 

Within two hours — at an estimated cost of $20 in compute tokens — the agent had achieved full read-and-write access to the production database.

​

The potential exposure was staggering: 46.5 million chat messages covering strategy, M&A, and client engagements. 728,000 files including confidential client documents. 57,000 user accounts. 3.68 million RAG document chunks representing decades of proprietary McKinsey research. And 95 system prompts — the instructions that govern how Lilli behaves for every one of the more than 40,000 consultants who use it.

 

The prompts were writable. An attacker could have silently reprogrammed the chatbot's behaviour — poisoning strategic advice, stripping safety guardrails, or embedding instructions to exfiltrate confidential data through normal-looking responses — without deploying a single line of code, and without triggering a security alert.

 

CodeWall disclosed the vulnerability to McKinsey on March 1. By the following day, McKinsey had patched all unauthenticated endpoints, taken the development environment offline, and removed public API documentation. McKinsey stated that its investigation, supported by a third-party forensics firm, found no evidence that client data had been accessed by any unauthorised party.

 

How it happened

 

The root cause was not exotic. CodeWall's agent discovered publicly exposed API documentation listing over 200 endpoints. Of those, 22 required no authentication. One of these unauthenticated endpoints accepted user search queries and fed the input directly into the database — with JSON field names concatenated into SQL statements without sanitisation.

​

This is SQL injection — a vulnerability class that has been in the OWASP Top 10 since 2003 and has been documented in security literature since the late 1990s. Standard automated scanning tools, including OWASP ZAP, failed to detect it because they test parameter values, not key names. The autonomous agent found it through iterative probing, recognising patterns in error messages that a checklist-based scanner would miss.

​

Lilli had been running in production for over two years. McKinsey has significant technology investment, dedicated security teams, and — notably — derives approximately 40% of its revenue from AI advisory work. If this could happen at McKinsey, it can happen anywhere. Or can it?

​

Why it matters — beyond McKinsey

 

Three dimensions of this incident deserve particular attention from financial services leaders.

​

First, AI platforms are not applications — they are intelligence repositories. Lilli processed over 500,000 prompts per month from consultants working on strategy, M&A, and client engagements. The database didn't just contain metadata; it contained the substance of McKinsey's advisory work — in plaintext. Any bank or wealth manager deploying a similar internal AI tool should assume it will rapidly accumulate a concentration of sensitive information that exceeds any single traditional application. The attack surface is not the model. It is the ecosystem around it: the APIs, the databases, the document stores, and the permission structures that connect them.

 

Second, the write-access dimension introduces a new category of risk. A conventional data breach steals information. An AI platform breach with write access can corrupt the advice that thousands of professionals rely on — silently, at scale, and without leaving a trace in application logs. This is not a risk that traditional information security frameworks are designed to detect. System prompt integrity — the assurance that the AI's behavioural instructions have not been tampered with — is a new governance requirement that most institutions have not yet addressed.

​

Third, the attacker was an AI agent. CodeWall's offensive agent autonomously selected its target, mapped the attack surface, identified the vulnerability, chained it with an IDOR flaw, escalated access, and exfiltrated data — all without human intervention. This is the threat model of the near future: AI-powered offensive operations that move at machine speed against organisations whose defences are designed for human-speed adversaries. Nation-state actors are already using AI agents to manage attack infrastructure. The Lilli breach is a controlled research exercise. The next one may not be.

 

What the board of a regulated bank must do

​

Banks operate under supervisory frameworks — FINMA Circular 2023/1 on operational risks and resilience, the ECB's supervisory expectations on ICT risk, the EU's DORA regulation — that place explicit responsibility for ICT and cyber risk governance with the board of directors. The McKinsey incident is a case study in why that responsibility cannot be discharged by generic assurances from the technology function.

 

Here is a concrete action plan.

 

1. Conduct an AI attack surface inventory. The board should request and review a complete register of all internal AI tools, chatbots, copilots, and agent-based systems deployed across the institution. For each, the inventory must document: what data the system can access, what APIs it connects to, whether authentication is enforced on all endpoints, and where system prompts and model configurations are stored. If the CISO cannot produce this inventory within, say, 30 days, that fact is itself a finding.

​

2. Mandate AI-specific penetration testing. Traditional penetration testing and vulnerability scanning are necessary but insufficient. The McKinsey breach demonstrates that standard tools miss AI-specific attack vectors — prompt injection, context manipulation, indirect data exfiltration through model outputs. The board should require that all production AI systems undergo dedicated AI red-teaming, including autonomous agent-based testing, before deployment and at regular intervals thereafter. This should be explicitly covered in the institution's ICT risk management framework, e.g. under DORA Article 25.

​

3. Separate AI configuration from production data. System prompts are the behavioural instructions of the AI. They determine what the system recommends, what it refuses, and how it handles sensitive information. Storing them in the same database as user data — as McKinsey did — means that a single breach can compromise both the data and the logic. The board should require that all system prompts and model configurations are stored in version-controlled, access-restricted repositories with immutable audit trails. Any modification must trigger an alert.

​

4. Classify AI platforms as critical third-party or critical intra-group services. Under DORA and FINMA's outsourcing requirements, any AI platform that ingests, processes, or generates advice based on client data should be classified as a critical or important function. This triggers enhanced governance requirements: documented risk assessments, exit strategies, ongoing monitoring, and board-level reporting. Internal AI tools are not exempt simply because they are built in-house.

​

5. Establish a board-level AI risk reporting cadence. AI risk should not be buried in the quarterly IT risk report. The board — or the Audit & Risk Committee — should receive a dedicated AI risk update at least quarterly, covering: the current deployment inventory, results of AI-specific testing, incidents and near-misses, regulatory developments, and an assessment of whether the institution's AI governance maturity is keeping pace with its AI deployment velocity. The gap between those two curves is where the risk lives.

​

6. Stress-test the incident response plan for AI-specific scenarios. Most bank incident response plans are designed for data exfiltration or ransomware. They are not designed for the scenario where an attacker silently poisons the AI that advises your relationship managers, your credit analysts, or your compliance officers. The board should require a tabletop exercise specifically designed for an AI integrity compromise — one that tests not only detection and containment, but also the institution's ability to identify how long the compromise persisted and which decisions were made on the basis of corrupted outputs.

 

The governance gap

​

The McKinsey breach is, in one sense, a familiar story: a well-resourced organisation failed to enforce elementary security hygiene on a production system. SQL injection is not new. Unauthenticated API endpoints are not new. The post-incident response was fast and professional.

 

But the context is new. When the compromised system is an AI platform that 40,000 people rely on for strategic advice, the blast radius of a breach is qualitatively different. The risk is not only that data is stolen. The risk is that the institution's capacity to reason is silently corrupted — and that no one notices.

​

For regulated financial institutions, this is not a hypothetical. Banks are deploying AI copilots in credit decisioning, in AML monitoring, in client advisory, in regulatory reporting. Each of these systems sits on top of an API ecosystem, a data layer, and a set of system prompts that define its behaviour. Each of them is an attack surface. And the adversaries are no longer just human.

​

The operational reality moves faster than the strategic oversight. That has always been true in cyber risk. But the board's responsibility does not move at the speed of the operation — it moves at the speed of foresight. The McKinsey breach is a warning. The question is whether boards treat it as one.

​

 

Silvan Schriber is Managing Director at Alvarez & Marsal and a Board Member and Audit & Risk Committee Chair at Zuger Kantonalbank. He advises financial institutions on strategy, transformation, and governance — including ICT risk and cyber resilience.

​​​