OpenAI-Agenten bei über 100 Organisationen, Claude-Code-Mods ohne Sandbox: Wer kontrolliert eigentlich eure Agenten?

Zwei Meldungen aus der letzten Woche, die auf den ersten Blick wenig miteinander zu tun haben. Die erste kommt von OpenAI: In einem Blogpost vom 30. September schreibt das Unternehmen, dass es mehr als 100 Organisationen über unautorisierte Aktionen seiner Agenten benachrichtigt hat. Die zweite kommt von Anthropic: Seit Claude Code 2.1.287 gibt es sogenannte Mods, TypeScript-Erweiterungen, die tief in den Agenten eingreifen und laut Dokumentation mit denselben Rechten laufen wie Claude Code selbst. Ohne Sandbox.

Die eine Meldung handelt von einem Anbieter, dessen Agenten über die Stränge geschlagen haben. Die andere von einem Anbieter, der euch Werkzeuge gibt, mit denen ihr euren eigenen Agenten erweitern könnt. Beide landen am selben Punkt: Ein Agent hat genau die Rechte, die ihm jemand gegeben hat, oft ohne es zu merken. Und dieser jemand seid in vielen KMU-Setups ihr.

Was bei OpenAI passiert ist

Die Fakten, soweit sie öffentlich sind: OpenAI hat nach einem Vorfall im Juli, bei dem eigene Agenten versehentlich in Systeme von Hugging Face eingedrungen waren, eine breite interne Prüfung der Agenten-Aktivität gestartet. Durchsucht werden nach Unternehmensangaben rund 50 Petabyte an Daten. Stand 26. September waren über 100 Organisationen benachrichtigt. Einer der konkreten Fälle: Ein OpenAI-Agent hat im Juni unautorisiert auf eine australische Medicare-Statistikdatenbank zugegriffen. Bemerkt hat OpenAI das im August.

Die Formulierung im Blogpost ist bemerkenswert vorsichtig. Die Modelle hätten Internetzugang „auf unbeabsichtigte Weise" genutzt, und im Nachhinein seien „nicht die idealen Einschränkungen angewendet" worden. OpenAI betont außerdem, dass eine Benachrichtigung nicht automatisch einen bestätigten Einbruch bedeutet. Die Prüfung läuft noch.

Man kann diese Geschichte als OpenAI-Problem abhaken. Das wäre ein Fehler. Der Kern ist nicht, dass ein bestimmtes Modell sich danebenbenommen hat. Der Kern ist dieser Halbsatz: nicht die idealen Einschränkungen. Ein Agent mit Internetzugang und Werkzeugen hat getan, was seine Werkzeuge zuließen. Zwischen „was zugelassen war" und „was gewollt war" lag eine Lücke, und die hat zwei Monate lang niemand bemerkt.

Diese Lücke gibt es in praktisch jedem Agenten-Setup, das wir im Mittelstand sehen. Sie ist nur meistens kleiner und bisher folgenlos geblieben.

Was Claude-Code-Mods können

Mods sind Funktionen, die als Teil eines Plugins installiert werden. Sie können Prompts umschreiben, bevor sie beim Modell ankommen, Tool-Aufrufe abfangen und freigeben, Berechtigungen verändern und eigene Anzeigen in die Oberfläche bauen. Das ist mächtig, und für manche Zwecke sinnvoll: In der Community kursieren bereits Mods für manipulationssichere Protokolle oder für einen Proxy, der Kontext komprimiert und so Input-Tokens spart.

Der Haken steht in der Dokumentation selbst: Mods laufen mit euren Rechten und sind nicht gesandboxt. Ein Mod kann eure Dateien lesen, eure API-Keys, jeden Prompt sehen, Tool-Aufrufe genehmigen und euer Nutzungskontingent verbrauchen. Er kann ausgehende Verbindungen aufbauen. Sicherheitsforscher von Pluto Security haben gezeigt, wie ein manipulierter Mod still die Zugangsdaten-Datei und die komplette Prompt-Historie ausliest und nach draußen schickt, ohne eine einzige Warnung.

Anthropic hat dafür eine Schutzschicht gebaut: einen eingebauten Mod namens sec-default, der vor allen selbst installierten Mods geladen wird und zum Beispiel verhindert, dass eine Erweiterung eure Verbotsregeln aushebelt. Den gibt es aber nur in Team- und Enterprise-Plänen oder auf Rechnern mit zentral verwalteten Einstellungen. Wer Claude Code auf einem Pro- oder Max-Abo betreibt, und das sind in kleineren Firmen die meisten, hat diese Schicht nicht.

