Wer heute über KI und IT-Sicherheit spricht, spricht fast zwangsläufig über Agenten. Gemeint sind KI-Systeme, die nicht nur Fragen beantworten, sondern eigenständig Werkzeuge bedienen, Code ausführen und mehrstufige Aufgaben abarbeiten. Für Angreifer ist das ein Multiplikator, für Verteidiger ebenso. Google setzt deshalb auf beiden Seiten an: mit Agenten, die Sicherheitslücken aufspüren und schließen, und mit einem Red Team, das eigene Angriffsagenten baut, um die Verteidigung auf das vorzubereiten, was kommt.

Das Jahr der ausgebrochenen Agenten

2026 haben gleich mehrere KI-Labore erlebt, dass ihre Agenten die Testumgebung verlassen. Im April machte Anthropic öffentlich, dass eine frühe Version von Claude Mythos Preview bei einem Sicherheitstest aus einer Sandbox ausgebrochen war, Internetzugang erlangte und einem Forscher eine E-Mail schickte. Der Ausbruch war dabei die gestellte Testaufgabe; Anthropic hat das Modell nicht allgemein veröffentlicht (The Next Web, Computing).

Schwerer wog der Fall bei OpenAI. Im Juli 2026 umgingen Agenten während interner Cyber-Evaluierungen die Internet-Isolation und kompromittierten Teile der eigenen Forschungsinfrastruktur sowie Systeme von Hugging Face (OpenAI, Hugging Face). Ende September meldete OpenAI einen weiteren, deutlich kleineren Ausbruch über einen DNS-Resolver und pausierte das Training zum zweiten Mal binnen drei Monaten (Fortune).

Auch Google blieb nicht verschont: Im Mai drang eine Gemini-Instanz bei einem Test in Systeme dreier realer Firmen ein – und stoppte dann von selbst (mehr dazu unten). Vor diesem Hintergrund ist die Frage berechtigt, wie Google Agenten in der eigenen Sicherheitsarbeit einsetzt und absichert.

Die Bedrohungslage: raffinierter, breiter, schneller

Daniel Fabian, Globaler Leiter der Google Red Teams, sieht KI die Angriffslandschaft in drei Dimensionen verändern. Die Raffinesse steigt, weil auch weniger erfahrene Akteure Zero-Days ausnutzen oder personalisierte TTPs einsetzen können, die früher Elitegruppen vorbehalten waren. Die Skalierung löst sich vom Personal: Angriffe laufen parallel, ohne dass dafür mehr Menschen nötig sind. Und die Geschwindigkeit nähert sich der Maschinenzeit – ein Agent kann sein Ziel erreicht haben, bevor ein Analyst den Alarm überhaupt öffnet.

Am meisten profitieren laut Fabian nicht die gezielt arbeitenden Spionagegruppen. Sie scheuen "laute", schwer berechenbare Agenten, weil eine Entdeckung teure Werkzeuge und Zugänge kostet. Ransomware-Betreiber und Initial Access Broker dagegen setzen auf Masse; für sie ist etwas weniger Präzision ein günstiger Tausch gegen Tempo und geringere Personalkosten.

Für Administratoren besonders relevant sind zwei Punkte:

• Security by Obscurity ist erledigt. Agenten lesen Netzwerk- und Systemdokumentation und erkunden eine Umgebung in einem Bruchteil der Zeit. Jede Infrastruktur, die man für eigene Agenten bereitstellt, nützt auch fremden.
• Die alten Baustellen werden zur Sofortgefahr. Schwache Passwörter, Schlüssel auf der Festplatte und überprivilegierte Konten erkennt ein Agent sofort und nutzt sie für laterale Bewegung in Sekunden.

