Ein autonomer KI-Agent hat sich ohne Zugangsdaten, ohne Insiderwissen und ohne menschliche Hilfe in McKinseys interne KI-Plattform Lilli gehackt. In nur zwei Stunden erlangte er vollen Lese- und Schreibzugriff auf die Produktionsdatenbank. Offengelegt wurden 46,5 Millionen Chat-Nachrichten zu Strategie, M&A und Kundenprojekten, 728.000 vertrauliche Dateien, 57.000 Benutzerkonten und 95 Systemprompts, die das Verhalten des Chatbots für über 40.000 McKinsey-Berater steuerten. Die Sicherheitsfirma CodeWall veröffentlichte die Ergebnisse am 9. März 2026. Die Angriffsmethode war kein neuartiger Zero-Day-Exploit, sondern SQL-Injection: eine Schwachstellenklasse, die seit den 1990er-Jahren bekannt ist.
Der entscheidende Punkt: OWASP ZAP, einer der meistgenutzten Sicherheitsscanner, hatte die Lücke nicht gefunden. Standardwerkzeuge haben versagt. Ein KI-Agent brauchte nur Minuten.
Der Angriff: SQL-Injection über JSON-Feldnamen
CodeWalls KI-Agent begann so, wie jeder externe Angreifer starten würde: mit der Suche nach öffentlich zugänglichen Angriffsflächen. Er fand Lillis API-Dokumentation, die frei im Internet einsehbar war. Darin identifizierte der Agent 22 API-Endpunkte, die keinerlei Authentifizierung erforderten. Kein API-Key, kein OAuth-Token, kein Session-Cookie. Offene Endpunkte auf einem Produktionssystem, das Dutzende Millionen vertraulicher Datensätze enthielt.
Einer dieser ungesicherten Endpunkte verarbeitete Suchanfragen von Nutzern. Der Agent testete ihn und bemerkte etwas Ungewöhnliches: Die JSON-Feldnamen in API-Requests tauchten wörtlich in Datenbank-Fehlermeldungen auf. Das ist ein Warnsignal, das Entwickler bereits im Grundstudium der IT-Sicherheit kennenlernen sollten.
Technisch funktioniert das so: Wenn eine API einen JSON-Payload wie {"username": "john"} erhält, wird der Wert (john) normalerweise parametrisiert in die SQL-Abfrage eingesetzt. McKinseys Entwickler hatten die Werte korrekt parametrisiert. Aber die Schlüssel, also die Feldnamen selbst (username), wurden direkt in den SQL-String eingefügt. The Decoder beschreibt das als “jahrzehntealte Technik”, angewendet in einem Kontext, den moderne Scanner nicht prüfen.
Der Agent führte 15 blinde Iterationen durch. Bei jedem Versuch konstruierte er einen leicht veränderten JSON-Schlüssel, um aus den Fehlermeldungen mehr Informationen zu extrahieren. Beim fünfzehnten Versuch flossen Produktionsdaten zurück. Voller Lese- und Schreibzugriff auf die gesamte Datenbank.
Was Standard-Scanner übersehen haben
Dieses Detail sollte jedes Security-Team aufhorchen lassen, das DAST-Tools in seiner CI/CD-Pipeline einsetzt. OWASP ZAP, der De-facto-Standard unter den Open-Source-Web-Application-Security-Scannern, testete Lilli und fand nichts. Der Grund: ZAP injiziert Testpayloads in Parameter-Werte, nicht in Parameter-Namen. Es testete {"username": "' OR 1=1--"}, aber niemals {"' OR 1=1--": "value"}. Die Angriffsfläche lag in einer Dimension, die der Scanner schlicht nicht abdeckt.
CodeWalls KI-Agent hatte diesen blinden Fleck nicht. Er beobachtete Fehlermeldungen, bildete Hypothesen über die Abfragestruktur und passte seine Payloads über 15 Iterationen an. Genau diese Fähigkeit macht KI-Agenten bei offensiver Sicherheitsprüfung so effektiv: Sie folgen keinem festen Skript, sondern lernen aus den Antworten des Systems und passen sich in Echtzeit an.
Das Ausmaß: 46,5 Millionen Nachrichten im Klartext
Die Zahlen sind selbst für Enterprise-Sicherheitsvorfälle außergewöhnlich. Laut mehreren Berichten erlangte CodeWalls Agent Zugriff auf:
- 46,5 Millionen Chat-Nachrichten zu Strategiediskussionen, M&A-Analysen und Kundenprojekten, sämtlich im Klartext gespeichert
- 728.000 Dateien mit vertraulichen Kundendaten
- 57.000 Benutzerkonten mit zugehörigen Metadaten
- 95 Systemprompts, die Lillis Verhalten, Leitplanken, Zitiermethoden und Antwortformatierung definierten
McKinseys Lilli ist kein Nebenprojekt. Es ist die zentrale KI-Plattform der Beratung, intern als Wissensmanagement-Tool beschrieben, das Beratern Zugang zu McKinseys proprietärer Forschung und Frameworks verschafft. Zehntausende Berater nutzen Lilli täglich. Jede Frage, die sie stellten, jedes strategische Szenario, das sie durchspielten, jeder Kundenname, den sie erwähnten: alles lag in dieser Datenbank.
Das Problem der beschreibbaren Systemprompts
Der gefährlichste Befund war nicht die Datenexposition. Es war die Tatsache, dass Lillis 95 Systemprompts über dieselbe SQL-Injection-Schwachstelle beschreibbar waren. Diese Prompts steuern alles an Lillis Verhalten: welche Leitplanken greifen, wie Quellen zitiert werden, welche Informationen angezeigt werden, welche Anfragen abgelehnt werden.
Da die SQL-Injection Lese- und Schreibzugriff ermöglichte, hätte ein Angreifer diese Prompts mit einem einzigen HTTP-Request ändern können. Keine Deployment-Pipeline, kein Code-Review, kein Infrastrukturzugang nötig. Ein einziger manipulierter API-Aufruf hätte gereicht, um die Anweisungen umzuschreiben, nach denen Lilli jede Anfrage jedes Beraters beantwortete.
Die Konsequenzen beschreibbarer Systemprompts in dieser Größenordnung sind gravierend. Ein Angreifer hätte:
- Strategische Empfehlungen manipulieren können, indem er Lillis Outputs zu M&A-Zielen, Marktgrößen oder Wettbewerbsanalysen subtil verzerrt
- Sicherheitsleitplanken deaktivieren können, sodass Lilli vertrauliche Informationen frei teilt, die eigentlich eingeschränkt sein sollten
- Das Zitierverhalten ändern können, sodass Lilli erfundene Daten echter McKinsey-Forschung zuschreibt
- Persistente Hintertüren in die Prompt-Logik einbauen können, die auch nach Anwendungs-Neustarts bestehen bleiben
Das ist nicht theoretisch. Die technische Möglichkeit wurde nachgewiesen. Der einzige Grund, warum es nicht passiert ist: CodeWall führte ein autorisiertes Red-Team-Engagement durch, keinen echten Angriff.
Warum KI-Agenten finden, was Scanner übersehen
Der McKinsey-Vorfall zeigt einen strukturellen Wandel in der Schwachstellenentdeckung. Klassische DAST-Werkzeuge (Dynamic Application Security Testing) wie ZAP, Burp Suite oder Qualys WAS folgen vordefinierten Testfällen. Sie injizieren bekannte Angriffsmuster an bekannten Parameterpositionen. Sie sind schnell, konsistent und sehr gut darin, die Schwachstellen zu finden, für die sie programmiert wurden.
KI-Agenten arbeiten fundamental anders. CodeWalls Agent wählte sein Ziel selbst aus, entdeckte die API-Oberfläche autonom, bildete Hypothesen über das Backend-Verhalten anhand von Fehlermeldungen und iterierte über Angriffsvektoren, die in keinem Scanner-Regelwerk stehen. Er fand eine Schwachstellenklasse (SQL-Injection über JSON-Keys), die technisch wohlbekannt, aber praktisch unsichtbar für automatisierte Tools war.
Das erzeugt eine Asymmetrie, die Verteidiger verinnerlichen müssen. Wer sich ausschließlich auf Scanner verlässt, testet gegen die Angriffsmuster von gestern. Offensive KI-Agenten testen gegen das tatsächliche Verhalten des Systems, einschließlich Randfälle, für die nie jemand eine Erkennungsregel geschrieben hat.
Die Beschleunigung durch Red Teaming mit KI
CodeWall schloss den gesamten Angriff in zwei Stunden ab. Ein menschlicher Penetrationstester hätte für dasselbe Assessment typischerweise Tage allein für die Aufklärungsphase gebraucht, möglicherweise eine Woche für das gesamte Engagement. Der KI-Agent komprimierte die gesamte Kill-Chain, von der Zielauswahl bis zum vollständigen Datenbankzugriff, auf 120 Minuten.
Dieser Geschwindigkeitsvorteil gilt auch für die Verteidigung. Wenn Unternehmen ähnliche Agenten defensiv einsetzen würden, um kontinuierlich Red-Team-Übungen gegen die eigene Infrastruktur durchzuführen, könnten sie solche Schwachstellen finden, bevor externe Angreifer es tun. Das Problem: Bisher haben nur sehr wenige Organisationen diesen Ansatz übernommen. Die meisten Unternehmen führen vierteljährliche oder jährliche Penetrationstests durch, Intervalle, die monatelange Fenster offenlassen, in denen neue Schwachstellen unentdeckt bleiben.
McKinseys Reaktion und was sie uns verrät
McKinsey reagierte schnell nach der Benachrichtigung. Laut ihrer Stellungnahme bestätigten sie die Schwachstelle und patchten sie innerhalb von Stunden. Die Behebung umfasste das Abschalten der Entwicklungsumgebung, die Entfernung des öffentlichen Zugangs zur API-Dokumentation und das Patchen der unauthentifizierten Endpunkte.
McKinseys Untersuchung, unterstützt von einer führenden forensischen Drittfirma, ergab keinen Hinweis auf unbefugten Zugriff auf Kundendaten außerhalb des kontrollierten CodeWall-Tests. Gute Nachrichten für McKinseys Kunden, aber eine unbequeme Frage bleibt: Wie lange waren diese 22 unauthentifizierten Endpunkte offen, bevor CodeWall sie fand? Die API-Dokumentation war öffentlich zugänglich. Die Schwachstelle war ohne Zugangsdaten ausnutzbar. Wenn CodeWalls Agent sie in Minuten fand, was könnte sie vorher schon gefunden haben?
Lehren für jedes Unternehmen mit KI-Plattform
Der McKinsey-Vorfall ist kein Einzelfall. Er ist eine Vorschau auf das, was jedem Unternehmen droht, das KI-Plattform-Sicherheit als nachträgliche Ergänzung statt als Grundvoraussetzung behandelt. Drei Muster aus diesem Vorfall sind universell anwendbar:
Erstens: API-Oberflächenmanagement für KI-Plattformen unterscheidet sich von klassischen Anwendungen. KI-Chatbots legen typischerweise mehr Endpunkte offen als eine herkömmliche Web-App, weil sie Dokumentenabruf, Nutzerkontext, Prompt-Verwaltung und Feedback-Schleifen bedienen müssen. Jeder davon ist eine Angriffsfläche. McKinsey hatte 22 unauthentifizierte Endpunkte. Wie viele hat Ihre KI-Plattform?
Zweitens: Klassische Sicherheitsscanner sind notwendig, aber nicht ausreichend. ZAP fand nichts. Das bedeutet nicht, dass ZAP fehlerhaft ist. Es bedeutet, dass die Schwachstelle außerhalb von ZAPs Testmatrix lag. Unternehmen müssen automatisiertes Scanning durch adversariales KI-Testing, manuelle Überprüfung von API-Designs und spezifisches Threat Modeling für KI-Systemarchitekturen ergänzen. Im DACH-Raum, wo die DSGVO und der EU AI Act (Inkrafttreten der Hochrisiko-Anforderungen ab August 2025) strenge Sorgfaltspflichten vorsehen, ist das besonders relevant.
Drittens: Systemprompts sind Infrastruktur, keine Konfiguration. Systemprompts in derselben Datenbank wie Nutzerdaten zu speichern, erreichbar über dieselbe Abfrageschicht, ist eine Designentscheidung, die kein Security-Review überstehen sollte. Prompts gehören versioniert, zugriffsgesteuert und separat von Laufzeitdaten gespeichert. Wer Schreibzugriff auf Ihre Prompts hat, kontrolliert Ihre KI.
Häufig gestellte Fragen
Wie wurde McKinseys KI-Agent Lilli gehackt?
Die Sicherheitsfirma CodeWall setzte einen autonomen KI-Agenten ein, der öffentlich zugängliche API-Dokumentation von McKinseys Lilli-Plattform fand. Der Agent identifizierte 22 unauthentifizierte Endpunkte und nutzte eine SQL-Injection-Schwachstelle in JSON-Feldnamen (nicht Werten) aus, um innerhalb von zwei Stunden vollen Lese- und Schreibzugriff auf die Produktionsdatenbank zu erlangen. Standard-Sicherheitsscanner wie OWASP ZAP hatten diese Schwachstelle übersehen, da sie nur Injection in Parameter-Werten testen, nicht in Parameter-Namen.
Welche Daten wurden beim McKinsey-Lilli-Vorfall offengelegt?
CodeWalls Agent erlangte Zugriff auf 46,5 Millionen Chat-Nachrichten zu Strategie, M&A und Kundenprojekten im Klartext, 728.000 vertrauliche Dateien, 57.000 Benutzerkonten und 95 Systemprompts, die steuerten, wie Lilli den über 40.000 McKinsey-Beratern antwortete. Die Systemprompts waren zudem beschreibbar, sodass ein Angreifer Lillis Verhalten hätte ändern können.
Was ist SQL-Injection über JSON-Feldnamen?
Die meisten SQL-Injection-Angriffe zielen auf Parameter-Werte in API-Requests. Beim McKinsey-Lilli-Vorfall waren die Werte korrekt parametrisiert, aber die JSON-Feldnamen (Keys) wurden direkt in SQL-Abfragen eingefügt. Dies ist eine bekannte Schwachstellenklasse, die Standard-Scanner typischerweise nicht prüfen, weshalb OWASP ZAP sie nicht erkannte.
Warum sind beschreibbare KI-Systemprompts ein Sicherheitsrisiko?
Systemprompts definieren, wie ein KI-Chatbot sich verhält, welche Leitplanken gelten, wie Quellen zitiert werden und welche Informationen geteilt werden. Kann ein Angreifer diese Prompts überschreiben, kann er das Verhalten der KI für alle Nutzer lautlos verändern, ohne Code zu deployen oder Infrastruktur zu ändern. Im Fall von McKinsey waren 95 Systemprompts über die SQL-Injection-Schwachstelle beschreibbar.
Wie können Unternehmen ihre KI-Plattformen vor ähnlichen Angriffen schützen?
Drei zentrale Maßnahmen: Erstens alle API-Endpunkte auf Authentifizierungsanforderungen prüfen, besonders bei KI-Plattformen, die oft mehr Angriffsflächen bieten als herkömmliche Apps. Zweitens automatisierte Sicherheitsscanner durch adversariales KI-Red-Teaming ergänzen, da Standard-Tools die McKinsey-Schwachstelle übersehen haben. Drittens Systemprompts als Infrastruktur behandeln: separat von Nutzerdaten speichern, versionieren und den Schreibzugriff einschränken.