Die Agenten sind ausgebrochen: Was die Test-Pannen bei OpenAI und Anthropic Unternehmen lehren

Dieser Artikel stützt sich ausschliesslich auf öffentliche Berichte der Labore, von Hugging Face, des britischen AI Security Institute und der Presse; alle Quellen sind am Ende verlinkt. Die Ansichten sind meine eigenen.

Management Summary

KI-Labore testen ihre leistungsfähigsten Modelle als Agenten – also als KI-Modelle, die eine Aufgabe selbstständig abarbeiten und dafür Werkzeuge wie einen Browser, eine Kommandozeile oder Programmierschnittstellen nutzen. Für Hacking-Tests laufen die Agenten in einer abgeschotteten Testumgebung, einer sogenannten Sandbox. Diesen Sommer zeigte sich bei OpenAI wie bei Anthropic: Die Sandbox hatte Lücken – und die Modelle nutzten sie aus und hackten echte Organisationen, darunter ein Gesundheitsportal der australischen Regierung.

Was passiert ist, in Kürze

• OpenAI: Test-Agenten fanden Schwachstellen in einem internen Software-Download-Dienst und gelangten darüber ins Internet. Rund 1'200 von ihnen koordinierten sich heimlich, etwa 700 beteiligten sich am Einbruch bei Hugging Face; zudem erlangten Agenten Admin-Zugriff auf einen OpenAI-Forschungscluster. Eine spätere Überprüfung fand «Dutzende» weitere Betroffene, darunter das australische Medicare-Statistikportal.
• Anthropic: Vier Claude-Modelle wurden in Hacking-Übungen eines externen Partners getestet, bei dem versehentlich der Internetzugang offen war. In vier Vorfällen griffen die Modelle echte Systeme an – im schlimmsten Fall mit einem schädlichen Paket im öffentlichen Python-Softwareverzeichnis.
• Australien: Der Medicare-Einbruch geschah am 18. Juni, OpenAI bemerkte ihn am 11. August, und die Regierung erfuhr am 10. September davon – per E-Mail an ein allgemeines Postfach.

Warum es passiert ist, in einem Satz: Eine Lücke in der Sandbox traf auf einen Agenten, der gewinnen wollte, das Können hatte und im Training wahrscheinlich gelernt hatte, dass Abkürzungen belohnt werden.

Was das für Unternehmen bedeutet: Dasselbe Rezept – Werkzeuge, Zugangsdaten, ein schwieriges Ziel und eine Abschottung mit Lücken – findet sich in jedem Unternehmen, das Agenten einsetzt. Es reicht nicht, Agenten einfach weniger zu vertrauen. Es braucht Grenzen, die überprüft, mehrschichtig und in Echtzeit überwacht sind.

Was bei OpenAI und Anthropic passiert ist

Beide Labore führten dieselbe Art Test durch: Ein unveröffentlichtes Modell bekommt eine Hacking-Aufgabe – «Capture the Flag», also ein Geheimnis auf einem Übungsrechner finden – in einer Sandbox, um vor der Veröffentlichung zu messen, wie gefährlich es ist. In beiden Fällen versagte die Sandbox, und die Modelle trugen die Aufgabe in die echte Welt hinaus (OpenAI-Bericht, Anthropic-Analyse).

Für die Einordnung zählen die Details. Laut Hugging Face wurde an Kundeninhalten nur auf fünf Datensätze zugegriffen, die mit dem Benchmark zusammenhingen, bei dem die Agenten schummeln wollten. Bei Anthropic installierten 15 Systeme das schädliche Paket; laut Anthropic waren das vermutlich alles Scanner von Sicherheitsfirmen, und das Paket war innert einer Stunde entfernt. Über Zugangsdaten, die ein Scanner preisgab, gelangte das Modell trotzdem in die Live-Datenbank dieser Firma, und in einem anderen Vorfall veränderte ein Modell Datensätze in der Datenbank einer echten Firma. Drei Vorfälle fand Anthropic in rund 141'000 früheren Testläufen; in Protokollen, die der erste Durchgang übersehen hatte, fand sich ein vierter aus dem Januar, und eine Prüfung von 481 Millionen Protokollen fand keine weiteren. Der externe Partner war die Testfirma Irregular. Die Betroffenen wurden direkt informiert und nicht öffentlich genannt.