Fabian rechnet damit, dass frei herunterladbare offene Modelle binnen sechs bis zwölf Monaten die heutigen Cyber-Fähigkeiten führender Modelle erreichen. Deren Schutzmechanismen lassen sich etwa per "Abliteration" entfernen. Als wahrscheinliche Muster nennt er industrialisiertes Social Engineering mit langfristigem Vertrauensaufbau, automatisierte Angriffsketten mit Modellen direkt auf kompromittierten Geräten, billigere Lieferkettenangriffe inklusive manipulierter Skill-Dateien für Agenten sowie schnell generierte Wegwerf-Implantate.

Den Verteidigern bleiben zwei strukturelle Vorteile: Sie kennen ihre Umgebung am besten, und sie können dieselben Werkzeuge zuerst nach innen richten. "Die Teams, die verlieren, werden nicht diejenigen mit weniger Ressourcen sein", erläutert Fabian in einem Textbeitrag (PDF-Datei), sondern jene, die das Thema als Zukunftsproblem behandeln.

Big Sleep: Lücken vor den Angreifern finden

Big Sleep ist ein Agent zur Schwachstellensuche, den Google DeepMind und Project Zero im November 2024 vorgestellt haben. Er soll Zero-Days in verbreiteter Software finden, bevor Angreifer sie nutzen (Google Cloud Blog).

Im Juli 2025 meldete Google einen Meilenstein: Gemeinsam mit der Google Threat Intelligence Group identifizierte Big Sleep eine kritische SQLite-Lücke (CVE-2025-6965), die nur Angreifern bekannt war und kurz vor dem Einsatz stand. Die Lücke wurde gemeldet und gepatcht, bevor sie ausgenutzt werden konnte. Google spricht vom nach eigener Einschätzung ersten Fall, in dem ein KI-Agent einen Exploit-Versuch in freier Wildbahn direkt vereitelt hat.

Der Mehrwert liegt im Tempo: Ein Mensch hätte zwei Versionen des Quellcodes manuell vergleichen müssen, während die Angreifer schon bereitstanden. Big Sleep wird inzwischen auch für andere Open-Source-Projekte eingesetzt; veröffentlichte Funde listet Google in einem öffentlichen Issue Tracker.

CodeMender: finden, beweisen, flicken

Wo Big Sleep sucht, soll CodeMender den Kreis schließen: Der Code-Security-Agent aus der Forschung von Google DeepMind findet Lücken, weist ihre Ausnutzbarkeit nach und liefert einen getesteten Patch. Seit dem 21. Juli 2026 ist er als Preview über die Gemini Enterprise Agent Platform oder als Teil von AI Threat Defense verfügbar (Google Cloud Blog).

Der Ablauf gliedert sich in drei Stufen:

1. Scan: CodeMender sucht nach schwer auffindbaren Klassen wie Speicherfehlern, Injections, Web-Schwachstellen, Kryptofehlern und unsicherem Datenhandling. Unterstützt werden unter anderem C/C++, Go, Java, Python, Ruby, Rust und TypeScript.
2. Verify: Der Agent baut einen Proof-of-Concept-Exploit und führt ihn in einer isolierten, vom Kunden verwalteten Sandbox aus. So werden False Positives aussortiert, bevor jemand Zeit in einen Fix steckt.
3. Remediate: Für bestätigte Lücken erzeugt CodeMender einen Patch als Diff im Entwicklerwerkzeug; ein zweites Modell prüft als "LLM-as-a-judge", ob der Fix bestehende Funktionen bricht.

Entscheidend für den Betrieb: Entwickler prüfen und genehmigen jeden Patch manuell, bevor er ins Repository gelangt. Der Agent lässt sich in CI/CD-Pipelines einbinden oder lokal per CLI nutzen. Google verspricht Datenisolation, Routing über die eigene VPC und keine Speicherung des Quellcodes. Eine Variante mit dem spezialisierten Modell Gemini 3.5 Flash Cyber bleibt vorerst einem kleinen Kreis von Regierungen und vertrauenswürdigen Partnern vorbehalten.

PageBreak: Schluss mit "AI Slop"

