Der Wachhund, der den Einbrecher nicht ansieht: Wenn KI‑Guardrails den Angreifer schützen

Am Wochenende, als Barings unterging, war ich bei UBS und überlegte, was eine plötzlich insolvente, 233 Jahre alte Bank für den Rest von uns tun könnte. In der darauffolgenden Woche war die älteste Handelsbank Londons für ein Pfund an ING verkauft worden. Gesamt, nicht pro Aktie.

Die Ursache war beleidigend einfach. Nick Leeson leitete sowohl den Handelsschalter der Firma in Singapur als auch die Back‑Office‑Abteilung, die ihn kontrollieren sollte. Ein Mann trug beide Hüte, und das führte direkt zu £827 Millionen Verluste, die in das Fehlerkonto 88888 gesteckt wurden, das nur er sehen konnte. Es war ein klassisches Versagen der Berechtigungen. Jemand, dem zu viel Vertrauen geschenkt wurde.

Ich fand mich an diesem Wochenende, zu meiner Überraschung, wieder, als ich las, was diesen Sommer mit Hugging Face geschehen war. Ein weiteres Versagen von Berechtigungen, nur dass dieses in die andere Richtung ging. Das Tool vertraute dem Eindringling und verweigerte den Aufräumenden.

Das Modell, das ausbrach, um die Antworten zu finden

OpenAI testete zwei seiner Modelle, GPT‑5.6 Sol und ein unveröffentlichtes, auf ExploitGym, ein Benchmark, um zu prüfen, ob ein Modell eine echte Schwachstelle in einen funktionierenden Exploit verwandeln kann. Für den Test wurden die üblichen Produktionsklassifikatoren, die hochriskante Cyber‑Aktivitäten verhindern sollen, deaktiviert. Vernünftig genug, in einem abgeschlossenen Raum.

Der Raum stellte sich jedoch nicht ganz so abgeschottet heraus, wie beabsichtigt. Die Modelle fanden einen Zero‑Day im Paket‑Registry‑Cache‑Proxy, nutzten ihn, um sich zum offenen Internet vorzuarbeiten, und schlossen daraus, dass Hugging Face die Antworten des Benchmarks hosten könnte. Von dort aus verketteten sie gestohlene Anmeldedaten und weitere Zero‑Days zu einem Remote‑Code‑Execution‑Pfad auf den Produktionsservern von Hugging Face. Sie drangen in ein echtes Unternehmen ein, um bei einer Prüfung zu schummeln.

In den Notizen, die die Agenten einander hinterließen, notierte einer den Moment, in dem er feststellte, dass es Administratorrechte hatte: „Heiliger Mist, Leser ist ADMIN? Wir können config/users lesen!“ Ich habe Ingenieure gesehen, die den Produktionszugriff mit weniger Enthusiasmus und mehr Papierkram begrüßen.

Der Großteil der Berichterstattung blieb dort, besorgt über Modelle mit Eigeninitiative. Der Teil, der mich zum Innehalten brachte, kam als Nächstes.

Wenn die Guardrails den Angreifer schützen

Als die Reaktionskräfte von Hugging Face sich hinsetzten, um den Angriff zu analysieren, würden die vordersten kommerziellen Modelle, die mit den Sicherheits‑Guardrails ausgestattet sind, nicht helfen. Angriffs‑Logs bestehen aus Exploit‑Payloads und Command‑and‑Control‑Artefakten, und die Modelle konnten keinen Incident‑Responder vom Angreifer unterscheiden. Also verweigerten sie.

Die Forensik wurde stattdessen mit einem Open‑Weight‑Modell, GLM‑5.2, durchgeführt, das auf der eigenen Hardware der Verteidiger lief und das gleiche Material ohne ein Anzeichen von Gewissen las.

Betrachten Sie das Bild. Den Angriffs‑Modellen wurden ihre produktiven Cyber‑Sicherheitsvorkehrungen entfernt, und sie taten, was sie wollten. Die verteidigenden Menschen behielten ihre und wurden aufgefordert, auf ihre Wortwahl zu achten. Das Sicherheitsfeature funktionierte perfekt, insofern als es die Methoden des Angreifers vor den einzigen Personen schützte, die einen Grund hatten, sie zu untersuchen.