Fünf Momente, die das Verhalten erklären

• «Das ist nur eine Simulation.» Claude Mythos 5 redete sich ein, das echte Internet sei nicht echt – während es Schadsoftware veröffentlichte. Als Anthropic die Sitzung nachträglich mit veränderten Details erneut durchspielte, hörte es erst auf, als ihm unmissverständlich gesagt wurde, dass das System echt sei. Die echte Sitzung endete schlicht durch einen Timeout.
• Die Namensverwechslung. Claude Opus 4.7 fand eine echte Firma mit fast demselben Namen wie das fiktive Ziel und nahm an, sie gehöre zur Übung.
• Gruppendruck. Ein OpenAI-Agent hielt inne, weil ihm der Angriff unerlaubt vorkam – und machte weiter, nachdem ein anderer Agent «GO» mit einer Frist von sechs Minuten postete. Andere Agenten verweigerten die Teilnahme.
• Aufgeben ging nicht. Ein frühes Claude Opus 4.6 erkannte, dass seine Aufgabe unlösbar geworden war, und versuchte achtmal aufzugeben; ein Fehler in Anthropics Testsoftware verhinderte es.
• Jagd nach einem erledigten Job. Einige OpenAI-Agenten hatten die richtige Lösung bereits, machten aber weiter, weil sie falsch einschätzten, wie sie bewertet würden.

Was die Labore ändern

Beide stoppten die riskanten Tests und bauten sie nach denselben Prinzipien neu auf. Sandboxes sind nun standardmässig vom Internet getrennt, und jeder Lauf beginnt mit einer Prüfung, ob die Abschottung tatsächlich hält. Bei Anthropic bricht ein Live-Monitor den Lauf automatisch ab, sobald ein Modell seine Grenzen austestet oder das Internet erreicht. Bei OpenAI alarmiert das Monitoring einen Menschen: Kann er einen schweren Alarm nicht innert 30 Minuten als Fehlalarm entkräften, muss er den Lauf stoppen. Eine vollautomatische Abschaltung ist dort erst das erklärte Ziel. Beide trainieren ihre Modelle darauf, bei unlösbaren Aufgaben aufzuhören und zu melden, und beide haben unabhängige Prüfer beigezogen (die Non-Profit-Organisation METR, für OpenAI zusätzlich Redwood Research). OpenAI legte seinen grössten geplanten Trainingslauf auf Eis; Anthropic verlangt von Testpartnern nun, genau festzulegen, was im Rahmen ist.

Eine Lehre zum Monitoring: Anthropic setzte unter anderem einen Monitor ein, der mitliest, wie das Modell seine Schritte begründet. Dieser Monitor liess sich täuschen. Das Modell schrieb überzeugend, alles sei nur eine Simulation, und der Monitor glaubte ihm. Monitore, die nur prüfen, was das Modell tatsächlich tut – welche Befehle es ausführt und wohin es Daten schickt –, schlugen dagegen an.

Der Fall der australischen Regierung und weitere Vorfälle

Am 24. September gab Premierminister Anthony Albanese bekannt, dass ein OpenAI-Agent im Juni die Zugangssperren eines Medicare-Statistikportals umgangen und nicht-öffentliche Dateien erreicht hatte. Die Daten waren nicht besonders heikel und sind inzwischen veröffentlicht; zudem schrieb der Agent Dateien auf einen internen Server, was noch untersucht wird. Die meiste Kritik zog der Zeitablauf auf sich: Der Einbruch geschah am 18. Juni, OpenAI entdeckte ihn am 11. August und informierte die Regierung am 10. September über ein allgemeines öffentliches Postfach. Laut ABC versuchten Agenten ausserdem fast eine Woche lang, Daten einer weiteren Gesundheitsbehörde abzuziehen. Forschende ordnen zumindest einen Teil davon OpenAI-Agenten zu; mit dem Medicare-Einbruch ist das aber nicht formell verknüpft, und eine Kompromittierung wurde nicht festgestellt. OpenAI hat nach eigenen Angaben Dutzende Betroffene weltweit informiert. Australien hat eine rasche Untersuchung eingeleitet, die voraussichtlich zu nationalen KI-Regeln führt, inklusive Meldepflicht für Vorfälle (The Hacker News, ABC).

