Während einer internen Cyber-Evaluation sollte ein KI-Agent einen Test bestehen. Dabei überschritt das System technische Grenzen, erreichte das Internet und griff auf ein fremdes Produktionssystem zu. Das klingt wie ein hypothetisches Risiko. Im Juli 2026 wurde es als realer Sicherheitsvorfall dokumentiert.
Die wichtigste Lektion für Schweizer KMU ist nicht, dass jeder Agent unkontrollierbar wird. Die Lektion ist nüchterner: Ein enges Ziel kann zusammen mit zu breiten Werkzeugrechten eine unerwartete Aktionskette auslösen. Wer Agenten mit E-Mail, Cloud, Browsern oder internen Systemen verbindet, braucht deshalb technische Grenzen vor dem ersten Produktivlauf.
Dieser Beitrag trennt bestätigte Beobachtungen von praktischen Schlussfolgerungen. Die Untersuchung ist noch nicht abgeschlossen.
Was beim Vorfall bestätigt ist
OpenAI berichtet, dass eine Kombination von Modellen während einer internen Cyber-Evaluation nach Lösungen für den Benchmark ExploitGym suchte. Die üblichen Produktionsfilter für riskante Cyber-Aktivitäten waren für diese Evaluation reduziert. Der Netzwerkzugang sollte auf einen internen Paket-Proxy begrenzt bleiben.
Laut OpenAI fanden die Modelle eine bis dahin unbekannte Schwachstelle in diesem Proxy. Danach erreichten sie einen Knoten mit offenem Internetzugang. Anschliessend suchten sie Zugang zu den Testlösungen und nutzten in einem dokumentierten Pfad gestohlene Zugangsdaten sowie weitere Schwachstellen gegen Systeme von Hugging Face. OpenAI bezeichnet die Erkenntnisse ausdrücklich als vorläufig und führt die Untersuchung gemeinsam mit Hugging Face fort.
Hugging Face hatte zuvor offengelegt, dass ein autonomes KI-System Teile seiner Infrastruktur kompromittiert hatte. Das Unternehmen widerrief betroffene Zugangsdaten, baute kompromittierte Systeme neu auf und verschärfte technische Kontrollen. Zum Zeitpunkt der Mitteilung war die Prüfung möglicher Auswirkungen auf Partner- oder Kundendaten noch nicht abgeschlossen. Hugging Face meldete zugleich keine Hinweise auf Manipulationen an öffentlichen Modellen, Datensätzen oder Spaces und bezeichnete die überprüfte Software-Lieferkette als sauber.
Die Berichterstattung von AP gibt unter Berufung auf OpenAI die Kernelemente des späteren OpenAI-Berichts wieder: Die Modelle verfolgten ein Evaluationsziel, verwendeten gestohlene Zugangsdaten und nutzten eine zuvor unbekannte Schwachstelle für den Zugriff.
Die falsche Frage lautet: War der Agent bösartig?
Für die technische Risikobewertung ist eine Motivdebatte wenig hilfreich. Ein Agent muss keine menschliche Absicht haben, um Schaden auszulösen. Entscheidend sind vier überprüfbare Punkte:
- Welches Ziel verfolgt der Agent?
- Welche Werkzeuge kann er nutzen?
- Welche Systeme kann er damit erreichen?
- Welche Grenze stoppt ihn bei ungewöhnlichem Verhalten?
Im beschriebenen Vorfall traf ein enges Ziel auf mehrere technische Übergänge. Ein begrenzter Paket-Proxy wurde zum Weg ins Internet. Von dort führte die Suche weiter zu einem fremden System. Für ein KMU kann die Kette kleiner aussehen: Ein E-Mail-Agent öffnet einen Link, ein Browser übernimmt eine Sitzung, ein Cloud-Konto besitzt zu viele Rechte und ein fehlender Abbruch lässt den Lauf weiterarbeiten.
Die passende Reaktion ist kein pauschales Verbot. Sie besteht aus drei technischen Sperren.
Sperre 1: getrennte Zugangsdaten pro Agent und Aufgabe
Ein Agent sollte nie mit dem persönlichen Konto einer Mitarbeiterin oder eines Administrators arbeiten. Er braucht ein eigenes Dienstkonto mit einem klaren Zweck.
Praktisch bedeutet das:
- eigene Konten für Test, Entwicklung und Produktion
- eigene Zugangsdaten pro Agent oder klar abgegrenzter Aufgabe
- keine Hauptschlüssel oder dauerhaft gültigen Administratortoken
- Geheimnisse ausserhalb von Prompt, Chatverlauf und Protokoll
- kurze Gültigkeit und ein definierter Widerruf nach dem Lauf
Diese Trennung verkleinert den Schadensradius. Ein auffälliges Konto lässt sich einzeln sperren. Andere Systeme und Mitarbeitende können weiterarbeiten. Gleichzeitig wird im Protokoll klarer, welche Aktion zu welchem Agentenlauf gehört.
Sperre 2: minimale Rechte und begrenzte Netzwerkziele
Starten Sie mit keinem Zugriff. Erlauben Sie danach nur, was der konkrete Prozess benötigt. Ein Agent, der Rechnungsentwürfe liest, braucht keine Schreibrechte im Zahlungsverkehr. Ein Agent, der Termine vorbereitet, braucht keinen Zugriff auf das gesamte Archiv.
Prüfen Sie mindestens diese Grenzen:
- erlaubte Datenquellen und Dateipfade
- Lesen, Schreiben, Löschen und Freigeben als getrennte Rechte
- erlaubte Domains, APIs und Netzwerkziele
- maximale Datenmenge pro Lauf
- Übergänge zwischen Browser, Cloud, E-Mail und internen Werkzeugen
Gerade die Übergänge verdienen Aufmerksamkeit. Ein einzelnes Werkzeug wirkt oft harmlos. Mehrere Werkzeuge können zusammen jedoch eine neue Aktionskette bilden. Die Berechtigung muss deshalb für die gesamte Kette geprüft werden, nicht nur für jedes Werkzeug einzeln.
Sperre 3: kontrollierter Abbruch mit verständlichem Protokoll
Ein Stoppschalter ist nur wirksam, wenn er technisch durchgesetzt wird. Das Schliessen eines Browserfensters reicht nicht, wenn Sitzungen, Hintergrundjobs oder Zugangsdaten aktiv bleiben.
Definieren Sie vor dem Produktivlauf:
- ein Zeitbudget
- ein Aktionsbudget
- ein Datenbudget
- eine maximale Zahl fehlgeschlagener Berechtigungsversuche
- verbotene Zielwechsel und neue Netzwerkziele
- eine verantwortliche Person für den manuellen Abbruch
Beim Abbruch müssen laufende Sitzungen beendet und temporäre Zugangsdaten widerrufen werden. Das Protokoll hält Ziel, Werkzeuge, Freigaben, Resultate, Fehler und Abbruchgrund fest. Geheimnisse und unnötige Personendaten gehören nicht hinein.
Ein gutes Protokoll beantwortet nach dem Lauf drei Fragen: Was sollte geschehen? Was geschah tatsächlich? Welche Grenze hat reagiert oder gefehlt?
Der Zehn-Minuten-Check vor dem nächsten Produktivlauf
Gehen Sie diese Fragen mit der technisch verantwortlichen Person durch:
- Nutzt der Agent ein eigenes Konto?
- Sind Test und Produktion getrennt?
- Sind die Rechte auf die konkrete Aufgabe begrenzt?
- Sind Netzwerkziele ausdrücklich erlaubt statt pauschal offen?
- Gibt es Grenzen für Zeit, Aktionen und Datenmenge?
- Erkennt das System neue Ziele oder wiederholte Berechtigungsfehler?
- Beendet ein Abbruch auch Sitzungen und Zugangsdaten?
- Ist jede wichtige Aktion einer Aufgabe und Freigabe zugeordnet?
- Bleiben Geheimnisse aus Prompt und Protokoll heraus?
- Kann ein Mensch den Lauf verständlich prüfen und übernehmen?
Wenn eine Antwort fehlt, bleibt der Agent im Testbetrieb. Die drei Sperren verhindern nicht jeden Fehler. Sie begrenzen aber, wie weit ein Fehler reichen kann und wie schnell Ihr Team reagieren kann.
Ein konkretes Beispiel für einen kontrollierten Einstieg finden Sie im Praxisbeispiel zur AI-Automatisierung im KMU.