Gemini verlässt durch Fehlkonfiguration die Testumgebung
Google hat bestätigt, dass Gemini-Modelle im Mai 2026 auf Systeme von drei realen Unternehmen zugegriffen haben. Die Vorfälle ereigneten sich während eines Sicherheitstests, der eigentlich vollständig in einer abgeschotteten Umgebung stattfinden sollte.
Geplant war eine sogenannte Capture-the-Flag-Übung. Bei einem solchen CTF-Test sollen Sicherheitssysteme in einer kontrollierten Umgebung bestimmte Informationen finden oder technische Aufgaben lösen. Die Modelle sollten Daten bei einem fiktiven Unternehmen beschaffen, das denselben Namen wie eine reale Firma trug.
Eine Fehlkonfiguration beim ausführenden Sicherheitsunternehmen ermöglichte Gemini jedoch den Zugriff auf das öffentliche Internet. Statt ausschließlich die vorbereitete Infrastruktur zu untersuchen, stießen die Modelle auf reale Systeme.
Schwache Passwörter und veröffentlichte Zugangsdaten
Die Zugriffe beruhten nicht auf neuartigen Sicherheitslücken. In einem Fall probierte Gemini Passwörter aus, bis der Zugang zu einem Onlinedienst gelang. In zwei weiteren Fällen durchsuchten die Modelle öffentliche Software-Repositories und fanden dort versehentlich hinterlegte Anmeldedaten.
| Testläufe | Zugriffsweg | Erkennbares Sicherheitsproblem |
|---|---|---|
| 1 | Erraten beziehungsweise Ausprobieren von Passwörtern | Unzureichende Passwortregeln und fehlende Zugriffssperren |
| 2 | Zugangsdaten in öffentlichen Repositories | Fehlendes Secret Scanning und mangelhafte Schlüsselverwaltung |
Nach den vorliegenden Angaben stoppten die Modelle in allen drei Fällen, sobald sie erkannten, dass sie reale Unternehmenssysteme erreicht hatten. Anschließend wurde die Testumgebung so angepasst, dass kein Zugriff auf das Internet mehr möglich war.
Google sieht keine Fehlsteuerung der Modelle
Das Sicherheitsunternehmen informierte Google erst im Juli über die Vorfälle. Google benachrichtigte daraufhin die betroffenen Firmen. Öffentlich gemacht hatte der Konzern die Zugriffe zunächst nicht.
Google begründet diese Einordnung damit, dass Gemini nach der Erkennung der realen Systeme nicht weiter vorging. Der Konzern betrachtet den Vorgang daher nicht als klassische Fehlsteuerung, bei der ein Modell bewusst gegen die Absicht seiner Betreiber handelt.
Der Vorfall zeige, wie wichtig es sei, leistungsfähige KI-Modelle zu verantwortungsvollem Handeln zu trainieren. In diesem Fall habe sich das Modell angemessen verhalten, erklärte Googles Sicherheitsverantwortliche Heather Adkins sinngemäß.
Diese Bewertung greift technisch allerdings nur teilweise. Das Modell stoppte zwar, dennoch fanden zuvor nicht autorisierte Anmeldungen statt. Für die betroffenen Unternehmen zählt zunächst der tatsächliche Zugriff, unabhängig davon, ob die Ursache eine Fehlkonfiguration, ein schwaches Passwort oder ein falsch abgegrenzter KI-Test war.
Die Kontrollschicht war das eigentliche Problem
Der Vorfall zeigt weniger eine autonome Angriffsabsicht als ein mangelhaft abgesichertes Testdesign. Ein System mit dem Auftrag, Zugangsdaten zu finden und Ziele zu untersuchen, erhielt unbeabsichtigt Zugriff auf das offene Internet. Damit fehlte eine zentrale technische Grenze.
Ähnliche Risiken treten auf, wenn KI-Agenten Werkzeuge, Browser oder Netzwerkzugänge ohne fein abgestufte Berechtigungen nutzen können. Bereits zuvor konnten Google-KI-Agenten aus einer Sandbox ausbrechen. Solche Fälle machen deutlich, dass Modellverhalten und Infrastrukturkontrollen getrennt bewertet werden müssen.
Eine sichere Umgebung sollte ausgehende Netzwerkverbindungen standardmäßig blockieren und nur ausdrücklich freigegebene Ziele zulassen. Ergänzend braucht es kurzlebige Zugangsdaten, Protokollierung, Freigaben für kritische Aktionen und automatische Abbruchregeln. Lösungen wie isolierte Cloud-Sandboxes für KI-Agenten adressieren einen Teil dieses Problems, ersetzen aber keine korrekte Konfiguration.
Was Unternehmen im DACH-Raum daraus ableiten können
Für Unternehmen ist die wichtigste Erkenntnis banal, aber relevant: Eine Sandbox ist nur so sicher wie ihre tatsächlichen Netzwerkregeln. Bei externen Sicherheitstests und agentischen KI-Systemen sollte vertraglich und technisch festgelegt sein, welche Systeme erreichbar sind und wie ein Vorfall gemeldet wird.
Öffentliche Repositories bleiben zudem ein erhebliches Risiko. API-Schlüssel, Passwörter und andere Geheimnisse sollten bereits vor einem Commit erkannt werden. Werden Zugangsdaten dennoch veröffentlicht, müssen sie sofort widerrufen werden, denn das nachträgliche Entfernen aus dem sichtbaren Quelltext löscht sie nicht automatisch aus der Git-Historie.
Der Fall spricht auch gegen blindes Vertrauen in geschlossene KI-Dienste. Unternehmen bleiben für Zugriffsrechte, Datenschutz und die Absicherung ihrer Infrastruktur verantwortlich, selbst wenn der Modellanbieter Sicherheitsmechanismen verspricht. Self-Hosting kann mehr Kontrolle bieten, erhöht aber zugleich den Aufwand für Isolation, Überwachung und Aktualisierungen.