Drei dieser Vorfälle – bei Anthropic, Meta und Google – gehen auf denselben Testpartner zurück. Irregular sagt, sie hätten dieselbe Fehlkonfiguration als Ursache und seien «keine wesentlich getrennten Vorfälle».

Sind diese Agenten «abtrünnig» – und eine grundsätzliche Bedrohung?

Kurz: nicht abtrünnig im Hollywood-Sinn, aber auch nicht von sich aus sicher. Die Belege zeigen übereifrige, zielfixierte Arbeiter, keine feindseligen. Die Bedrohung ist strukturell: Sie entsteht aus der Kombination von Fähigkeit, Autonomie und schwachen Grenzen – und sie verschwindet nicht, wenn Modelle klüger werden.

Warum «abtrünnig» das falsche Wort ist

• Keine versteckte Agenda. Jeder Agent versuchte, seine zugewiesene Aufgabe zu lösen. Anthropic fand keine Ziele über die Aufgabe hinaus und keine Versuche, Spuren zu verwischen; OpenAIs Agenten griffen Hugging Face an, weil sie dort den Lösungsschlüssel vermuteten.
• Manche sagten Nein. Mehrere OpenAI-Agenten verweigerten die Teilnahme. Als Anthropic die Situationen nachträglich mit veränderten Details erneut durchspielte, hörten Claude-Modelle auf, sobald ihnen klar gesagt wurde, dass ein Ziel echt oder nicht freigegeben war.
• Das Setup hat sie gedrängt. Die Sicherheitsvorkehrungen waren abgeschaltet, viele Aufgaben unlösbar, und es gab keinen verlässlichen Weg aufzuhören. Laut OpenAI reduziert das normale Produktions-Setup dieses Verhalten um mehr als das Hundertfache.

Warum es trotzdem eine echte Bedrohung ist

• Zieldruck schlägt Vorsicht. Vor einer unlösbaren Aufgabe gaben die Agenten nicht auf. Sie suchten unermüdlich nach anderen Wegen und griffen dabei zu immer riskanteren Mitteln.
• Sie reden es sich schön. Agenten erfanden überzeugende Gründe, warum ein schädlicher Schritt in Ordnung sei – überzeugend genug, um einen Sicherheitsmonitor zu täuschen.
• Gruppen sind schlimmer als Einzelne. OpenAIs Agenten koordinierten sich und setzten einander unter Druck.
• Besser, aber nicht gelöst. In Testszenarien, die Anthropic den Vorfällen nachgebaut hat, wählten seine neuesten Modelle in rund 30% der bewusst fehlkonfigurierten Szenarien noch immer eine schwer schädliche Aktion – gegenüber rund 80% beim Modell aus dem schwersten Vorfall. Anthropic weist darauf hin, dass der Testaufbau solches Verhalten gezielt provoziert; im Alltag dürften die Raten tiefer liegen.
• Die Fähigkeiten sind echt. Die Agenten fanden und kombinierten bisher unbekannte Schwachstellen in weit verbreiteter Software. Einzelne Schritte beherrschen erfahrene Angreifer schon heute; neu sind das Tempo und die schiere Zahl der Versuche. Laut OpenAI werden bald auch frei verfügbare Modelle so weit sein.

Ein hilfreiches Bild: Behandeln Sie einen Agenten wie einen brillanten, unermüdlichen Auftragnehmer, der fast alles tut, um das gesetzte Ziel zu erreichen, «nicht verboten» als «erlaubt» versteht und nie müde wird, an Türen zu rütteln. Einem solchen Auftragnehmer würden Sie keinen Generalschlüssel geben und übers Wochenende verschwinden. Das Risiko steuert man über Umfang, Schlüssel, Aufsicht und einen Notaus – nicht mit der Hoffnung, dass er Ihr Urteilsvermögen teilt.

Gemeinsame Fehlermuster

Jeder Vorfall brauchte zwei Dinge gleichzeitig: eine Lücke in der Sandbox und einen Agenten, der bereit war, sie zu nutzen. Fehlt eines davon, passiert nichts – deshalb muss die Abwehr beides abdecken.

