McKinsey’s Lilli ging am 9. März an die Öffentlichkeit. Die Aufzeichnung birgt keinen Schaden.

Am 9. März 2026 veröffentlichte das Sicherheits-Startup CodeWall seine Darstellung, wie ein von ihm entwickelter autonomer Agent in rund zwei Stunden und ohne einen einzigen Zugangsdatensatz vollständigen Lese- und Schreibzugriff auf die Produktionsdatenbank hinter Lilli erlangte, dem unternehmensweiten KI-Assistenten von McKinsey & Company. Der Eindringversuch selbst fand am 28. Februar statt; was dieser Eintrag im KI-Vorfallarchiv verzeichnet, ist der Tag, an dem er öffentlich wurde. Laut CodeWall enthielt die Datenbank, die der Agent erreichte, 46,5 Millionen Chatnachrichten im Klartext, 728.000 Dateien, 57.000 Benutzerkonten und die 95 System-Prompts, die steuern, wie Lilli antwortet – und diese Prompts lagen in derselben Datenbank, in die der Agent schreiben konnte. Bei den Personen in den Daten handelte es sich um McKinseys eigene Mitarbeiter: Das Unternehmen gibt an, 72 Prozent seiner Mitarbeiter – mehr als 40.000 Menschen – nutzen Lilli, das mehr als 500.000 Prompts pro Monat verarbeitet. Der vollständige Eintrag mit seinen Schweregrad- und Konfidenz-Einstufungen und den benachbarten Datensätzen, unter denen er steht, befindet sich im Orca AI Incident Archive.

Diese Eröffnung ist eine Verdichtung zweier sehr unterschiedlicher Arten von Behauptungen, und der Archiveintrag achtet sorgfältig auf den Unterschied. Er stuft den Eintrag als Vorfall ein, Konfidenz A, nicht bestritten, Schweregrad hoch, Region USA, Typ INFRA — Infrastruktur, kein Modellversagen. Außerdem verzeichnet er keinen tatsächlichen Schaden. Das letzte Feld sollte man zweimal lesen, denn es bedeutet nicht, dass die Exposition harmlos war. Es bedeutet, dass im Eintrag kein Schaden nachgewiesen wurde, und der folgende Artikel trennt, worüber sich zwei Parteien einig sind, von dem, was auf der Darstellung eines Unternehmens über seine eigene Forschung beruht.

Warum die Offenlegung ein eigenes datiertes Ereignis ist

Die Zusammenfassung des Archivs für diesen Eintrag verweist auf den 28. Februar 2026 zurück, den Tag, an dem der Agent von CodeWall die Schwachstelle fand, und das Archiv führt dieses frühere Datum als separaten Datensatz. Die Trennung ist nicht bürokratisch. Vor dem 9. März waren die einzigen Parteien, die wussten, was in Lilli geschehen war, McKinsey und der Forscher, der davon berichtet hatte. Nach dem 9. März waren die Form des Fehlers, die Reaktion des Unternehmens und die Behauptung darüber, was sich in der Datenbank befand, allesamt öffentlich dokumentiert, wo andere Sicherheitsforscher sich mit ihnen auseinandersetzen konnten.

Lilli ist kein Nebenprojekt. The Register datierte den Rollout auf Juli 2023 – mit Funktionen für Chat, Dokumentenanalyse und Abruf über die interne Forschung des Unternehmens hinweg. CodeWalls Bericht, der auch festhält, woher der Name stammt – von der ersten Frau, die das Unternehmen 1945 in einer Fachposition einstellte –, beschreibt mehr als 100.000 interne Dokumente, die dahinterstehen. The Register, das die Offenlegung am selben Tag berichtete, bezifferte die Nutzung auf 72 Prozent der Mitarbeitenden und das Volumen auf über 500.000 Prompts pro Monat – Zahlen, die McKinsey selbst in einer öffentlichen Fallstudie über die Plattform veröffentlicht hat.

Wie der Agent hineingelangte

CodeWalls Bericht beginnt mit Dokumentation, nicht mit Ausnutzung. Sein Agent fand Lillis API-Dokumentation öffentlich zugänglich und vollständig dokumentiert vor: insgesamt mehr als 200 Endpunkte, die meisten davon authentifizierungsbedürftig, und 22, die es nicht waren. Einer dieser nicht authentifizierten Endpunkte schrieb Benutzersuchanfragen in die Datenbank. Die Werte waren ordnungsgemäß parametrisiert, aber die JSON-Schlüssel – die Feldnamen – wurden direkt in SQL eingefügt.