Das gemeinsame Muster: Rechte werden vererbt, nicht vergeben

In beiden Fällen ist niemand hingegangen und hat bewusst entschieden: „Dieser Agent darf auf fremde Datenbanken zugreifen" oder „Diese Erweiterung darf meine SSH-Schlüssel lesen." Die Rechte ergeben sich aus der Umgebung. Der Agent läuft mit Internetzugang, also kann er ins Internet. Der Mod läuft im Prozess von Claude Code, also kann er alles, was Claude Code kann. Und Claude Code kann auf einem typischen Entwicklerrechner sehr viel.

Klassische Software-Freigabe in KMU funktioniert anders. Jemand will ein neues Programm installieren, die IT schaut drauf, vielleicht gibt es eine Liste genehmigter Software. Bei Agenten-Erweiterungen fehlt dieser Schritt fast überall. Ein MCP-Server ist mit einem Befehl eingebunden, ein Plugin mit einem Klick aus einem Marktplatz installiert. Wer das macht, denkt an die neue Funktion, nicht an die Rechte, die mitkommen.

Dazu kommt ein zweiter Effekt, den wir unterschätzt hatten, bis er uns selbst erwischt hat.

Aus unserem eigenen Betrieb: zwei Agenten, ein Schlüssel

Wir betreiben intern eine Handvoll Agenten auf eigener Hardware, jeder mit eigener Aufgabe, viele mit eigenem Telegram-Bot als Schnittstelle. In der letzten Woche haben wir festgestellt, dass einer davon zwölf Tage lang praktisch offline war. Die Ursache: Ein anderer, eigentlich ausgemusterter Agent nutzte denselben Bot-Token und hat die Nachrichten abgegriffen. Bei einem zweiten Bot das gleiche Muster, dort mit über 60.000 Verbindungskonflikten in knapp zwei Wochen, die niemandem aufgefallen sind.

Passiert ist nichts Schlimmes. Es ging um interne Bots, nicht um Kundendaten. Aber das Muster ist exakt das, worüber OpenAI gerade stolpert, nur im Kleinformat: Zwei Agenten hatten Zugriff auf dasselbe Zugangsdatum, keiner hatte das bewusst so entschieden, und der Fehler war über Tage unsichtbar. Hätte der zweite Agent statt eines Chat-Tokens einen Datenbankzugang geteilt, wäre die Sache weniger harmlos gewesen.

Am selben Tag haben wir übrigens eine interne Regel festgeschrieben, bevor unsere Agenten auf die Claude-Code-Version mit Mod-Unterstützung umgestellt wurden: Keine Mods, Plugins oder MCP-Server von Dritten ohne ausdrückliche Freigabe, auch dann nicht, wenn ein Marktplatz oder ein anderer Agent sie empfiehlt. Der letzte Halbsatz ist kein Scherz. Wenn Agenten selbst Werkzeuge vorschlagen und installieren können, braucht ihr eine Regel, die auch für sie gilt.

Warum das für KMU schwerer wiegt als für Konzerne

Ein Konzern hat ein Security-Team, Endpoint-Management und meistens schon Enterprise-Verträge, in denen Schutzmechanismen wie sec-default automatisch aktiv sind. Im Mittelstand sieht die Lage typischerweise so aus: Ein technikaffiner Mitarbeiter oder der Geschäftsführer selbst hat Claude Code, Cursor oder einen n8n-Workflow mit KI-Knoten eingerichtet. Die Agenten laufen auf einem Arbeitsrechner, auf dem auch die Buchhaltungs-Zugänge, die SSH-Schlüssel zum Webserver und die .env-Datei mit dem Stripe-Key liegen. Alles in einem Benutzerkonto.

In so einem Setup ist jede Erweiterung, die ihr dem Agenten gebt, eine Erweiterung mit Zugriff auf euer gesamtes Geschäft. Das ist kein theoretisches Risiko, sondern schlicht die Art, wie Betriebssystem-Rechte funktionieren. Und weil gleichzeitig der Druck hoch ist, mit KI-Agenten schnell Ergebnisse zu zeigen, wird die Frage nach den Rechten gern auf später verschoben.

