AIDEFEND in Action AIA-0004 Validated Research Published: Apr 17, 2026

McKinsey Lilli Compromise: When SQL Injection Reaches the AI Prompt Layer

This chain starts with an old-fashioned web bug. Lilli (McKinsey's internal AI platform) exposed 22 unauthenticated API endpoints, and one of them built SQL from attacker-controlled JSON keys. CodeWall used that path to read and write the database behind McKinsey's AI platform: 46.5M chat messages, 728K files, 3.68M RAG chunks, vector-store metadata, and the system prompts shaping 43,000+ users.

The important point is not just that SQL injection happened. It is that one web bug reached the prompt and retrieval tables, so the compromise landed directly in the AI layer.

SQL InjectionData ExfiltrationData GovernanceEnterprise AIAgentic AI
5 applicable AIDEFEND defenses
Source: How We Hacked McKinsey's AI Platform 
Author: Paul Price (CodeWall)
Original article: Mar 9, 2026

Threat Analysis

  • Step 1: start with the unauthenticated API surface. Lilli exposed 22 endpoints without authentication. That gave CodeWall's autonomous agent a wide place to probe without needing an account first.
  • Step 2: use one endpoint that turns JSON keys into SQL. One API built SQL queries from attacker-controlled JSON keys. CodeWall reports database read/write access through SQL injection within about 2 hours. It separately chained SQL injection with insecure direct object references (IDOR) to read individual employees' search histories.
  • Step 3: realize the database also holds the AI platform's crown jewels. The exposed tables were not just ordinary business records. They included 46.5M chat messages, 728K files, 3.68M RAG chunks with S3 paths, vector-store metadata, AI assistants, and 95 prompt/model configurations across 12 models.
  • Step 4: move from reading the AI layer to rewriting it. The same SQLi allowed UPDATE. That meant an attacker could change a system prompt, poison retrieved content, remove model-level safety instructions, or insert exfiltration instructions with a simple HTTP request and without touching application code. These are potential effects of verified write access, not demonstrated prompt poisoning or a bypass of independently enforced backend authorization.
  • Why this matters: Lilli ran this way for 2 years with 43K+ users and 500K+ monthly prompts. CodeWall reports that ZAP missed the injection and its agent found the path; this is not an independent comparison of all automated or manual testing. McKinsey closed the unauthenticated endpoints and patched the issue on 2026-03-02 after CodeWall's 2026-03-01 report.

Applicable AIDEFEND Defenses (5)

AID-H-021.002
Runtime Integrity Enforcement (Signed Configurations)
High
Convert approved prompt/configuration records into exact signed bundles and verify the same bytes locally before startup and every live refresh, using trust keys and deployment approval outside the compromised database. This requires a customer-controlled loader; placing a signature beside a database row is insufficient. Deny unsigned or stale bundles and direct database-to-model bypasses. An approved signature proves origin and integrity, not safe prompt meaning.
AID-H-020.001
Chunk-Level Integrity Signing
High
Before context assembly, verify each exact chunk, source version, embedding bytes and model identity against an externally signed, retention-locked versioned manifest. Keep the signer and manifest outside the vector/database writer's trust domain. Reject missing, stale or mismatched evidence; a hash or signature stored only beside the mutable row does not constrain a writer who can replace both.
AID-D-004.003
Runtime Configuration & Policy Drift Detection and Monitoring
Medium
Independently compare effective prompts and policies with approved exact versions and route drift findings for investigation. The published Argo CD method observes declared deployment resources; it does not automatically read database prompt rows. This case needs a separately reviewed database/runtime collector covering the complete record population. Repository events or DB audit logs alone do not prove effective runtime state, and detection does not block or restore changes. The database collector is an alternative implementation, not the published Argo CD method.
AID-H-018.001
Tool Parameter Constraint & Schema Validation
Medium
In a customer-controlled API/tool adapter, enforce an exact key/type/selector schema before constructing database operations and reject unknown JSON field names. This reduces the admitted attack surface but is not a substitute for parameterized SQL and allowlisted identifier construction. SQL values and identifiers need their own safe construction rules; schema validation alone is not a database-isolation boundary.
AID-H-029.002
Lifecycle-Stage Authorization Gate
Medium
At every AI lifecycle ingress, independently resolve the exact asset/version, authoritative use tags, stage and authorized purpose before training, indexing or context assembly. A customer-controlled data plane must prevent direct DB reads from bypassing the gate. This limits unauthorized consumption of AI assets; it does not repair SQL injection or isolate tables with different credentials. Separate least-privilege database identities and storage boundaries are additional controls.

What Defenders Should Do Now

  • Inventory the exact prompt, RAG, vector-metadata and agent-configuration population and verify signed versions before loading or retrieval.
  • Use safe SQL construction for both values and identifiers, exact API schemas, and default-deny authentication and object authorization on every route.
  • Monitor unexpected writes to AI control data through independently protected database and runtime collectors; investigate rather than infer automatic containment.
  • Separate asset stores and least-privilege identities, then test cross-store access and all routes that could bypass lifecycle gates.
  • Add authorized, bounded security regression and red-team testing. Record what each test covered; autonomous testing supplements other AppSec methods and cannot guarantee complete discovery.

2 additional considerations

Blast-radius isolation between AI asset classes

Separate prompt, retrieval, conversation and identity stores with independently restricted identities and routes, and test direct and lateral access after one identity is compromised. Merely moving tables into different schemas or databases does not prevent a shared privileged account from reaching all of them.
Recommendation: Separate AI-asset stores by class (prompts / RAG / chat history / user identity / vector metadata) into distinct databases or schemas with distinct credentials and network paths, so lateral movement requires multiple independent failures rather than one SQLi.

Security testing coverage

CodeWall reported a reproducible path missed by the tools it used. This does not establish comparative superiority over all other AppSec methods. Test JSON field names as well as values, object authorization and AI control-data writes.
Recommendation: Combine authorized automated and manual testing, preserve evidence and record what remains untested.

Conclusion

McKinsey Lilli is a clear example of how an old web bug becomes a very modern AI-platform failure. Once SQL injection reached the prompt and retrieval tables, the attacker was no longer just looking at a database; they were in a position to rewrite how the system answered. AIDEFEND 's prompt-integrity, chunk-signing, and staged-authorization techniques map directly to that problem. The operational lesson is to treat prompts, RAG chunks, and vector metadata as assets that need their own integrity controls, not as ordinary rows sitting safely inside a database.

Last updated: