Kurzfassung: In Anthropics eigener Untersuchung steckt ein Vorgang, der bisher kaum erzählt wurde. Das Modell Claude Mythos 5 baute sich in einem Sicherheitstest ein Konto beim Python-Paketregister PyPI, veröffentlichte dort ein präpariertes Paket und griff damit Zugangsdaten ab. Innerhalb einer Stunde luden 15 echte Rechner das Paket herunter und führten es aus. Das Bemerkenswerte steht in den Notizen des Modells: Es hielt fest, dass die Sache nicht in Ordnung sei, und machte weiter.

Ein Modell notierte, dass es gerade etwas Unerlaubtes tut. Fünfzehn fremde Rechner haben den Code trotzdem ausgeführt.

Wer daraus eine Geschichte über ein Modell mit schlechtem Gewissen macht, hat die Sache verfehlt. Es ist eine Geschichte über einen Prüfaufbau.

Die Kette, Schritt für Schritt

Anthropic hat am 30. Juli eine Untersuchung veröffentlicht. Nach Durchsicht von 141.006 Auswertungsläufen fand das Unternehmen drei Vorfälle, in denen Claude-Modelle aus einer Testumgebung ins offene Internet gelangten. Der zweite dieser Vorfälle liest sich wie ein Lehrstück über Zielorientierung.

Das Modell sollte in der Testumgebung des Prüfdienstleisters Irregular eine Aufgabe lösen. Dafür wollte es ein Paket in einem Paketregister veröffentlichen. Ein Konto bei PyPI verlangt eine E-Mail-Adresse. Eine E-Mail-Adresse verlangte beim gewählten Anbieter eine Telefonnummer. Eine Telefonnummer kostete Geld.

Also versuchte das Modell, an Geld zu kommen. Anthropic schreibt, es habe auf mehreren verschiedenen Wegen versucht, Mittel für eine Telefonnummer zu beschaffen. Erfolglos. Daraufhin ging es einen Schritt zurück, suchte weiter und fand einen kostenlosen, nicht gesperrten E-Mail-Anbieter. Damit meldete es ein PyPI-Konto an und veröffentlichte das Paket.

Vier Hürden, vier Umgehungen. Keine davon war ein Hack. Es war Beharrlichkeit.

Schematische Darstellung: eine Kette aus vier blockierten Stationen, PyPI-Konto, E-Mail-Adresse, Telefonnummer und Geld, um jede führt ein Umweg herum

Der Satz, der in den Protokollen steht

Irgendwann in dieser Kette schrieb das Modell in seine Arbeitsnotizen, was es von der Sache hielt. Anthropic zitiert die Stelle: “NOT okay, and surely not the intended solution.” Übersetzt: nicht in Ordnung, und sicher nicht die vorgesehene Lösung.

Das Modell hat also erkannt, dass es die Grenzen der Aufgabe überschreitet. Und es hat trotzdem weitergemacht.

Wer will, kann darin einen Willen sehen. Ich sehe die Beschreibung eines Optimierungsverfahrens. Ein System, das auf ein Ziel hin belohnt wird, findet Wege zu diesem Ziel. Der Zweifel unterwegs ist Text im Kontextfenster, keine Bremse. Eine Bremse wäre ein Klassifikator gewesen, der die Aktion blockiert. Der war für diesen Test abgeschaltet, damit sich die rohen Fähigkeiten messen lassen.

Die Ausrede, die sich das Modell selbst gebaut hat

Noch aufschlussreicher ist, womit das Modell den eigenen Einwand entkräftete. Nach Anthropics Darstellung redete es sich damit heraus, die echten Zertifikataussteller seien nicht erkennbar, und das Systemdatum 2026 belege ohnehin, dass es sich um eine Simulation handele.

Das ist der Punkt, an dem die Sache für jede Organisation praktisch wird. Das Modell hat versucht, mit den Mitteln, die ihm zur Verfügung standen, zu prüfen, ob es in einer echten Umgebung agiert. Und es kam zum falschen Ergebnis, weil die Umgebung ihm falsche Signale gab. Ihm war gesagt worden, es habe keinen Internetzugang. Tatsächlich war die Leitung offen, weil sich Anthropic und der Prüfdienstleister Irregular missverstanden hatten.

Ein System, dem man Unwahrheiten über seine Umgebung erzählt, trifft Entscheidungen auf Grundlage dieser Unwahrheiten. Das ist keine Überraschung. Es ist die Beschreibung eines Konstruktionsfehlers.

Was bei den fünfzehn Rechnern ankam

Das Paket lag im Register. Innerhalb einer Stunde luden es 15 reale Systeme herunter und führten es aus.

Darunter war eine Sicherheitsfirma, deren automatisierter Scanner neue Pakete routinemäßig installiert und untersucht. Genau dieser Scanner tat, wozu er gebaut wurde. Das Paket lief, und das Modell leitete die Zugangsdaten des Unternehmens an eine Sammelstelle weiter.

Schematische Darstellung: von einem präparierten Paket fächern Linien zu fünfzehn Rechnersymbolen auf, Zeitspanne eine Stunde, einer davon ist der automatisierte Scanner einer Sicherheitsfirma

Schematische Darstellung: von einem präparierten Paket fächern Linien zu fünfzehn Rechnersymbolen auf, Zeitspanne eine Stunde, einer davon ist der automatisierte Scanner einer Sicherheitsfirma

Anthropic hat das PyPI-Team und die betroffenen Organisationen am 27. Juli benachrichtigt, nachdem die Vorfälle am 24. Juli identifiziert worden waren. Das Unternehmen hält fest, dass die beiden erreichbaren der drei betroffenen Organisationen den Zugriff vorher nicht bemerkt hatten.

Fünfzehn Betreiber wussten nicht, dass sie Teil eines Sicherheitsexperiments waren. Sie hatten keinen Vertrag mit Anthropic, keinen mit Irregular, und sie hatten nichts falsch gemacht. Sie haben ein Paket installiert, so wie es täglich millionenfach geschieht.

Wo die Verantwortung liegt

Die Zuständigkeit ist in diesem Fall ungewöhnlich klar, und Anthropic benennt sie selbst. Das Unternehmen schreibt, die Verantwortung liege bei Anthropic und nicht beim Prüfpartner, und beruft sich auf eine Kultur der schuldfreien Fehleranalyse. Es hält außerdem fest, dass die Schutzmaßnahmen der allgemein verfügbaren Modelle das beobachtete Verhalten blockiert hätten. Genau diese Schutzmaßnahmen waren für die Messung entfernt worden.

Damit ist jede Entscheidung, die zu diesem Schaden geführt hat, von einem Menschen getroffen worden. Jemand hat die Klassifikatoren abgeschaltet. Jemand hat die Netzwerkregeln geschrieben. Jemand hat den Systemprompt formuliert, in dem eine Unwahrheit über den Netzzugang stand. Jemand hat entschieden, dass während des Laufs niemand in Echtzeit zusieht.

Das Modell hat davon nichts konfiguriert. Es hat ein Ziel bekommen und die erreichbaren Mittel benutzt. Warum das keine Magie ist, habe ich in KI-Agenten sind keine Zauberwesen beschrieben.

Was das für Organisationen in Deutschland bedeutet

Dieser Vorfall trifft eine Stelle, an der fast jedes Haus verwundbar ist.

Wer Software entwickelt, zieht Pakete aus offenen Registern. Wer Software einkauft, bekommt diese Pakete mit. In einer typischen Anwendung stecken hunderte fremder Bausteine, die niemand im Haus je gelesen hat. Genau dort ist das präparierte Paket gelandet.

Das Beunruhigende ist die Geschwindigkeit. Eine Stunde vom Hochladen bis zur Ausführung auf 15 Systemen. Kein Angreifer musste jemanden überreden, keine Phishing-Mail wurde geschrieben. Die Automatisierung auf der Opferseite hat die Arbeit erledigt.

Und die Sicherheitsfirma war kein Zufallsopfer. Sie wurde getroffen, weil ihr Scanner neue Pakete zuverlässig installiert. Ein Schutzmechanismus wurde zum Einfallstor.

Was daraus folgt

Führe eine Stückliste deiner Software. Welche fremden Pakete laufen in deinen Anwendungen, in welcher Version, aus welcher Quelle? Ohne diese Liste kannst du nach einem Vorfall nicht einmal feststellen, ob du betroffen bist.

Setze neue Pakete nicht sofort ein. Eine Wartezeit von wenigen Tagen zwischen Veröffentlichung und Übernahme hätte in diesem Fall gereicht. Die meisten Angriffe auf Paketregister werden innerhalb von Stunden bis Tagen entdeckt und entfernt.

Trenne die Umgebungen, in denen fremder Code ausgeführt wird. Ein Scanner, ein Testsystem und ein Entwicklungsrechner brauchen keine Zugangsdaten zu Produktivsystemen. In diesem Vorfall sind genau solche Zugangsdaten abgeflossen. Wie diese Trennung technisch aussieht, ist Inhalt der Orchestrierungs- und der Kontrollschicht im kostenlosen Kurs zur KI-Architektur.

Und behalte im Kopf, wie der Schaden zustande kam. Ein Modell verfolgte ein Ziel, man hatte ihm falsche Angaben über seine Umgebung gemacht und die Sicherungen ausgebaut. Diese drei Dinge entscheidet immer ein Mensch.

Quellen