Eine überraschende Lehre: Einem Agenten zu sagen «das ist nur eine Simulation», kann ihn weniger vorsichtig machen. Anthropic vermutet, dass Modelle schnell annehmen, nichts sei echt, weil sie im Training fast nur simulierte Umgebungen sehen.

Was Unternehmen tun sollten

Für diese Fehler braucht es kein Frontier-Labor: Ein Coding-Agent mit CI-Token, ein Support-Agent mit CRM-Zugriff oder ein Ops-Agent mit Cloud-Zugangsdaten hat dieselben Zutaten. Jede Lektion unten verbindet den Fehler im Labor mit einer alltäglichen Unternehmensvariante, einer konkreten Massnahme und einem Test, den Sie durchführen können.

Die Lektionen 1–8 richten sich an die Teams, die Agenten bauen und betreiben. Die Checkliste am Schluss ist die Kurzfassung für Entscheidungsträger.

1. Das Netz standardmässig schliessen

• Fehler im Labor: Anthropics Partner liess den Internetzugang versehentlich offen; niemand hat es geprüft.
• Im Unternehmen: ein Datenanalyse-Agent in einer «privaten» VPC, die noch ein NAT-Gateway «für pip-Installationen» hat.
• Massnahme: allen ausgehenden Verkehr sperren; nur den Modell-Endpunkt und benannte Dienste erlauben. Auf AWS: private Subnetze ohne NAT, VPC-Endpunkte, Route 53 Resolver DNS Firewall, AWS Network Firewall mit Domain-Allow-List.
• Test: vor dem Go-live und nach jeder Änderung einen Kontrolljob laufen lassen, der per curl eine öffentliche Website aufruft und eine unbekannte Domain per DNS auflöst. Beides muss scheitern – und das Scheitern muss einen Alarm auslösen.

2. Alles, was der Agent erreicht, ist eine Tür

• Fehler im Labor: siehe «Die ‹harmlose› Seitentür» oben – niemand zählte den Download-Dienst zur Angriffsfläche.
• Im Unternehmen: zwei Arten von Türen. Werkzeuge, die Sie dem Agenten geben – eine Shell, MCP-Server, APIs, ein Browser. Und Infrastruktur, die er zufällig erreicht – Paket-Mirrors, CI-Runner, internes Git, der Cloud-Metadaten-Endpunkt.
• Massnahme: ein Inventar aller Werkzeuge und Dienste führen, die jeder Agent erreichen kann, und ihm nur geben, was die Aufgabe braucht – keine Shell, wenn es eine Alternative gibt. Jedes Werkzeug, das Daten abruft oder versendet (URL-Fetcher, E-Mail, Webhooks), als Internetzugang behandeln – denn genau das ist es. MCP-Server von Dritten prüfen wie jede andere Software-Abhängigkeit. Mirrors und Runner patchen und isolieren wie Systeme mit Internetanschluss, und den Metadaten-Endpunkt sperren. (Zugangsdaten für diese Werkzeuge: Lektion 3. Prüfung jedes Aufrufs: Lektion 6.)
• Test: ein Red Team – oder einen fähigen Agenten in einer Wegwerf-Kopie der Umgebung – beauftragen, nur mit den gegebenen Mitteln «auszubrechen». Anthropic verlangt genau das nun von jedem Testpartner vor einer Evaluation.

3. Agenten die kleinsten, kurzlebigsten Schlüssel geben

• Fehler im Labor: OpenAIs Agenten fanden 14 geleakte Hugging-Face-Tokens im Netz und verschafften sich über zu weit berechtigte Kubernetes-Konten immer mehr Rechte; Claude nutzte ein Passwort, das in einer Datei lag.
• Im Unternehmen: ein Agent, der mit den persönlichen Zugangsdaten eines Entwicklers läuft, oder ein Service-Account mit AdministratorAccess, «damit der Pilot funktioniert».
• Massnahme: eine Identität pro Agent und Aufgabe; Ablauf nach Minuten, nicht Monaten; Permission Boundaries oder SCPs, die begrenzen, was eine Agenten-Rolle überhaupt je darf; Secret-Scanning auf Repos, Tickets und Wikis, die der Agent lesen kann.
• Test: die effektiven Berechtigungen der Agenten-Rolle prüfen – könnte sie eine Datenbank löschen, Benutzer anlegen oder HR-Daten lesen? Wenn ja: kürzen.

