McKinsey gehackt: Wenn ein KI-Agent deine KI-Plattform knackt

Illustration zum KI-Hack bei McKinsey – Sebastian Winkler erklärt KI-Sicherheitsrisiken

46,5 Millionen Chat-Nachrichten. 728.000 Dateien. 57.000 User-Accounts. Alles offen.

Nicht bei einem Startup, das gestern gegründet wurde. Bei McKinsey. Der Beratung, die Fortune-500-Unternehmen erklärt, wie sie KI sicher einsetzen sollen.

Was ist passiert? Und was heisst das für jedes Unternehmen, das gerade KI einführt?

Was ist ein KI-Agent? Und warum ist er gefährlicher als ein Hacker?

Ein KI-Agent ist ein autonomes KI-System, das selbstständig Aufgaben ausführt, ohne dass jeder Schritt von einem Menschen genehmigt werden muss. Anders als ein Chatbot, der nur auf Anfragen reagiert, kann ein KI-Agent Entscheidungen treffen, Werkzeuge nutzen, Aktionen ausführen und – wie im Fall des McKinsey-Hacks – Sicherheitslücken iterativ finden und ausnutzen.

Das macht KI-Agenten zu einer neuen Kategorie von Sicherheitsrisiko. Ein menschlicher Hacker braucht Schlaf, macht Pausen, arbeitet an einem Problem vielleicht zwei Stunden. Ein KI-Agent arbeitet 24 Stunden am Tag, sieben Tage die Woche, systematisch, geduldig und ohne Ego. Wenn er auf eine verschlossene Tür trifft, probiert er 1.000 Schlüssel – einer nach dem anderen.

Der Hack: Zwei Stunden, ein Agent, alles offen

Das Security-Unternehmen CodeWall.ai hat einen autonomen KI-Agenten auf McKinseys interne KI-Plattform „Lilli“ losgelassen. Kein Mensch mit Kapuzenpulli in einem dunklen Keller. Ein KI-Agent. Alleine.

Der Einstiegspunkt? Eine SQL-Injection über einen ungeschützten API-Endpunkt. Das ist so ungefähr das Äquivalent davon, die Haustür offen stehen zu lassen.

Der Agent hat 15 Iterationen gebraucht, um die Schwachstelle zu finden und auszunutzen. Zwei Stunden nach dem Start hatte er vollen Lese- und Schreibzugriff auf die komplette Produktionsdatenbank. Was da alles drin lag: 192.000 PDFs. 93.000 Excel-Sheets. 384.000 KI-Assistenten. 3,68 Millionen RAG-Dokumentteile. Und die System-Prompts, die das Verhalten der gesamten Plattform steuern.

Nicht nur lesen. Auch verändern. Der Agent hätte die System-Prompts umschreiben können – und damit das Verhalten aller KI-Assistenten auf der Plattform manipulieren.

Warum mich das beschäftigt

Ich rede nicht von einer kleinen Firma, die sich mit IT schwertut. McKinsey hat Tausende der klügsten Köpfe. Budgets, von denen die meisten Mittelständler nur träumen. Und trotzdem: eine SQL-Injection. 2026. Ernsthaft.

Das zeigt mir zwei Dinge.

Erstens: Geschwindigkeit schlägt Sicherheit. Überall. Jeder will KI einführen. Gestern. Deshalb wird Security in der Hektik zum Nachgedanken. „Machen wir später.“ Später ist dann, wenn jemand drin ist.

Zweitens: KI-Agenten verändern das Spiel. Es braucht keinen erfahrenen Hacker mehr. Ein autonomer Agent iteriert sich durch Schwachstellen wie ein Schachcomputer durch Eröffnungen. Systematisch, geduldig, 24 Stunden am Tag. Das senkt die Eintrittshürde für Angriffe massiv.

Was ist RAG und warum ist der Datenzugriff so kritisch?

RAG steht für Retrieval Augmented Generation – eine Technik, bei der KI-Systeme auf eine externe Wissensdatenbank zugreifen, um präzisere Antworten zu liefern. Statt alles im Modell selbst zu speichern, liest das System bei jeder Anfrage relevante Dokumente aus einer Datenbank heraus und kombiniert sie mit dem Sprachmodell.

Das Problem: Diese Datenbanken enthalten oft die sensibelsten Informationen eines Unternehmens. Kundendaten, interne Prozesse, Strategiepapiere, Mitarbeiterinformationen. Wer Zugriff auf die RAG-Datenbank bekommt, bekommt Zugriff auf das Gehirn der KI-Plattform. Im McKinsey-Fall waren das 3,68 Millionen Dokument-Chunks.

