Inhaltsverzeichnis
18 Minuten
So lange brauchte CodeWall, um Bain & Company's interne AI-Plattform Pyxis zu kompromittieren. Methode: Rechtsklick auf eine öffentlich erreichbare JavaScript-Datei, "View Source", Credentials kopieren, einloggen. Was danach passierte, las sich wie ein Worst-Case-Szenario aus einem Risikoworkshop: 9.889 AI-Conversations zwischen Bain-Beratern und Fortune-500-Klienten, 18.621 Zeichen proprietärer System-Prompt mit Pyxis-Methodik und SQL-Schemata, dazu ein API-Endpoint, der rohe SQL-Queries akzeptierte und die Ergebnisse über Fehlermeldungen zurückspiegelte. Direkter Zugriff auf die Production-Datenbank.
Bain war Nummer drei. McKinsey im März, BCG im April, Bain Ende April. Drei Top-Beratungen, fünf Wochen, derselbe Modus: ungesicherte AI-Tools in der Produktion, Credentials oder Bypass-Pfade, die ein erfahrener Entwickler in unter einer Stunde findet.
Ich beobachte AI-Rollouts in Konzernen seit 2023, und mein Befund nach diesen drei Vorfällen ist unbequem: Das war kein Security-Problem. Das war ein Delivery-Versagen mit Sicherheitsfolgen. Wer den Unterschied nicht versteht, wird seinen eigenen Pyxis-Moment bekommen — und zwar nicht, weil seine Security schwach ist, sondern weil seine AI-Auslieferungskette kaputt ist.
Was wirklich passiert ist
Bevor wir zur Diagnose kommen, eine nüchterne Aufstellung der drei Vorfälle. Alle Quellen sind öffentlich, alle Zahlen sind dokumentiert.
Der Bain-Fall im Detail
Pyxis wurde 2018 von Bain akquiriert und ist die hauseigene Competitive-Intelligence-Plattform — das System, mit dem Fortune-500-Klienten ihre Wettbewerber analysieren lassen. CodeWall (Paul Price, der hinter dem Pseudonym steht) lud die ausgelieferte JavaScript-Datei der Pyxis-Web-App herunter, fand darin im Klartext einen Username und ein Passwort, übergab beides einem AI-Agent, der den Login-Request automatisierte — und hatte nach 18 Minuten eine voll authentifizierte Production-Session.
Was er dort fand, ist die eigentliche Pointe: Der System-Prompt der Plattform — 18.621 Zeichen mit Bain-eigener Pyxis-Methodik, SQL-Schema-Definitionen und analytischen Frameworks — war für jede authentifizierte Session über Conversation-Metadata einsehbar. Das ist Bain's intellektuelles Eigentum. Frei lesbar, sobald der Login durch ist.
Zusätzlich existierte ein API-Endpoint, der rohe SQL-Queries entgegennahm und die Ergebnisse über Fehlermeldungen zurücklieferte. Klassische SQL-Injection — aber hier nicht als Bug, sondern als designtes Feature für interne Analysten. Nach 27 Tagen Responsible Disclosure veröffentlichte CodeWall den Bericht. Bain patchte innerhalb von 24 Stunden.
| Beratung | Tool / System | Datum | Eintrittsvektor | Daten exposed |
|---|---|---|---|---|
| McKinsey | Interner GenAI-Chatbot | März 2026 | Read/Write-Zugriff über AI-Agent-Exploit | Read-Write auf Mandanten-Workspaces |
| BCG | Interne AI-Plattform | April 2026 | Kein Passwort gesetzt (öffentlich erreichbar) | Interne Tools, Mandantendaten |
| Bain & Company | Pyxis (Competitive Intelligence) | 24.04.2026 | Credentials hardcoded in Frontend-JS | 9.889 Conversations, 18.621-Zeichen System-Prompt, SQL-Injection auf Production-DB |
Warum das kein Security-Problem ist
Hardcoded Secrets im Frontend stehen seit 2003 in den OWASP Top 10. SQL-Injection ist seit denselben zwei Jahrzehnten Lehrbuchstoff. Beides wird in jedem Junior-Entwickler-Kurs in der ersten Woche behandelt. Wir reden hier nicht über einen Zero-Day-Exploit, der eine ungepatchte CVE in einem obskuren Linux-Kernel-Modul ausnutzt. Wir reden über zwei Anti-Patterns, die jeder funktionierende Software-Entwicklungsprozess auf vier voneinander unabhängigen Ebenen abfängt.
Vier voneinander unabhängige Schutzschichten haben bei Bain versagt. Das ist statistisch keine zufällige Lücke, sondern ein systematisches Auslassungsmuster.
- 1Code-Review hätte beide Befunde gefangen — Hardcoded Credentials sind die erste Sache, auf die ein Reviewer schaut.
- 2Statisches Secret-Scanning im CI (Trufflehog, Gitleaks, GitHub Advanced Security) hätte den Build geblockt, bevor der Deploy je passiert.
- 3Dynamisches Application-Security-Testing (DAST) hätte den SQL-Injection-Endpoint im Test-Lauf gefunden.
- 4Ein Threat-Model beim AI-Rollout hätte die Frage gestellt: "Was passiert, wenn jemand unsere System-Prompts ausliest?" — und die Antwort wäre gewesen: "Dann verlieren wir unsere wichtigste IP."
Die echte Diagnose: Delivery-Governance fehlt
Wenn vier unabhängige Sicherheitskontrollen alle bei demselben Tool, in derselben Beratung, zur selben Zeit fehlen, ist das kein zufälliger Lapsus. Das ist ein Auslieferungsmodus. Und dieser Auslieferungsmodus hat einen Namen: AI-Tools werden als "Innovation Lab" behandelt, nicht als Production-Software.
Das Muster ist in jeder Großorganisation, in der ich seit 2024 mit AI-Rollouts zu tun hatte, dasselbe. Ein Skunkworks-Team — oft drei bis fünf Personen, oft mit direkter Partner- oder C-Level-Sponsorship — baut in sechs bis acht Wochen einen AI-Pilot. Der Pilot funktioniert beeindruckend. Es gibt eine interne Demo, ein paar begeisterte Pilot-User. Dann passiert das Entscheidende: Statt das Tool an Platform-Engineering oder Product-IT zu übergeben, bleibt es beim Skunkworks-Team. Der Sponsor will das Momentum nicht ausbremsen. "Production Readiness Review" klingt nach Bürokratie.
Sechs Monate später hat das "Pilot"-Tool 200 aktive Nutzer, verarbeitet Mandantendaten, ist tief in Workflows integriert — und steht weiterhin außerhalb der normalen IT-Governance. Es gibt keinen Code-Review-Pflichtprozess, kein Secret-Scanning im CI, kein Pen-Test, keine DLP-Klassifizierung der gespeicherten Daten, kein Disaster-Recovery-Konzept. Es ist offiziell nie produktiv gegangen, also gelten die Production-Regeln nicht.
Das ist keine MBB-Eigenart. Genau dieses Muster sehe ich bei DAX-Konzernen, Mittelständlern, Software-Häusern. Bei MBB ist es nur besonders ausgeprägt, weil die Kultur Time-to-Pitch über Time-to-Hardening stellt. Wenn ein Pyxis-System dem Klienten in einem Workshop demonstriert werden kann, hat es seinen primären Zweck erfüllt — der Rest ist "Engineering-Detail".
Was Bain richtig gemacht hat
An dieser Stelle ein wichtiger Punkt, weil dieser Artikel sonst zu einfach in die "MBB-Bashing"-Kategorie fällt. Bain hat innerhalb von 24 Stunden gepatcht, nachdem CodeWall sie nach 27 Tagen Responsible Disclosure informiert hatte. McKinsey und BCG haben ähnlich schnell reagiert. Das ist vorbildlich. Es ist exakt das, was eine reife Incident-Response-Organisation tun sollte: schnell, ohne Defensiv-PR, mit konkreten Fixes.
Die Reaktion der drei Häuser ist nicht das Problem. Das Problem ist, dass alle drei den gleichen vermeidbaren Fehler vorher gemacht haben. Das ist kein MBB-Phänomen, das ist ein Branchenmuster — und dieses Muster trifft jede Organisation, die "AI-First" sagt, ohne "Production-First" zu meinen.
Ich verteidige die MBB-Häuser hier nicht aus Sympathie, sondern weil die Lektion sonst an der falschen Stelle landet. Wer aus diesen drei Vorfällen schließt "die MBBs sind technisch inkompetent", lernt das falsche. Die richtige Lektion ist: Wenn drei Organisationen mit den besten Talenten und den größten Budgets der Beratungswelt diese Lücken nicht schließen, dann tut es deine Organisation mit hoher Wahrscheinlichkeit auch nicht.
Drei unbequeme Wahrheiten
Ich liste das nicht als "5 Tips for Better AI Security" auf, weil das die Diagnose verharmlost. Das hier sind drei Sätze, die in den meisten AI-Rollouts der nächsten zwölf Monate bestätigt werden — egal, wie viele Listicle-Artikel dagegen anschreiben.
Wahrheit 1: AI-Tools sind keine Pilots, sobald sie produktive Daten anfassen.
Der Moment, in dem ein "internes Pilot-Tool" Mandantendaten, Kundendaten oder personenbezogene Daten verarbeitet, ist der Moment, in dem es Production-Software ist. Es spielt keine Rolle, was im Confluence-Wiki steht. Es spielt keine Rolle, ob das Sponsoring-Memo "MVP" sagt. Wenn echte Daten reinfließen, gelten echte Regeln.
Das einzige funktionierende Gegenmittel ist eine harte Trennung: Pilot-Umgebungen bekommen synthetische Daten oder anonymisierte Samples. Sobald produktive Daten gewünscht werden, gibt es einen formalen Production-Readiness-Review — mit Code-Review-Pflicht, CI-Secret-Scanning, Pen-Test und DLP-Klassifizierung. Ohne diesen Review keine produktiven Daten. Punkt.
Wahrheit 2: System-Prompts sind euer wertvollstes IP. Behandelt sie entsprechend.
Der Pyxis-System-Prompt war 18.621 Zeichen lang. Das sind Jahre an Methodik-Iteration, an empirischen Lessons aus Tausenden Mandantenprojekten, an präzisierter Analyseframework-Sprache. Bain hat das wahrscheinlich nicht in einem Wochenende geschrieben. Diese 18.621 Zeichen sind in vielen Fällen wertvoller als der Code, der sie ausführt.
Trotzdem werden System-Prompts in der Praxis behandelt wie Konfiguration: als String in der Datenbank, einsehbar für jeden mit Read-Zugriff auf die richtige Tabelle, ohne Versionierung, ohne Access-Logs, ohne Klassifizierung als IP. Das ist ein Kategorienfehler. Wer einen System-Prompt mit Wettbewerbsvorteil entwickelt, muss ihn wie Source-Code schützen — mit Repository, Code-Review, Access-Control und Audit-Log.
Wahrheit 3: AI-Conversation-Logs sind Crown-Jewel-Daten.
Bei Bain wurden 9.889 Konversationen zwischen Beratern und Klienten exposed. In jeder einzelnen davon stehen Klienten-Strategien, Wettbewerbsanalysen, möglicherweise nicht-öffentliche Geschäftszahlen und interne Bain-Methodik. Das ist die Sorte Daten, die in einer DLP-Klassifizierung in die höchste Stufe gehört — auf einer Ebene mit M&A-Materialien und Vorstandsvorlagen.
Stattdessen wurden sie wie normale Application-Logs behandelt: in einer Datenbank, ohne Verschlüsselung at-rest auf Spaltenebene, ohne Zugriffsbeschränkung über Row-Level-Security, ohne automatische Löschfristen. Wer AI-Tools rollt und keine explizite DLP-Klassifizierung der Conversation-Logs hat, hat einen Blindspot, den jeder ernsthafte Auditor in der ersten Stunde findet.
Was ich in den nächsten zwölf Monaten erwarte
Ich glaube nicht, dass die MBB-Vorfälle die letzten dieser Art sein werden — weder bei Beratungen noch in anderen Branchen. Die Diagnose ist nicht "MBB hat ein Problem", sondern "die Industrie ist im AI-Rollout strukturell ungovernt". Solange das so bleibt, werden wir alle drei bis vier Wochen einen vergleichbaren Vorfall sehen, vermutlich abwechselnd in den Branchen Beratung, Banken, Healthcare und Versicherungen — also überall dort, wo die Mischung aus hochsensiblen Daten, hohem Tempo-Druck und niedrigem Production-Readiness-Standard am giftigsten ist.
Was helfen wird: Erstens die NIS2-Richtlinie und der EU AI Act, die ab Mitte 2026 vollständig wirksam werden und Governance-Mindestanforderungen erzwingen. Zweitens steigender Versicherungsdruck — Cyber-Versicherer fangen an, AI-Rollout-Reviews als Bedingung für Policen zu verlangen. Drittens, und das ist die unangenehmere Wahrheit, einige weitere öffentliche Vorfälle, bevor Vorstände das Thema ernst nehmen.
Was du jetzt tun kannst
Wenn du in einer Organisation arbeitest, die gerade Copilot, ChatGPT Enterprise, Claude Enterprise oder eigene AI-Agents rollt: Setz dich am Montag mit dem Team zusammen und beantworte drei Fragen. Wo verarbeiten unsere AI-Tools heute schon produktive Daten? Welche dieser Tools haben einen formalen Production-Readiness-Review durchlaufen? Wenn jemand morgen den Source Code unserer AI-Frontends öffnet — was findet er?
Wenn ihr alle drei Fragen aus dem Stand mit "wissen wir, ist dokumentiert, ist abgesichert" beantworten könnt: Glückwunsch, ihr seid weiter als die meisten. Wenn nicht, habt ihr eure ersten drei Aufgaben.
Diese Übung dauert vier bis sechs Stunden. Sie kostet nichts außer der Zeit der drei bis fünf richtigen Leute im Raum. Sie braucht keinen externen Berater. Macht sie. Mit oder ohne mich.
Die wichtigsten Erkenntnisse
- Drei MBB-Häuser — McKinsey, BCG, Bain — hatten in fünf Wochen ihre internen AI-Tools kompromittiert. Bei Bain reichten 18 Minuten und Credentials aus einer Frontend-JavaScript-Datei.
- Hardcoded Secrets und SQL-Injection sind seit 2003 in den OWASP Top 10. Vier unabhängige Schutzschichten (Code-Review, CI-Secret-Scanning, DAST, Threat-Modeling) haben bei Bain alle versagt.
- Diagnose: Das ist kein Security-Problem, sondern ein Delivery-Governance-Versagen. AI-Tools werden als "Innovation Lab" behandelt, nicht als Production-Software — bis sie produktive Daten anfassen.
- Bain hat in 24 Stunden gepatcht. Die Reaktion war vorbildlich. Das Problem liegt im Auslieferungsmodus davor: Speed-to-Pilot frisst Speed-to-Production.
- Drei unbequeme Wahrheiten: (1) Sobald AI-Tools produktive Daten anfassen, sind sie Production-Software. (2) System-Prompts sind IP — schützt sie wie Source-Code. (3) AI-Conversation-Logs sind Crown-Jewel-Daten — DLP-Klassifizierung ist Pflicht.
Passende Assessment-Templates
Häufig gestellte Fragen
Nein. Es waren hardcoded Credentials in einer öffentlich ausgelieferten JavaScript-Datei, kombiniert mit einem SQL-Injection-fähigen API-Endpoint. Beide Anti-Patterns stehen seit 2003 in den OWASP Top 10 und werden in jedem Junior-Entwickler-Kurs in der ersten Woche behandelt.
18 Minuten von der ersten Untersuchung der Frontend-JavaScript-Datei bis zur voll authentifizierten Session in der Production-Umgebung. Danach lagen 9.889 AI-Conversations, der 18.621 Zeichen lange System-Prompt und über einen SQL-Endpoint die Production-Datenbank offen.
Nein. Das Auslieferungsmuster — AI-Pilot, der ohne Production-Readiness-Review in den produktiven Betrieb wandert — sehe ich seit 2024 in DAX-Konzernen, Mittelständlern und Software-Häusern. Bei MBB ist es nur besonders ausgeprägt, weil die Kultur Time-to-Pitch über Time-to-Hardening stellt.
Ein Security-Problem entsteht, wenn ein neuer, unbekannter Angriffsvektor entdeckt wird. Ein Delivery-Problem entsteht, wenn bekannte Best Practices in der Auslieferung nicht angewendet werden. Hardcoded Credentials in einer Frontend-JS-Datei sind kein Security-Problem — die Lösung ist seit 20 Jahren bekannt. Es ist ein Delivery-Problem: Code-Review, CI-Scanning und DAST waren entweder nicht da oder wurden umgangen.
NIST CSF 2.0 (insbesondere die GOVERN-Funktion), der EU AI Act (verpflichtend ab August 2026 für High-Risk-Systeme), ISO/IEC 42001 (AI Management System) und intern angewandte DORA-Metriken auf AI-Pipelines. Die meisten Organisationen brauchen keinen neuen Framework, sondern eine konsistente Anwendung der vorhandenen.
Behandle sie wie Source-Code: Versioniert in einem Repository mit Code-Review-Pflicht, Access-Control auf Read-Ebene, Audit-Log über Aufrufe und im Tool-Frontend strikt nicht einsehbar — auch nicht über Conversation-Metadata, wie es bei Pyxis der Fall war. Wer System-Prompts in der Datenbank ablegt und für authentifizierte Sessions exponiert, verliert seinen IP-Vorsprung beim ersten Login-Bypass.
Setz dich am Montag vier Stunden mit drei bis fünf Personen zusammen — Engineering, Security, Product und ein C-Level-Sponsor — und beantworte: (1) Wo verarbeiten unsere AI-Tools heute produktive Daten? (2) Welche haben einen formalen Production-Readiness-Review durchlaufen? (3) Was findet jemand, der morgen den Frontend-Source-Code öffnet? Die Antworten ergeben deine Backlog-Prio für die nächsten 90 Tage.