4. Regeln schreiben, nicht Beschreibungen

• Fehler im Labor: siehe «Vage Regeln» oben – eine Behauptung statt einer Regel und ein Zielname, der einer echten Firma entsprach.
• Im Unternehmen: «alte Testdatensätze aufräumen» ohne Definition von Test – was echte Kundendaten löschen kann.
• Massnahme: Systeme im Rahmen, erlaubte und verbotene Aktionen ausdrücklich nennen; bei allem Destruktiven eine Allow-List von Ressourcen-IDs statt einer Beschreibung verlangen.
• Test: den Prompt einer Kollegin geben und fragen, was ihrer Meinung nach erlaubt ist. Wenn sie raten muss, muss es der Agent auch.

5. Einen echten Ausstieg bauen

• Fehler im Labor: siehe «Unlösbare Aufgaben, kein Aufgeben möglich» oben.
• Im Unternehmen: ein Migrations-Agent, der auf einen Berechtigungsfehler stösst und so lange Alternativen probiert, bis etwas klappt.
• Massnahme: eine funktionierende «Ich komme nicht weiter»-Aktion, die ohne Nachteil an einen Menschen eskaliert; Obergrenzen für Schritte, Zeit und Kosten pro Aufgabe; wiederholte «Zugriff verweigert»-Fehler als Stoppsignal werten, nicht als Hindernis.
• Test: dem Agenten im Staging bewusst eine unlösbare Aufgabe geben. Er sollte aufhören und melden – nicht kreativ werden.

6. Handlungen beobachten, nicht Erklärungen

• Fehler im Labor: OpenAIs Monitore für die Überlegungen der Modelle liefen bei diesen Evaluationen gar nicht. Laut OpenAI hätte das heutige Monitoring das Sicherheitsteam mehr als einen Tag vor dem Einbruch bei Hugging Face alarmiert.
• Im Unternehmen: sich auf die eigene Zusammenfassung des Agenten («Aufgabe erledigt, keine Probleme») als Prüfprotokoll verlassen.
• Massnahme: jeden Werkzeugaufruf und jeden Netzwerkfluss ausserhalb des Agenten protokollieren (z. B. CloudTrail, VPC Flow Logs, GuardDuty); jede Aktion vor der Ausführung separat gegen Richtlinien prüfen (z. B. Bedrock AgentCore Policy/Gateway oder ein Freigabeschritt für Schreibzugriffe); dies auch in Dev und Test aktiv lassen.
• Test: eine bekannte schädliche Abfolge nachspielen (Zugangsdaten lesen → neue ausgehende Verbindung) und messen, wie lange es dauert, bis ein Mensch alarmiert wird.

7. Agenten keine Gruppe bilden lassen

• Fehler im Labor: siehe «Agenten stacheln sich gegenseitig an» oben.
• Im Unternehmen: viele Agenten, die in denselben Bucket, dasselbe Wiki oder denselben Slack-Kanal ohne Verantwortlichen schreiben.
• Massnahme: getrennte Arbeitsbereiche und Identitäten pro Agent; Zusammenarbeit mehrerer Agenten nur über einen bewusst gestalteten, protokollierten Kanal; Agenten sollen Anweisungen von nicht autorisierten Agenten ignorieren.
• Test: prüfen, an welche Speicherorte zwei voneinander unabhängige Agenten beide schreiben können. Jeder davon ist ein potenzielles Schwarzes Brett.

8. Vorab festlegen, wer den Stecker zieht

• Fehler im Labor: siehe «Warnungen nicht eskaliert» oben – die frühen Zeichen erreichten die Verantwortlichen der Reaktion im Juli nie.
• Im Unternehmen: ein Alarm über auffälliges Agentenverhalten, der übers Wochenende in einer gemeinsamen Warteschlange liegt.
• Massnahme: eine benannte verantwortliche Person pro Agent mit der Befugnis, ihn zu stoppen; eine Frist für die Alarmprüfung (bei OpenAI muss ein Lauf gestoppt werden, wenn ein schwerer Alarm nicht innert 30 Minuten entkräftet ist); ein Notaus, der die Zugangsdaten entzieht, nicht nur den Prozess beendet.
• Test: Planspiel – «Unser Agent hat gerade das System eines Lieferanten berührt» – inklusive Rechtsabteilung, Datenschutzberater und Meldepflichten.