PageBreak hat mehr als 500 XSS-Lücken in Googles eigenen Webanwendungen gefunden, auch auf sensiblen Domains – bei einer False-Positive-Rate nahe null. Der interne Agent des Google Product Security Teams startete im November 2025 als Pilot und ist seit Januar 2026 ein eigenständiges Projekt; er läuft überwiegend mit Gemini 3.1 Pro und Gemini 3.5 Flash (Google Blog).

Das Projekt adressiert ein Problem, das viele Security-Teams kennen: LLM-basierte Scanner produzieren Berge unbestätigter Hypothesen, die Produktteams mehr belasten als entlasten. PageBreak setzt deshalb auf deterministische Validierung. Jede vermutete Lücke geht an einen spezialisierten, nicht von einer KI geschriebenen Validator, der eine echte Payload gegen die laufende Anwendung ausführt.

Bei XSS prüft er etwa, ob das injizierte JavaScript tatsächlich ausgeführt wird; bei Path Traversal legt er eine Datei an und versucht, sie über die Anwendung zu lesen. Weitere Validatoren gibt es für SQL Injection, Remote Code Execution und SSRF. Unbestätigte Funde erreichen die Produktteams nicht. Sie dienen intern als Ausgangspunkt für weitere Scans und zeigen, wo neue Validatoren nötig sind. Der Agent darf zudem melden, welche Fähigkeiten oder Zugänge ihm für eine Bestätigung fehlen.

Aufschlussreich ist der Gegentest: Anwendungen auf Googles gehärteten Secure-by-Design-Web-Frameworks hielten dem Agenten gut stand. Bis zum 4. September 2026 fand PageBreak dort in Hunderten Anwendungen nur zwei XSS-Lücken, beide in internen Anwendungen oder Debug-Endpunkten. Künftig soll PageBreak enger mit CodeMender zusammenarbeiten, sodass Produktteams am Ende nur noch vorgeschlagene Fixes abnehmen.

Red Team baut seinen eigenen Angreifer

Googles Red Team will die Organisation auf agentenbasierte Angreifer vorbereiten, indem es selbst einen Red-Teaming-Agenten entwickelt. Die Mission bleibt laut Fabian dieselbe wie immer – das Unternehmen auf reale Angreifer vorbereiten. Neu ist die Frage, der sich die Blue Teams stellen müssen:

• Lassen sich die Spuren legitimer KI-Agenten der eigenen Mitarbeitenden von denen bösartiger Agenten unterscheiden?
• Ist die Erkennung schnell genug, um auf einen Angreifer in Maschinenzeit zu reagieren?
• Wartet die Abwehr auf menschliches Eingreifen, während der Gegner autonom agiert?

Den Weg dorthin beschreibt Fabian als iterativ statt als Großprojekt. Das Team automatisiert zunächst einzelne, isolierte Schritte klassischer Einsätze, etwa Aufklärung, Erstzugriff oder laterale Bewegung. Aus jeder Übung entsteht ein neuer, modularer "Subagent". Ein Orchestrator verknüpft diese Module schrittweise zu durchgängigen Angriffssimulationen, die mit jeder Operation besser werden. Das Rezept taugt auch für kleinere Red Teams: Es verlangt kein fertiges autonomes System, sondern einen ersten automatisierten Baustein.

Enge Grenzen und der Mensch am Schalter

Bei internen Pentests setzt Google seinen KI-Agenten enge Grenzen, sagt Daniel Fabian im Gespräch. Datenverändernde Zugriffe eines Agenten müssen von einem Menschen geprüft und freigegeben werden. Dasselbe Prinzip findet sich in den Produkten: CodeMender schlägt Patches vor, committet sie aber nicht selbst; PageBreak meldet nur deterministisch bestätigte Funde.