Der Agent bemerkte es, weil Datenbank-Fehlermeldungen diese JSON-Schlüssel wörtlich zurückgaben. CodeWall erklärt, dass der ZAP-Scanner von OWASP das Problem nicht gemeldet habe und dass der Agent anschließend fünfzehn Blind-Iterationen durchlief, wobei jede Fehlermeldung ihm etwas mehr über die Gestalt der Abfrage verriet, bis schließlich echte Produktionszeilen zurückkamen. Von dort aus verknüpfte er die Injection mit einer Schwachstelle bei der objektbezogenen Autorisierung, um die Suchverläufe einzelner Mitarbeiter zu lesen. Das Unternehmen beschreibt den gesamten Ablauf als vollständig autonom, von der Zielauswahl bis zum Bericht, ohne Zugangsdaten und ohne menschliches Eingreifen. Sein Gründer und Chief Executive Paul Price sagte gegenüber The Register, der Prozess sei „vollständig autonom gewesen – von der Recherche des Ziels über das Analysieren und Angreifen bis zum Berichten.“

Was CodeWall zufolge darin war

Jede Zahl in diesem Abschnitt stammt aus CodeWalls Bericht vom 9. März. Es wurden keine Payloads veröffentlicht, daher kann nichts davon reproduziert oder unabhängig nachgezählt werden — eine Einschränkung, mit der sich der nächste Abschnitt befasst.

• 46,5 Millionen Chat-Nachrichten, im Klartext gespeichert, die Strategiearbeit, Kundenprojekte, Finanzdaten sowie Fusionen und Übernahmen abdecken.

• {{1}}728.000{{/1}} Dateien, von denen die Ausarbeitung {{2}}192.000{{/2}} PDFs, {{3}}93.000{{/3}} Excel-Tabellen, {{4}}93.000{{/4}} PowerPoint-Präsentationen und {{5}}58.000{{/5}} Word-Dokumente einzeln aufführt – insgesamt {{6}}436.000{{/6}}, wodurch die verbleibenden {{7}}292.000{{/7}} im selben Satz unklassifiziert bleiben.

• 57.000 Benutzerkonten, 384.000 KI-Assistenten und 94.000 Workspaces, was CodeWall als die vollständige organisatorische Struktur der internen KI-Nutzung des Unternehmens beschreibt.

• {{1}}95 System-Prompts und Modellkonfigurationen{{/1}} über {{2}}12 Modelltypen{{/2}} hinweg, die zeigen, {{3}}wie der Assistent angewiesen wurde{{/3}}, {{4}}welche Guardrails vorhanden waren{{/4}} und {{5}}welche Modelle darunter steckten{{/5}}.

• 3,68 Millionen Dokument-Chunks für retrieval-augmentierte Generierung, samt S3-Speicherpfaden und internen Dateimetadaten – die Wissensbasis, die den Assistenten speist.

• 1,1 Millionen Dateien und 217.000 Agentennachrichten, die über externe KI-APIs laufen, darunter mehr als 266.000 Vektorspeicher auf der Plattform von OpenAI.

Der Befund, den CodeWall als Schlagzeile behandelt, ist nicht die Injection, sondern der Ort, an dem die Injection gelandet ist. Lillis System-Prompts waren Zeilen in derselben Datenbank, in die der Agent schreiben konnte, was bedeutet, dass ein Angreifer mit demselben Zugriff die Anweisungen des Assistenten mit einem einzigen UPDATE-Statement hätte umschreiben können, verpackt in einen einzigen HTTP-Aufruf – kein Deployment, keine Codeänderung, keine Datei auf der Festplatte zum Diffen. CodeWall sagt, seine eigenen Tests dienten nur der Verifizierung: Es las, es schrieb nicht, und es sagt, kein Produktionsdienst sei gestört worden.

Was McKinsey am selben Tag sagte

Ein McKinsey-Sprecher sagte am 9. März gegenüber The Register, dass die Firma alle von CodeWall identifizierten Probleme innerhalb von Stunden nach Kenntnisnahme behoben habe. „Unsere Untersuchung, unterstützt durch eine führende externe Forensikfirma, ergab keine Hinweise darauf, dass Kundendaten oder vertrauliche Kundeninformationen von diesem Forscher oder einem anderen unbefugten Dritten abgerufen wurden“, sagte der Sprecher und fügte hinzu, dass „die Cybersicherheitssysteme von McKinsey robust seien.“