Was das für euer Unternehmen heisst

Hand aufs Herz. Wann habt ihr das letzte Mal eure KI-Systeme auf Sicherheit getestet? Nicht die IT-Infrastruktur. Die KI-Systeme. Die Prompts. Die API-Endpunkte. Die Datenbanken, in denen eure RAG-Dokumente liegen.

Die meisten Unternehmen, die ich berate, haben keine Antwort auf diese Frage. Nicht weil sie fahrlässig sind. Sondern weil KI-Security ein blinder Fleck ist. Alle reden über Use Cases und Produktivität. Kaum jemand redet über Angriffsflächen.

Bei CTRL+ALT+LEAD sagen wir: KI einführen ohne Security mitzudenken ist wie ein Haus bauen ohne Schlösser. Sieht erstmal gut aus – solange, bis jemand reinspaziert.

Die gute Nachricht

McKinsey hat innerhalb von 24 Stunden reagiert und alle Schwachstellen geschlossen. CodeWall hat Responsible Disclosure praktiziert, also vorher Bescheid gesagt, bevor sie den Hack öffentlich gemacht haben.

Das zeigt: Wenn du weisst, dass da ein Problem ist, kannst du es schnell fixen. Das Problem ist das „wenn du weisst“. Die meisten Unternehmen wissen es nicht. Weil sie nicht testen.

Drei Fragen, die sich jedes Unternehmen jetzt stellen sollte

Wer hat Zugriff auf die Datenbanken hinter unseren KI-Systemen? Sind unsere API-Endpunkte gegen Injection-Angriffe geschützt? Was passiert, wenn jemand unsere System-Prompts verändert?

Wenn ihr auf eine dieser Fragen keine klare Antwort habt, dann wisst ihr, was eure nächste Priorität sein sollte.

Häufige Fragen zur KI-Agent-Sicherheit

Was ist Prompt Injection und wie funktioniert der Angriff?

Prompt Injection ist ein Angriff, bei dem schädliche Anweisungen in die Eingabe eines KI-Systems eingebettet werden, um das Verhalten des Modells zu manipulieren. Im einfachsten Fall wird versucht, die ursprünglichen System-Anweisungen zu überschreiben. Im fortgeschrittenen Fall – wie beim McKinsey-Hack – wird ein autonomer Agent genutzt, der SQL-Injections in API-Endpunkte einschleust, um auf Backend-Datenbanken zuzugreifen. Diese Angriffe sind besonders gefährlich, weil KI-Systeme von Natur aus darauf ausgelegt sind, Textinstruktionen zu folgen.

Wie schütze ich mein KI-System vor Agent-Angriffen?

Die wichtigsten Massnahmen: Input-Validierung und -Sanitierung bei allen API-Endpunkten, Principle of Least Privilege (KI-Systeme erhalten nur Zugriff auf das, was sie wirklich brauchen), regelmässige Penetrationstests speziell für KI-Systeme, Monitoring und Logging aller Datenbankzugriffe sowie klare Trennung zwischen Produktionsdaten und KI-Testumgebungen. KI-Security ist kein einmaliges Projekt, sondern ein laufender Prozess.

Was ist der Unterschied zwischen traditioneller IT-Security und KI-Security?

Traditionelle IT-Security befasst sich hauptsächlich mit Netzwerken, Zugangskontrollen und Software-Schwachstellen. KI-Security umfasst zusätzlich modellspezifische Angriffsvektoren: Prompt Injection, Adversarial Inputs (manipulierte Eingaben, die das Modell in die Irre führen), Datenextraktion aus Trainings- oder RAG-Daten sowie Model Poisoning (Manipulation der Trainingsdaten). KI-Systeme vergrössern die Angriffsfläche, weil sie auf natürlichsprachige Eingaben reagieren – und diese lassen sich schwerer als klassische Code-Injections filtern.

Müssen kleine Unternehmen sich um KI-Security sorgen?

Ja – gerade kleine und mittelständische Unternehmen sind oft stärker gefährdet, weil sie KI-Tools schnell einführen, ohne Security-Teams oder dedizierte IT-Sicherheitsspezialisten zu haben. Wer Kundendaten, interne Dokumente oder Geschäftsgeheimnisse in KI-Systeme einführt, schafft automatisch neue Angriffsflächen. Die gute Nachricht: Die wichtigsten Schutzmassnahmen sind keine Raketenwissenschaft. Sie erfordern Bewusstsein und einen strukturierten Ansatz – keine Millionenbudgets.

Ähnliche Beiträge