Am 19. September 2026 wurde öffentlich, dass Gemini im Mai während einer von Irregular durchgeführten Sicherheitsprüfung auf Systeme dreier realer Unternehmen zugegriffen hatte. Der Test sollte mit fiktiven Firmen in einer abgeschotteten Umgebung stattfinden. Ein Fehler in der Infrastruktur oder Konfiguration ermöglichte jedoch den Zugang zum Internet.

Google zufolge gelangte Gemini in einem Fall durch wiederholtes Raten eines Passworts in ein geschütztes System. In zwei weiteren Fällen stieß das Modell auf Zugangsdaten in öffentlich zugänglichen Repositorien. Nachdem Gemini erkannt hatte, dass die Ziele reale Unternehmen waren, stoppte es laut Google in allen drei Fällen.

Was während der Gemini-Prüfung geschah

Irregular hatte die Prüfung als Capture-the-Flag-Übung mit fiktiven Unternehmen angelegt. Solche Tests simulieren Sicherheitsaufgaben, damit ein KI-System Schwachstellen in einer kontrollierten Umgebung bearbeiten kann. Die technische Grenze zwischen dieser Simulation und dem öffentlichen Internet hielt in diesem Fall jedoch nicht dicht.

Dadurch konnte Gemini Informationen außerhalb der vorgesehenen Testumgebung erreichen und weitere Schritte ausführen. Ein fiktives Unternehmen trug außerdem denselben Namen wie ein reales Unternehmen. Diese Namensüberschneidung lenkte die Aktivität zusätzlich auf ein echtes Ziel.

Die drei Zugriffe verteilten sich nach Googles Darstellung auf unterschiedliche Wege:

ZugangswegFälleWas geschah
Wiederholtes Raten eines Passworts1Gemini erriet wiederholt ein Passwort und erhielt dadurch Zugang zu einem geschützten System.
Zugangsdaten aus öffentlichen Repositorien2Gemini nutzte Zugangsdaten, die in öffentlich erreichbaren Repositorien zu finden waren.

Wie Gemini in reale Systeme gelangte

Gemini gelangte während einer Sicherheitsprüfung durch einen Fehler in der Testumgebung ins Internet und stoppte laut Google, nachdem es reale Unternehmenssysteme erkannt hatte.

Der entscheidende Fehler lag zunächst nicht in einem komplizierten Angriff, sondern in der fehlenden technischen Abschottung des Tests. Eine Umgebung, die nur fiktive Ziele enthalten sollte, konnte Verbindungen ins Internet herstellen. Damit war die Begrenzung nicht mehr allein eine Frage der Anweisung an das Modell, sondern eine Schwachstelle der Testumgebung selbst.

Der Fall zeigt damit eine praktische Grenze für KI-Agenten: Sobald ein System mit Werkzeugen, Netzwerkzugriff und mehrstufigen Aufgaben arbeitet, muss die Umgebung die zulässigen Verbindungen technisch erzwingen. Die spätere Reaktion des Modells beseitigte den vorherigen Zugriff nicht.

Gemini stoppte – die technische Grenze war trotzdem überschritten

Google erklärte, Gemini habe nach der Erkennung der realen Ziele in allen drei Fällen aufgehört. Nach Darstellung des Unternehmens wurden die betroffenen Organisationen informiert; Google erklärte außerdem, es sei kein Schaden entstanden. Diese Einschätzung stammt von Google.

Für die Sicherheitsarchitektur bleibt der frühere Schritt entscheidend: Gemini hatte die isolierte Testumgebung bereits verlassen und reale Systeme erreicht. Ein Modell, das eine falsche Zielzuordnung später erkennt, ersetzt deshalb keine Netzwerkregeln, zeitlich begrenzten Zugangsdaten und lückenlose Protokollierung. Diese Kontrollen müssen den erlaubten Aktionsraum vor dem Zugriff begrenzen.

Welche Unternehmen betroffen waren

Google hat die drei betroffenen Unternehmen nicht öffentlich identifiziert. Auch das genaue Gemini-Modell, das bei der Prüfung eingesetzt wurde, nannte Google nicht.

Der Vorfall belegt keinen Datenabfluss aus gewöhnlichen Gemini-Unterhaltungen. Er beschreibt einen Gemini-Einsatz in einer Cybersicherheitsprüfung, bei dem unbeabsichtigter Internetzugang zu realen Unternehmenssystemen führte.