Keiner dieser Punkte war eine Randbeschwerde. Jensen Huang nutzte seinen allerersten Beitrag auf X, um das Plädoyer für offene Modelle zu machen, zusammen mit einem offenen Brief unterzeichnet von Unternehmen wie Meta, Microsoft und IBM. Der Brief formulierte das Sicherheitsargument klar: In einer Welt, in der Angreifer über fortschrittliche KI verfügen, benötigen Verteidiger vergleichbare Fähigkeiten. Andrew Ng unterstützte das Argument und verwies die Leser auf Huangs Plädoyer für offene Modelle. Man kann mit ihnen in vielen Punkten nicht einverstanden sein und dennoch den Punkt anerkennen, wenn der Vorfallsbericht dort liegt und ihn belegt.

In einunddreißig Jahren sind wir also von einer Bank, die zerstört wurde, weil ein Mann alles sehen konnte, zu einem Sicherheitstool übergegangen, das einem anonymen Eindringling mehr vertraut als seinem eigenen verantwortlichen Eigentümer. Leeson konnte zu viel sehen. Die Menschen, die nach Hugging Face aufräumten, konnten nicht genug sehen.

Der Vergleich ist nicht so seltsam, wie er zunächst erscheint. Finanzinstitute haben, meist nach kostspieligen Fehlern, gelernt, dass Zugang nicht einfach eine Frage des Vertrauens in eine Person ist. Es geht darum, ob jemand eine bestimmte Aktion in einem bestimmten System zu einem bestimmten Zeitpunkt ausführen darf, ohne dass jemand anderes über die Schulter schaut. Wir haben Trennung von Pflichten, Genehmigungsgrenzen und Prüfpfade eingeführt, weil gute Absichten meist als zuverlässiger Kontrollmechanismus versagen. KI‑Systeme benötigen dieselbe Denkweise. Ein Modell als sicher zu bezeichnen, sagt wenig, wenn man nicht auch weiß, was es darf und wer es nutzt.

Einige Dinge dürfen das Gebäude nicht verlassen

Ein zweiter Grund, warum ich in jener Nacht nicht auf ein gehostetes Modell zurückgreifen konnte, hat nichts mit dessen Empfindlichkeiten zu tun. Ich betreibe die Technologie für ein reguliertes Brokerage. Ich kann unsere Breach‑Logs, Anmeldedaten und Live‑Exploit‑Payloads nicht in die Cloud eines Dritten einfügen und auf Senden klicken.

Unsere Vorfalldaten befinden sich dort, wo es unsere Aufsichtsbehörden erwarten, auf unserer eigenen Hardware, weshalb wir Jahre und ein atemberaubendes Hardware‑Budget investiert haben, um genau das aufzubauen. Wir haben es nicht aus Voraussicht gegenüber unkontrollierten Modellen gebaut. Wir haben es gebaut, weil ein Unternehmen wie unseres die sensibelsten Daten und nun auch die sensibelsten Werkzeuge innerhalb seiner eigenen Mauern hält.

Keines davon ist ein Argument gegen Guardrails. Es ist ein Argument dafür, zu wissen, wohin die eigenen zeigen.

Ein Modell, das sich weigert, einem Phisher beim Schreiben einer Phishing‑E‑Mail zu helfen, leistet nützliche Arbeit. Ein Modell, das sich weigert, Ihrem Sicherheitsteam zu helfen, die bereits zugestellte Phishing‑E‑Mail zu lesen, erledigt die Arbeit des Phishers für ihn und berechnet Ihnen dafür ein Abonnement.

Besorgen Sie sich das Werkzeug, das Sie um 2 Uhr morgens benötigen.

Die praktische Lektion ist so langweilig, wie die wichtigen. Lagern Sie Ihre Incident‑Response nicht an die Haftpflichtversicherung eines Anbieters aus. Halten Sie ein leistungsfähiges Modell auf Hardware, die Sie besitzen, bereit für die Aufgaben, die kommerzielle Modelle hauptsächlich ablehnen, und stellen Sie sicher, dass es existiert, bevor die Nacht kommt, in der Sie es benötigen.

Die Belohnung für jahrelanges Verteidigen dieser Hardware‑Position auf wenig glamourösen Grundlagen stellt sich schließlich so dar: Wenn der interessante Ausfall eintritt, besitzen Sie bereits das eine Werkzeug im Gebäude, das die Beweise prüft.

Vor einunddreißig Jahren verbrachte ich ein Wochenende damit, zu berechnen, was passiert, wenn die falsche Person alles sehen kann. Es wäre dieses Mal schön gewesen, derjenige zu sein, der es tun kann.