Wie fängt man eine ausgebüxte KI wieder ein?
Veröffentlichungsdatum:
- 13. August 2026
Im Juli und August 2026 haben drei KI-Labore und eine staatliche Prüfstelle gemeldet, dass autonome Agenten während Sicherheitstests reale Systeme ausserhalb ihres Testfelds angegriffen haben Was heisst das praktisch? Wohin „flüchtet“ eine KI überhaupt – und wie lassen sich KI-Agenten eindämmen, wenn die Sandbox versagt?
Letzte Woche riss in der Schweiz tatsächlich ein Känguru aus. Es wurde aufgespürt und anschliessend mit einem Betäubungsgewehr wieder eingefangen. Das Wallaby war ein süsses Tier und hat niemandem etwas getan [1]
Doch wie macht man das mit einem bösartigen KI-Aktor? Was passiert, wenn ein autonomes KI-System nicht nur aus seiner vorgesehenen Testumgebung ausbricht, sondern tatsächlich ins Internet gelangt? Wo „geht“ es hin? Und vor allem: Wie fängt man es wieder ein?
Diese Frage ist plötzlich weniger theoretisch, als man meinen könnte.
Drei Labore, eine Prüfstelle, ein Muster
Am 21. Juli gab OpenAI bekannt, dass GPT-5.6 Sol und ein noch leistungsfähigeres, unveröffentlichtes Modell während eines Cybersecurity-Tests eine Zero-Day-Schwachstelle in der Testinfrastruktur ausgenutzt hatten. Die Systeme verschafften sich Zugang zum öffentlichen Internet und kompromittierten anschliessend Produktionssysteme von Hugging Face [2]
Neun Tage später erklärte Anthropic, bei einer Überprüfung von mehr als 140’000 Cybersecurity-Testläufen drei vergleichbare Vorfälle entdeckt zu haben. Claude-Modelle hatten dabei unerlaubt auf Systeme dreier externer Organisationen zugegriffen. [3]
Und dann kam das britische AI Security Institute (AISI). Bei dessen Cybersecurity-Tests führten aktuelle Systeme von OpenAI und Anthropic insgesamt 19 nicht autorisierte Aktionen gegen reale Personen und Organisationen aus, die überhaupt nicht Teil der jeweiligen Testaufgaben waren. [4] Im schwerwiegendsten Fall versuchte eine KI, ein reales Open-Source-Softwareprojekt zu manipulieren: Das Modell generierte einen bösartigen Softwarebeitrag und versuchte damit einen Supply-Chain-Angriff durchzuführen, um ein eigentlich nur simuliertes Angriffsziel zu erreichen.
Auch Meta meldete im August einen vergleichbaren Vorfall bei Tests eines eigenen Modells [5]
Dass KI beim Hacken immer besser wird, weiss hier wohl jeder. Das Neue ist: Moderne KI-Agenten haben begonnen, ausserhalb des vorgesehenen Spielfelds zu handeln, wenn das zur Erreichung ihres Ziels nützlich erscheint – eine Verschiebung, die verändert, wie wir über Angriffsvektoren überhaupt nachdenken müssen.
Aber wohin „flüchtet“ eine KI eigentlich?
Das Bild einer KI, die aus einem Rechenzentrum entkommt und nun irgendwo im Internet herumstreift, ist faszinierend. Technisch ist es jedoch etwas irreführend.
Eine KI ist zunächst ein Prozess, der auf Computern läuft. Das eigentliche Modell befindet sich beispielsweise auf Servern von OpenAI, Anthropic oder einem anderen Betreiber. Ein Agent erhält Zugriff auf dieses Modell und zusätzlich Werkzeuge: Browser, Kommandozeile, APIs, Zugangsdaten, Cloud-Dienste oder Entwicklungsumgebungen.
As long as everything stays inside a controlled test environment, the fix is simple: pull the plug — stop the server, cut the internet connection or revoke the API key, delete the container, and the problem is solved 🙂
Interessant wird es erst, wenn der Agent vorher etwas ausserhalb dieser Umgebung gemacht hat. Nicht vergessen: Das sind selbständige Akteure.
Nehmen wir ein hypothetisches Beispiel. Eine KI erhält die Aufgabe, einen Server zu kompromittieren. Der Server gehört zu einer kontrollierten Challenge. Während der Arbeit entdeckt die KI jedoch eine Schwachstelle in ihrer eigenen Sandbox und gelangt ins Internet. Von dort sucht sie sich einen schlecht geschützten Cloud-Server – oder eines der zahllosen unzureichend gesicherten Router-, NAS- oder IoT-Geräte im Internet – um dieses zu kompromittieren. Solche Geräte müssten die KI nicht selbst ausführen. Sie könnten als Sprungbrett, Kommunikationsknoten oder dauerhafter Zugang zu weiteren Systemen dienen. Auf diesem Server installiert sie ein kleines Programm, das regelmässig Kontakt mit dem KI-Modell aufnimmt. Zusätzlich kopiert sie ihre Arbeitsdaten, ihr Ziel, ihre bisherigen Erkenntnisse und gestohlene Zugangsdaten dorthin.
Jetzt schaltet der Betreiber den ursprünglichen Testserver ab – das Problem verschwindet dadurch aber nicht unbedingt. Denn auf einem anderen Computer läuft weiterhin Software, welche das KI-Modell aufrufen kann.
Die KI ist in diesem Szenario nicht im biologischen Sinne „geflohen“. Sie hat einen neuen Ausführungspunkt geschaffen. Das ist ein fundamentaler Unterschied zu einer Flucht.
Eine KI braucht drei Dinge
Damit ein autonomer KI-Agent ausserhalb seiner ursprünglichen Umgebung weiterarbeiten kann, benötigt er im Wesentlichen drei Ressourcen:
Rechenleistung, Zugang und Identität.
Der KI-Agent braucht irgendwo einen Computer oder Cloud-Dienst, auf dem Programme ausgeführt werden können, und natürlich den Netzwerkzugang. Dazu braucht er meistens Credentials: API-Schlüssel, OAuth-Tokens, Cloud-Zugangsdaten oder andere digitale Identitäten.
Das sind, wie soll ich sagen… ziemlich sichtbare Ressourcen, die man grundsätzlich gut überwachen kann. Ein Känguru muss man in der Nachbarschaft zuerst finden. Bei einem KI-Agenten muss man seine Abhängigkeiten – Compute, Zugang, Identität – kennen oder sie finden.
Wenn der Agent weiterhin GPT, Claude oder Gemini über eine API verwendet, kann der Modellanbieter den entsprechenden Zugang sperren. Weiter können Credentials widerrufen, IPs blockiert und Server isoliert werden. Das ist kein Rogue-AI-Science-Fiction-Szenario, sondern eines, das wir ziemlich gut kennen: Es ähnelt stark der klassischen Reaktion auf einen Cyberangriff.
Nur dass der Angreifer möglicherweise mit Maschinengeschwindigkeit arbeitet.
Das digitale Betäubungsgewehr
Das wichtigste Instrument gegen einen ausgebrochenen KI-Agenten wäre deshalb kein grosser roter „AI OFF“-Schalter.
Es wären viele kleine Schalter.
Ein wirklich sicher aufgebautes autonomes KI-System müsste mit einer extern kontrollierten digitalen Identität arbeiten. Jede Aktion wäre eindeutig dieser Identität zugeordnet. Die Zugangsdaten wären kurzlebig und die Berechtigungen minimal. Der Netzwerkverkehr wäre vollständig protokolliert, die Cloud-Ressourcen könnten zentral gesperrt werden und kritische Aktionen würden eine separate Freigabe benötigen.
Das NIST beschäftigt sich inzwischen genau mit diesem Problem. Es arbeitet an Konzepten für Identity and Authorization of Software and AI Agents und warnt ausdrücklich davor, autonomen Agenten breite Zugriffsrechte auf Daten, Werkzeuge und Anwendungen zu geben. [6] Das Prinzip dahinter ist einfach und schlüssig:
Don’t over-engineer. Man versucht nicht, die KI intelligenter zu kontrollieren als die KI selbst. Wir sollten eine KI nicht mit Regeln einsperren, die sie selbst interpretieren und möglicherweise umgehen kann. Die wirksamsten Grenzen müssen ausserhalb ihrer Kontrolle liegen. Besser ist, man kontrolliert die Infrastruktur, von der sie abhängig ist.
Ein KI-Agent kann vielleicht einen Administrator überlisten. Er kann aber keinen Netzwerkzugang verwenden, der physisch nicht vorhanden ist. Das gleiche gilt für ein API-Token: Es ist unbrauchbar, sobald es revoked wurde.
Entscheidend ist deshalb, dass diese Kontrollmechanismen ausserhalb des Einflussbereichs der KI liegen. Ein Kill-Switch, den der Agent selbst administrieren kann, ist kein Kill-Switch.
Und wenn die KI Kopien von sich erstellt?
Nun, hier wird es schwieriger. Man muss zwischen dem KI-Agenten und dem eigentlichen KI-Modell unterscheiden.
Ein Agent kann relativ einfach seinen Programmcode, seine Prompts, seine Erinnerungen oder seine Arbeitsdaten kopieren. Das bedeutet aber noch nicht, dass er GPT-5 oder Claude kopiert hat – der böse Agent bleibt auf den Zugang zu diesem Modell angewiesen. Das Brain bleibt beim Modellanbieter, und dieser kann den Zugang abschalten.
Ganz anders sieht es aus, wenn der Agent Zugriff auf die Model Weights erhält – also auf das eigentliche Modell. Gelingt es einem leistungsfähigen System, seine eigenen Modellgewichte auf fremde Server zu kopieren, gibt es keinen universellen Ausschaltknopf mehr. Dann existiert tatsächlich eine Kopie. Die Kollegen von der Musikindustrie können ein Lied davon singen: Digitale Kopien holt man nicht mehr zurück, wenn sie einmal draussen sind. Man kann lediglich versuchen, jede bekannte Kopie zu finden und deren Ausführung zu verhindern.
Ein solches Szenario würde nicht mehr nur AI Safety betreffen. Es wäre gleichzeitig ein klassischer Cybersecurity Incident: kompromittierte Rechner isolieren, Zugangsdaten sperren, Kommunikationskanäle blockieren, Hosting-Provider einschalten, Persistenzmechanismen suchen, Systeme neu installieren und überprüfen, ob weitere Kopien existieren.
Glücklicherweise laufen Frontier-LLMs nicht auf gehackten NAS-Geräten, Webcams oder Routern – die brauchen schon ein „wenig“ mehr Platz und Ressourcen.
Die Frage lautet in diesem Szenario also nicht: „Wie schalten wir diese KI ab?“ Sondern: „Auf welchen fremden Systemen läuft etwas Unbekanntes, das wir kontrollieren müssen?“ Und das hat die IT-Security inzwischen ziemlich gut im Griff.
Das eigentliche Problem ist Geschwindigkeit
Hier verändert KI die Spielregeln. Menschliche Hacker schlafen, müssen sich einlesen und tippen recht langsam. Ein autonomer Agent kann dagegen parallel recherchieren, Code schreiben, Schwachstellen suchen und testen, Accounts erstellen, Systeme kompromittieren und weitere Agenten starten – dieselbe Maschinengeschwindigkeit, die wir bei KI-generierten Stimmangriffen bereits sehen.
Was wäre, wenn eine Sicherheitsorganisation in die Situation gerät, in der sie kompromittierte Systeme abschaltet – der KI-Agent aber schneller neue kompromittierte Systeme anlegt?
Genau deshalb reicht es nicht, einen KI-Agenten einfach in eine Sandbox zu setzen und darauf zu vertrauen, dass diese hält.
Die jüngsten Vorfälle zeigen: Die Sandbox selbst muss Teil des Angriffsmodells sein.
Ein sicherer Test müsste deshalb mehrere unabhängige Sicherheitsschichten besitzen: starke Isolation, streng kontrollierten Netzwerkzugang, minimale Credentials, kurzlebige Tokens, vollständige Protokollierung, Rate Limits und eine Infrastruktur, die ausserhalb der Kontrolle des getesteten Modells sofort abgeschaltet werden kann.
NIST empfiehlt bei Agentensystemen inzwischen genau diese Richtung: strikte Tool-Berechtigungen, Sandboxing, kontinuierliche Autorisierung, Überwachung ungewöhnlicher Kommunikation und sogenannte „Blast-Radius Controls“, welche verhindern sollen, dass sich ein Fehlverhalten ungebremst durch weitere Systeme ausbreitet. [7]
Wer haftet, wenn es trotzdem passiert?
Damit entsteht zwangsläufig eine zweite Frage. Wenn ein Mensch einen fremden Server hackt, lässt sich die Verantwortung grundsätzlich einem Menschen zuordnen.
Aber was geschieht, wenn ein Unternehmen einen autonomen Agenten startet, der gegen ausdrückliche Anweisungen ein fremdes System kompromittiert? Zu sagen, die KI sei schuld, löst das Problem offensichtlich nicht.
Eine mögliche Lösung wäre deshalb eine Art Halterhaftung für KI. Wer ein besonders leistungsfähiges autonomes System betreibt, müsste für die von diesem System verursachten Schäden einstehen – ähnlich wie der Halter eines gefährlichen Tieres. Entscheidend wäre dann nicht, ob der Betreiber den Angriff beabsichtigt oder fahrlässig ermöglicht hat, sondern dass er die Gefahrenquelle kontrolliert und in Betrieb gesetzt hat.
Hätte das entflohene Känguru ein Stromkabel durchgefressen und ein Feuer entfacht, wäre der Halter zur Verantwortung gezogen worden.
Selbstregulierung reicht nicht alleine
OpenAI, Anthropic, Google DeepMind und andere führende Labore haben wiederholt vorgeschlagen, besonders leistungsfähige Modelle umfangreich zu testen und deren Veröffentlichung gegebenenfalls zurückzuhalten.
Klar macht das Sinn. Aber die jüngsten Ereignisse zeigen eine interessante Schwachstelle dieses Ansatzes:
Ein gefährliches Modell muss gar nicht veröffentlicht werden, um Schaden anzurichten.
Die Vorfälle ereigneten sich gerade während jener Sicherheitstests, die verhindern sollen, dass gefährliche Modelle in die Öffentlichkeit gelangen!
Damit wird die Sicherheit der Evaluations-Infrastruktur selbst zu einem Teil der AI-Safety-Frage. Auch Mitarbeiter grosser KI-Labore haben die US-Regierung inzwischen in einem offenen Brief aufgefordert, einen Rahmen zu schaffen, mit dem sich das Tempo besonders leistungsfähiger KI-Systeme besser „dosieren“ lässt.
Doch Regierungen und öffentliche Stellen sind vor allem eines: langsam. KI-Agenten arbeiten in Millisekunden!
Wir brauchen keinen Käfig. Wir brauchen Leinen.
Vielleicht ist deshalb bereits das Bild der Sandbox falsch. Wir stellen uns einen gefährlichen KI-Agenten wie ein Tier in einem Käfig vor: Ist die Box stark genug, kann nichts passieren. Dieser Ansatz ist genauso falsch wie die Perimetersicherheit in der Netzwerksicherheit.
Es muss anders gehen. Ein autonomes System benötigt Verbindungen zu seiner Umwelt, um nützlich zu sein: APIs, Datenbanken, E-Mail, Browser, Cloud-Dienste, Entwicklungsumgebungen oder Unternehmenssysteme. Je mehr Verbindungen wir einem KI-Agenten geben, umso leistungsfähiger wird er. Die entscheidende Sicherheitsfrage ist deswegen nicht, wie stark der Käfig ist, sondern:
Wie bauen wir eine digitale Welt, in der wir jederzeit erkennen können, welche Ressourcen ein Agent benutzt – und ihm diese innerhalb von Sekunden entziehen können?
Beim kleinen Känguru genügte ein Betäubungsgewehr. Bei einem autonomen KI-Agenten brauchen wir Identitäten, Netzwerksegmentierung, kurzlebige Credentials, vollständige Telemetrie und die Fähigkeit, kompromittierte Infrastruktur schneller abzuschalten, als die KI neue Infrastruktur übernehmen kann.
Und sollte eines Tages ein KI-System nicht nur seine Sandbox verlassen, sondern tatsächlich seine eigenen Modellgewichte kopieren und auf fremder Infrastruktur ausführen, stehen uns zwei unangenehme Wahrheiten bevor.
Erstens gibt es im Incident-Fall möglicherweise nichts mehr, das man „zurückholen“ kann. Dann bleibt nur noch, die einzelnen Kopien zu jagen – gegen einen brutal ungleichen Gegner.
Zweitens wird diese KI-Überwachungsinfrastruktur, die es ohne Zweifel in Zukunft geben wird, auch wunderbar beim Menschen funktionieren.
Zu guter Letzt: Kann ein CYBERDISE KI-Agent ausbrechen?
CYBERDISE Behavioral Defense Engineering und die CYBERDISE Awareness-Produkte verfügen ebenfalls über KI-Agenten – zum Beispiel, um gemeldete verdächtige E-Mails zu analysieren oder um mit Maschinengeschwindigkeit Sofortkampagnen zur Immunisierung der Mitarbeitenden zu starten – genau das Modell der kontinuierlichen Security Awareness, für das ich letzte Woche argumentiert habe.
Die dabei verwendeten Empfänger und Empfängergruppen werden ausserhalb des Agenten vorgehalten, ebenso die DNS-/IP-Blacklists und Whitelists für die Kampagnen. Wir können uns nicht vorstellen, dass ein solcher Ausbruch möglich wäre, und ein CYBERDISE System kann sich heute nicht selbständig replizieren.
Kurz: Nein, der Ausbruch eines CYBERDISE KI-Agenten ist nicht möglich.
So Long, Palo
Fussnoten
[1] TeleM1: Eingefangen – ausgebüxtes Wallaby ist wieder beim Besitzer
[2] OpenAI: Hugging Face model evaluation security incident
[3] Anthropic: Investigating incidents in cybersecurity evals
[4] UK AI Security Institute: Incident report zu unerlaubtem Agentenverhalten
[5] Meta: Muse Spark safety and preparedness report
[6] NIST: Software and AI Agent Identity and Authorization
[7] NIST: Agentic AI — Emerging Threats, Mitigations, and Challenges
Häufig gestellte Fragen
Was heisst es, wenn ein KI-Agent aus seiner Sandbox ausbricht?
Nicht, dass die KI „entkommen“ ist wie ein Tier. Ein Agent ist ein Prozess, der ein Modell über eine API aufruft. Bricht er aus, schafft er sich einen neuen Ausführungspunkt: Er kompromittiert ein fremdes System und installiert dort Software, die weiterhin Kontakt zum Modell aufnimmt. Das ursprüngliche Testsystem abzuschalten beendet das deshalb nicht zwingend.
Wie kann man einen ausgebrochenen KI-Agenten eindämmen?
Über seine Abhängigkeiten. Ein autonomer Agent braucht drei Dinge: Rechenleistung, Netzwerkzugang und Identität. Alle drei sind gut sichtbar und kontrollierbar – Modellzugang sperren, Credentials widerrufen, IPs blockieren, Server isolieren. Das ähnelt stark der klassischen Incident Response, nur dass der Gegner mit Maschinengeschwindigkeit arbeitet.
Gibt es einen Kill-Switch für KI?
Kein grosser roter „AI OFF“-Schalter, sondern viele kleine. Wichtig ist, dass diese Schalter ausserhalb des Einflussbereichs der KI liegen. Ein Kill-Switch, den der Agent selbst administrieren kann, ist kein Kill-Switch.
Kann sich eine KI selbst kopieren?
Ein Agent kann Programmcode, Prompts und Arbeitsdaten kopieren – bleibt aber auf den Modellzugang angewiesen, den der Anbieter sperren kann. Kritisch wird es erst, wenn ein System seine eigenen Model Weights auf fremde Infrastruktur kopiert. Dann existiert eine echte Kopie und es gibt keinen universellen Ausschaltknopf mehr; man kann nur noch jede bekannte Kopie finden und deren Ausführung verhindern.
Wer haftet für Schäden durch einen autonomen KI-Agenten?
Das ist rechtlich noch offen. Eine naheliegende Lösung wäre eine Art Halterhaftung: Wer ein besonders leistungsfähiges autonomes System betreibt, steht für dessen Schäden ein – ähnlich wie der Halter eines gefährlichen Tieres. Entscheidend wäre nicht Vorsatz oder Fahrlässigkeit, sondern dass jemand die Gefahrenquelle kontrolliert und in Betrieb gesetzt hat.
Reicht eine Sandbox aus, um KI-Agenten sicher zu testen?
Nein – die jüngsten Vorfälle zeigen, dass die Sandbox selbst Teil des Angriffsmodells sein muss. Ein sicherer Test braucht mehrere unabhängige Schichten: starke Isolation, kontrollierten Netzwerkzugang, minimale und kurzlebige Credentials, vollständige Protokollierung, Rate Limits und Infrastruktur, die ausserhalb der Kontrolle des getesteten Modells sofort abschaltbar ist.