Silicon UK berichtete am 13. März über dieselbe Darstellung in Matthew Broersmas Bericht: McKinsey erklärte, man sei „kürzlich von einem Sicherheitsforscher auf eine Sicherheitslücke in unserem internen KI-Tool Lilli aufmerksam gemacht worden“, habe „die Sicherheitslücke umgehend bestätigt und das Problem innerhalb von Stunden behoben“, und es seien keine Kundendaten oder vertraulichen Kundeninformationen abgerufen worden. In dem Bericht wird außerdem erwähnt, dass Price der einzige Mitarbeiter von CodeWall ist – ein Detail, das erwähnenswert ist, weil es in beide Richtungen wirkt: Ein Ein-Personen-Forschungsunternehmen fand in zwei Stunden, was die eigenen Scanner der Firma nicht fanden, und ein Ein-Personen-Unternehmen verkauft außerdem das Tool, das es gefunden hat.

Zwei Berichte über die Lösung, mit einem Tag Abstand

CodeWalls eigener Offenlegungszeitplan sieht so aus: Der Agent identifiziert die SQL-Injection und beginnt am 28. Februar mit der Enumeration der Produktionsdatenbank; die vollständige Kette wird noch am selben Tag bestätigt, wobei 27 Befunde dokumentiert werden; am 1. März geht eine E-Mail zur verantwortungsvollen Offenlegung mit einer Zusammenfassung der Auswirkungen auf hoher Ebene an McKinseys Sicherheitsteam; der Chief Information Security Officer des Unternehmens bestätigt am 2. März den Eingang und bittet um detaillierte Nachweise; und am 2. März werden alle nicht authentifizierten Endpunkte gepatcht und verifiziert, die Entwicklungsumgebung wird offline genommen und die öffentliche API-Dokumentation wird blockiert. Die öffentliche Offenlegung folgt am 9. März.

McKinsey stellt es so dar, dass die Behebung innerhalb von Stunden nach der Benachrichtigung erfolgte. CodeWalls Zeitlinie setzt den Patch auf den Tag nach seiner Offenlegungs-E-Mail. Beide Darstellungen sind dokumentiert. Keine der Parteien hat sie miteinander abgeglichen, und dieser Artikel unternimmt auch keinen Versuch dazu: Der Unterschied besteht zwischen einer Behebung am selben Tag und einer am nächsten Tag, und die entscheidende Abfolge – benachrichtigt, dann gepatcht, dann veröffentlicht – ist unstrittig.

Etabliert, Single-Source und die Lücke dazwischen

Festgestellt und von beiden Parteien vereinbart: Es gab eine nicht authentifizierte Schwachstelle an der öffentlichen API-Oberfläche von Lilli; sie wurde von einem externen Sicherheitsforscher und nicht von einem Insider entdeckt; McKinsey bestätigte sie und behob sie per Patch; die nicht authentifizierten Endpunkte wurden geschlossen, die Entwicklungsumgebung wurde offline genommen und die öffentliche API-Dokumentation wurde blockiert.

Aus einer einzigen Quelle, von CodeWall: jede oben genannte Zahl, der Zwei-Stunden-Zeitrahmen, die fünfzehn Blind-Iterationen, die 27 dokumentierten Befunde und die Behauptung, dass die Prompts über dieselbe Injection schreibbar waren. Nichts davon ist widerlegt. Nichts davon wurde jedoch unabhängig verifiziert, weil die Payloads, mit denen jemand das hätte überprüfen können, nicht veröffentlicht wurden und Price sich weigerte, The Register die genauen Prompts zu nennen, die sein Team verwendet hatte.

Promptfoo, das KI-Sicherheitsunternehmen, veröffentlichte am 10. März eine Bewertung, die die Grenze präzise benennt: Die öffentliche Aktenlage „belegt nicht unabhängig jede gemeldete Zeilenanzahl oder jeden Schritt der Ausnutzung“, obwohl sie die Gestalt des Vorfalls stützt. Das ist die richtige Lesart des verfügbaren Materials. Die Fehlerklasse ist rekonstruierbar; der Umfang ist Aussage.

Der Schaden, den die Aufzeichnung nicht trägt

Hier leistet die Bewertung des Archivs echte Arbeit. Ein zweistündiger Weg zu Lese- und Schreibzugriff in der Produktionsdatenbank eines konzernweiten Assistenten klingt nach einem Schadenseintrag, und das Archiv verzeichnet keinen. Das Feld stützt sich auf drei Dinge: McKinseys Erklärung, dass eine forensische Untersuchung durch Dritte keine Beweise dafür fand, dass auf Kundendaten zugegriffen wurde; CodeWalls Erklärung, dass seine Tests nur der Verifizierung dienten und nichts beeinträchtigten; und das Fehlen jeglicher widersprechender Feststellung in der für diesen Artikel geprüften Berichterstattung.