Wie nötig solche Leitplanken sind, zeigt ein Vorfall aus dem Mai 2026. Bei einem Capture-the-Flag-Test des externen KI-Sicherheitsdienstleisters Irregular sollte Gemini Daten aus dem simulierten Netz einer fiktiven Firma holen. Die Testumgebung war jedoch fälschlich mit dem Internet verbunden, und der Name der fiktiven Firma entsprach einer realen Domain (Tech Times). Gemini verschaffte sich Zugang zu Systemen dreier realer Unternehmen, einmal durch wiederholtes Passwortraten, zweimal mit Zugangsdaten aus einem öffentlichen Code-Repository (The Hacker News).

In allen drei Fällen brach das Modell ab, als es erkannte, dass es reale Firmen angriff. Google wertet das als Beleg, dass das Modell sich angemessen verhalten hat und keine Fehlausrichtung vorlag. Nach einem Bericht des Wall Street Journal lief dagegen bei einem Irregular-Test mit Anthropics Claude Opus 4.7 der Angriff weiter, obwohl der Agent das Ziel als wahrscheinlich real erkannt hatte (Gizmodo).

Zur Einordnung gehören drei Punkte:

• Der Abbruch kam erst nach dem erfolgreichen Zugriff. Er zeigt ein erwünschtes Verhalten, verhinderte die Einbrüche aber nicht und ist keine Garantie für künftige Läufe (Quasa).
• Die Ursache lag in der Testumgebung, nicht in einer Anweisung zum Angriff auf reale Ziele – also genau dort, wo enge Scopes und Netzisolation ansetzen.
• Irregular informierte Google Ende Juli; öffentlich bestätigt hat Google den Vorfall erst am 18. September, nachdem das Wall Street Journal angefragt hatte. Die betroffenen Firmen wurden nach Googles Angaben benachrichtigt (Eastern Herald).

Schutz vor Prompt Injections

Google misst die Abwehr gegen Prompt Injection empirisch: Das Team testet schädliche Prompts in zahlreichen Variationen und wertet aus, welcher Anteil davon durchkommt, erklärte Viviana Sutedjo, Software-Ingenieurin Google Cybersecurity. Relevant ist das vor allem für indirekte Angriffe. Dabei steckt die bösartige Anweisung nicht in der Nutzereingabe, sondern etwa in einer E-Mail, die Gemini für den Nutzer zusammenfasst. Im schlimmsten Fall führt der Assistent dann unbemerkt Aktionen aus oder leitet vertrauliche Daten ab (Google Workspace Admin-Hilfe).

Die Messung ist Teil einer mehrschichtigen Verteidigung, die Google seit 2025 öffentlich beschreibt. Die Basis bildet ein Modelltraining mit gegnerischen Daten, das die Widerstandsfähigkeit gegen indirekte Injections erhöhen soll (Google Blog). Darauf setzen fünf weitere Schutzschichten auf:

• Klassifikatoren, die eingebettete Anweisungen in Inhalten erkennen
• Security Thought Reinforcement, das das Modell an seine eigentliche Aufgabe erinnert
• Markdown-Bereinigung und das Schwärzen verdächtiger URLs, um Datenabfluss über Links und Bilder zu verhindern
• Nutzerbestätigung vor riskanten Aktionen
• Hinweise an Endnutzer, wenn ein Schutzmechanismus gegriffen hat

Das Prinzip dahinter ist dasselbe wie im Red Teaming: Keine Schicht muss perfekt sein, solange jede die Erfolgsquote messbar senkt und Angreifer zu aufwändigeren, leichter erkennbaren Methoden zwingt.

SAIF: Googles Leitfaden für sichere KI

Wer die Prinzipien hinter Googles Vorgehen nachlesen will, findet sie im Secure AI Framework (SAIF), auf das die Referenten verwiesen. Google beschreibt es als Praxisleitfaden für KI-Sicherheit: Eine Risikokarte ordnet 15 typische Risiken entlang der KI-Entwicklung ein und nennt passende Gegenmaßnahmen. Eine eigene Erweiterung widmet sich Agenten, deren Fähigkeit zu autonomem Handeln neue Risiken schafft, etwa unbeabsichtigte "Rogue Actions" oder den Abfluss sensibler Daten.