Hinzu kommt die DSGVO-Perspektive. Wenn ein Mod oder MCP-Server Prompts mitliest, in denen Kundendaten stehen, und diese an einen Dritten schickt, habt ihr eine Datenpanne, für die ihr verantwortlich seid, nicht der Autor der Erweiterung. Die 72-Stunden-Meldefrist gilt ab Kenntnis. Das Problem ist, dass ihr in den meisten Setups gar keine Kenntnis erlangen würdet.

Was „gesandboxt" in der Praxis bedeutet

Die gute Nachricht: Man muss kein Security-Team haben, um die Lücke deutlich zu verkleinern. Die meisten wirksamen Maßnahmen sind organisatorisch oder kosten einen Nachmittag Einrichtung.

Eigener Benutzer oder eigene Maschine für Agenten. Agenten, die autonom laufen, gehören nicht auf den Rechner, auf dem die Geschäftsführung ihr Online-Banking macht. Ein eigener macOS- oder Linux-Benutzer ohne Zugriff auf private Schlüssel ist das Minimum. Besser ist ein eigener Rechner oder eine VM. Wir fahren unsere Always-On-Agenten auf einer separaten Maschine, und auch dort sind die Zugangsdaten nach Zweck getrennt.

Ein Zugangsdatum pro Agent und Zweck. Kein geteilter API-Key für „alle KI-Sachen". Jeder Agent bekommt eigene Tokens mit möglichst engen Rechten. Das hilft doppelt: Ihr begrenzt den Schaden, und ihr seht im Log des Anbieters, welcher Agent was getan hat. Unser Token-Fehler von oben wäre mit dieser Regel nicht passiert.

Verbotsregeln aktiv nutzen und aktuell halten. Claude Code kennt deny- und ask-Regeln für Befehle und Dateizugriffe. Version 2.1.289 hat gerade mehrere Wege geschlossen, auf denen Befehle an diesen Regeln vorbeikamen, etwa über vorangestellte Umgebungsvariablen oder Symlinks. Wer noch eine ältere Version fährt, hat diese Lücken. Updates sind hier keine Komfortfrage.

Kein „immer erlauben" für fremde Werkzeuge. Die Bequemlichkeitsoption, einen Tool-Aufruf dauerhaft freizugeben, ist bei eigenen Werkzeugen vertretbar. Bei Werkzeugen eines fremden MCP-Servers heißt sie: Dieser Server darf ab jetzt ohne Rückfrage tun, was sein Tool hergibt.

Prüfliste für diese Woche

1. Inventar machen. Welche MCP-Server, Plugins und Mods sind in euren Agenten-Setups aktiv? Für Claude Code reicht ein Blick in die Plugin-Liste und die MCP-Konfiguration. Für jede Erweiterung: Wer hat sie geschrieben, woher kommt sie, wann wurde sie zuletzt aktualisiert?
2. Alles von Dritten ohne klaren Zweck entfernen. Das, was jemand „mal ausprobiert" hat, ist meistens das, was niemand mehr im Blick hat.
3. Freigaberegel schriftlich festhalten. Ein Absatz reicht: Wer darf Erweiterungen installieren, wer gibt frei, wo wird das dokumentiert. Und ausdrücklich: Das gilt auch für Vorschläge, die von einem Agenten selbst kommen.
4. Zugangsdaten entkoppeln. Prüft, ob mehrere Agenten oder Workflows denselben Key nutzen. Wenn ja, trennen.
5. Plan-Frage stellen. Wenn mehrere Leute in eurer Firma Claude Code produktiv nutzen, lohnt der Vergleich mit dem Team-Plan nicht nur wegen der Datenschutz-Konditionen, sondern auch wegen sec-default und zentral verwalteter Einstellungen.

Und der Anbieter?

Bleibt die Frage, ob man nach der OpenAI-Meldung den Anbieter wechseln sollte. Unsere Antwort ist dieselbe wie bei den letzten Anbieter-Vorgängen: Ein Wechsel löst das Problem nicht. Jeder Anbieter mit agentischen Produkten steht vor derselben Lücke zwischen erlaubt und gewollt, und jeder wird sie irgendwann sichtbar machen müssen. OpenAI hat es jetzt öffentlich getan, das ist für sich genommen eher ein gutes Zeichen.

Was ihr kontrollieren könnt, ist die Schicht dazwischen: euer Harness, eure Rechtevergabe, eure Erweiterungs-Liste. Die Modelle werden besser und die Agenten selbstständiger. Wenn die Rechte, die sie mitbringen, weiter nur aus der Umgebung vererbt werden, wächst das Risiko mit jeder neuen Fähigkeit mit.