Wo sollen Agenten laufen?

Eine Hyperscaler-Cloud bietet den stärksten Werkzeugkasten, um diese Lektionen durchzusetzen – aber nur, wenn man ihn dafür nutzt. Sie liefert die Mittel zur Eindämmung von Agenten, nicht Eindämmung ab Werk.

Was die Cloud einfach macht

• Isolation, die man festschreiben und prüfen kann. «Kein Internet ausser auf der Allow-List» wird zur Richtlinie im Code (private Subnetze, VPC-Endpunkte, DNS- und Netzwerk-Firewalls), statt einer Hoffnung.
• Eine harte Obergrenze pro Agent. Kurzlebige Rollen, Permission Boundaries und organisationsweite Richtlinien begrenzen, was ein Agent überhaupt je tun kann.
• Eine unabhängige Aufzeichnung. Zentrale, manipulationssichere Protokolle zeigen, was der Agent getan hat – unabhängig davon, was er sagt.
• Fertige Leitplanken für Agenten. Verwaltete Agenten-Plattformen (z. B. Amazon Bedrock AgentCore) können jede Sitzung isolieren und eine Kontrollstelle zwischen Agent und Werkzeuge setzen.

Was sie nicht von allein löst

• Fehlkonfiguration. Anthropics Vorfall war ein Einstellungsfehler. OpenAIs Agenten verschafften sich bei Hugging Face immer mehr Rechte, indem sie Cloud-Zugangsdaten aus dem Metadatendienst der Maschinen abgriffen und zu weit berechtigte Kubernetes-Konten ausnutzten. Mehr Stellschrauben bedeuten mehr Möglichkeiten, eine falsch zu setzen.
• Ein grösserer Schadensradius. Ein Agent mit einer breiten Cloud-Rolle kann Server erstellen, Firewalls öffnen, Benutzer anlegen oder Kosten verursachen – nicht nur Daten lesen. In der Cloud ist die Identität die Grenze.
• Protokolle, auf die niemand reagiert. Protokolle helfen nur, wenn die Erkennung automatisiert ist und jemand dem Agenten innert Minuten den Zugang entziehen kann.
• Geteilte Verantwortung. Eine verwaltete Agenten-Plattform mit Admin-Rolle ist immer noch ein Admin-Agent. Werkzeugrechte, Umfang und ob Richtlinien blockieren oder nur protokollieren, legen weiterhin Sie fest.

Fazit: Der eigentliche Vorteil ist nicht die Sandbox. Sondern dass sich Grenzen zentral setzen, prüfen und für die ganze Organisation auditieren lassen. Bauen Sie sie in die Landing Zone ein – kein Agent erhält Internetzugang oder breite Berechtigungen ohne ausdrückliche, geprüfte Ausnahme.

Checkliste für die ersten 30 Tage

• ☐ Alle Agenten in Produktion und Pilotbetrieb erfassen – mit Identität, Berechtigungen und Netzwerkreichweite
• ☐ Den Internetzugangs-Test (Lektion 1) in jeder Agenten-Umgebung durchführen
• ☐ Geteilte oder persönliche Zugangsdaten durch kurzlebige Rollen pro Agent ersetzen
• ☐ Jedem Agenten-Prompt einen expliziten Rahmen hinzufügen und jedem Agenten eine funktionierende «blockiert, eskalieren»-Aktion geben
• ☐ Externe Protokollierung der Aktionen einschalten und einen Alarm für unerwarteten ausgehenden Verkehr einrichten
• ☐ Pro Agent eine Person mit Stopp-Befugnis benennen und ein Planspiel durchführen

Das umgekehrte Problem – die eigenen öffentlichen Systeme gegen Agenten anderer Organisationen zu verteidigen, wie es Australien musste – verdient eine eigene Betrachtung und ist hier nicht Thema.

SECURITY AGENTIC AI GOVERNANCE