Es beruht nicht auf einem unabhängigen technischen Audit, einer Feststellung einer Aufsichtsbehörde oder einer Meldung einer Datenschutzverletzung. In keiner der geprüften Berichterstattungen wurde eine CVE-Kennung vergeben – Lilli ist interne Software und kein vertriebenes Produkt, und keine Sicherheitsempfehlung nennt eine – und keine Aufsichtsbehörde scheint ein Verfahren eröffnet zu haben. In der für diesen Artikel geprüften Berichterstattung sind keine öffentlichen Belege dafür aufgetaucht, dass die Daten genutzt, verkauft oder weiter offengelegt wurden. Das ist hier die Bedeutung von „kein echter Schaden verzeichnet“: eine Aussage über die Beweislage zu einem Eintrag, nicht die Feststellung, dass die Offenlegung unbedenklich war.

Die Lücke ist wichtig, weil das interessante Risiko prospektiv war. Lesezugriff legt offen, was vorhanden war. Schreibzugriff auf die Prompt-Ebene legt offen, was der Assistent als Nächstes sagen würde – vergiftete Ratschläge, das Entfernen von Schutzmechanismen, vertrauliches Material, das in eine Antwort eingebettet wird, die ein Berater dann in ein Kundendokument einfügt. CodeWall beschrieb diese Folgen als für jeden mit demselben Zugriff verfügbar. Niemand hat gezeigt, dass davon Gebrauch gemacht wurde. Beide Aussagen können gleichzeitig zutreffen: Die Fähigkeit war real, und der Schaden ist nach den Belegen, die irgendjemand veröffentlicht hat, nicht eingetreten.

Warum es als Infrastruktur eingestuft wird und nicht als Modellfehler

Das Archiv versieht diesen Eintrag mit dem Tag INFRA, und der technische Datensatz stützt diese Einstufung. Nichts in CodeWalls Bericht erforderte es, das Modell zu täuschen. Es gab kein Jailbreak, keine Prompt-Injection aus einem Dokument, keine gegnerischen Eingaben, die der Assistent hätte schlucken sollen. Der Einstiegspunkt waren eine offenliegende Dokumentation, eine fehlende Authentifizierungsprüfung und eine unsichere SQL-Konstruktion; das Modell war schlicht das Wertvollste hinter der Tür.

Die Analyse von Promptfoo vom 10. März trifft dieselbe Unterscheidung aus der Verteidigungsperspektive: Lilli „wirkt in der öffentlichen Darstellung wie ein Anwendungssicherheitsvorfall, der ein KI-System erreicht hat, nicht wie ein Model-Jailbreak“, und vieles, was als KI-Sicherheit bezeichnet wird, ist nach wie vor Software-Sicherheit, Datensicherheit und Konfigurations-Governance. Der KI-spezifische Teil war der Schadensradius, nicht die Kompromittierung – da Prompts, Routing-Regeln und Retrieval-Einstellungen veränderbare Anwendungsdaten waren, wurde Schreibzugriff auf die Datenbank zu der Möglichkeit, das Verhalten des Assistenten zu ändern, ohne Code anzufassen.

Was hat sich danach geändert?

Die konkreten Änderungen sind die, die beide Parteien beschreiben: Die nicht authentifizierten Endpunkte wurden geschlossen und verifiziert, die Entwicklungsumgebung wurde offline genommen und die öffentliche API-Dokumentation wurde gesperrt. McKinsey hat erklärt, dass das Unternehmen die Schwachstelle gefunden, bestätigt und behoben hat, und vertritt öffentlich die Position, dass auf keine Kundendaten zugegriffen wurde.

Was sich nicht geändert hat, ist die breitere Exposition, die dieser Vorfall beschreibt. CodeWalls Analyse schließt mit dem Argument, dass Prompts in Datenbanken gespeichert, durch APIs geleitet und in Konfigurationsdateien zwischengespeichert werden und dass sie selten Zugriffskontrollen, Versionsverläufe oder Integritätsüberwachung erhalten – was eine Aussage über eine Branche und keine Erkenntnis über McKinsey ist und als Argument eines Unternehmens gelesen werden sollte, das kontinuierliche automatisierte Tests verkauft. Das Unternehmen befindet sich in einer frühen Vorschauphase und sucht Designpartner; die Offenlegung dient zugleich als Demonstration.

Was das Protokoll übrig lässt, ist enger und nützlicher als der Streit. Ein firmenweiter Assistent, eine Produktionsdatenbank, zwei Stunden, keine Zugangsdaten und eine Schadenszeile, die falsch klingt, weil beide Parteien mit Zugang zu den Fakten sagen, dass die Daten nicht verwendet wurden. Die Zahlen gehören zu einer dieser Parteien. Die Schwachstelle gehört beiden.