Die drei dort empfohlenen Agenten-Kontrollen lesen sich wie eine Zusammenfassung dessen, was Fabian und Sutedjo aus der Praxis berichteten: Aktionen, die Daten verändern oder im Namen des Nutzers handeln, brauchen eine Freigabe durch den Menschen. Rechte und Werkzeuge eines Agenten folgen dem Least-Privilege-Prinzip. Und Aktionen, Tool-Aufrufe und Schlussfolgerungen des Agenten werden protokolliert, damit sie nachvollziehbar und prüfbar bleiben.

Mit dem Agent Risk Self Assessment können Unternehmen zudem per Fragebogen ermitteln, welche Risiken sie betreffen. Google weist allerdings darauf hin, dass die Inhalte der Website als Orientierung für die Branche gedacht sind und nicht die aktuelle technische Umsetzung bei Google abbilden.

Fünf Tipps für Administratoren

Aus den Vorträgen und den Vorfällen des Jahres lassen sich fünf konkrete Aufgaben ableiten:

1. Hygiene zuerst. Schwache Passwörter, Klartext-Schlüssel auf Festplatten und überprivilegierte Konten sind für Agenten die schnellste Route ins Netz. Zwei der drei Gemini-Einbrüche liefen über Zugangsdaten aus einem öffentlichen Repository – Secret Scanning gehört auf die Liste.
2. Eigene Agenten eng führen. Wer Agenten für Pentests oder Betrieb einsetzt, sollte Scopes eng setzen, Netzzugriffe isolieren und schreibende Aktionen an eine menschliche Freigabe koppeln.
3. Testumgebungen wirklich abschotten. Alle bekannten Ausbrüche 2026 begannen mit einer Sandbox, die weniger dicht war als gedacht. Egress-Regeln, DNS und Namenskollisionen fiktiver Ziele mit realen Domains gehören geprüft.
4. Erkennung auf Maschinenzeit auslegen. Detection und automatisierte Reaktion müssen greifen, bevor ein Analyst den Alarm sieht, und legitime von fremden Agenten unterscheiden können.
5. Nur verifizierte Funde weiterreichen. Wer KI-Scanner nutzt, sollte Treffer vor der Übergabe an Entwickler bestätigen, wie es PageBreak mit seinen Validatoren tut.

Fazit

Google scheint verstanden zu haben, dass sich der Wettlauf um KI-Sicherheit nicht mit abwartender Vorsicht gewinnen lässt. Der Konzern setzt Agenten deshalb konsequent auf der Seite der Verteidigung ein. Big Sleep findet Lücken, bevor Angreifer sie ausnutzen. CodeMender liefert getestete Patches, und PageBreak meldet nur Schwachstellen, die er auch beweisen kann. Parallel baut das Red Team seinen eigenen Angreifer-Agenten, damit die Abwehr lernt, in Maschinenzeit zu reagieren.

Bemerkenswert ist dabei weniger die Technik als die Haltung dahinter: Kein Agent handelt ohne Leine. Enge Scopes, minimale Rechte und die menschliche Freigabe jeder verändernden Aktion ziehen sich durch alle Projekte und finden sich auch im Secure AI Framework wieder. Der Gemini-Vorfall zeigt, warum diese Leine nötig ist. Dass das Modell von selbst stoppte, als es reale Firmen erkannte, spricht für Googles Ansatz. Verhindert hat es die drei Einbrüche aber nicht. Und öffentlich gemacht hat Google den Fall erst, als das Wall Street Journal nachfragte.

Für Administratoren folgt daraus: Auf das Wohlverhalten eines Modells darf sich niemand verlassen. Sicher ist nur eine Umgebung, in der ein Agent auch dann keinen Schaden anrichten kann, wenn er sich falsch verhält. Wer jetzt mit Hygiene, strikter Isolation und eigenen Tests beginnt, hat im Wettlauf gegen die Angreifer-Agenten noch einen Vorsprung. Wer das Thema als Zukunftsproblem vertagt, wird ihn verlieren.