Googles Red Team zerlegt agentische Angriffsketten

Der Angriff beginnt nicht mehr am Prompt-Fenster

Sechs bis zwölf Monate. So lange, schätzt Googles Red Team, dauert es noch, bis frei verfügbare Open-Weight-Modelle bei offensiven Cybersicherheits-Fähigkeiten mit den Flaggschiff-Modellen der großen Anbieter gleichziehen. Diese Zahl steckt in einem aktuellen Blogbeitrag von Google, in dem Daniel Fabian, Leiter der Red Teams des Konzerns, beschreibt, wie sich seine Abteilung neu aufstellt. Der Beitrag stammt vom 13. August 2026 und ist bemerkenswert nüchtern für ein Unternehmen, das sonst gern mit Superlativen wirbt.

Googles Kernaussage: Autonome Angriffe, ausgeführt von Agenten im Auftrag von Bedrohungsakteuren, sind kein Zukunftsszenario mehr, sondern ein aktuelles Betriebsrisiko. Wer diese Formulierung als reine Marketing-Zuspitzung abtut, sollte sich klarmachen, dass sie von einem Team stammt, dessen Job darin besteht, genau solche Angriffe zu simulieren, nicht sie zu verkaufen. Trotzdem bleibt eine Leerstelle: Konkrete Zahlen zu bereits beobachteten agentischen Angriffen liefert der Beitrag nicht. Das ist die erste Einordnung, die dieser Text vornehmen muss, bevor er Googles Rahmen übernimmt.

Der entscheidende Bruch mit der bisherigen Sicherheitslogik liegt woanders: Ein Angriff endet nicht mehr am Modell, das eine schädliche Antwort verweigert oder ausgibt. Er zieht sich über Identitäten, Werkzeugrechte, gespeicherten Kontext und mehrstufige Handlungsketten – und genau dort, wo klassische Red-Team-Übungen bislang aufhörten, fängt die neue Angriffsfläche erst an. Diese Verschiebung ist der eigentliche Kern des Beitrags, mehr als jede einzelne Bedrohungsprognose.

Drei Dimensionen einer neuen Bedrohung: Sophistication, Scale, Speed

Google gliedert die Verschiebung in drei Achsen, und jede einzelne lässt sich an konkreten Mechanismen festmachen, nicht nur an Stimmung. Erstens: Raffinesse demokratisiert sich. Angreifer ohne tiefes Fachwissen kommen über automatisierte Werkzeuge inzwischen an Taktiken, die früher wenigen spezialisierten Gruppen vorbehalten waren – die Zahl der über Bug-Bounty-Programme gemeldeten Schwachstellen liefert dafür laut Google einen Indikator.

Zweitens: Skalierung braucht keine zusätzlichen Menschen mehr. Wo mittelgroße Angreifergruppen früher durch die Zahl verfügbarer Operatoren begrenzt waren, laufen Kampagnen jetzt parallel und ohne diese Deckelung. Ransomware-Gruppen und sogenannte Initial-Access-Broker profitieren laut Google besonders stark davon, weil sie ohnehin auf Volumen statt auf chirurgische Präzision setzen; ein kleiner Qualitätsverlust pro Angriff ist für sie ein günstiger Tausch gegen viel mehr Angriffe insgesamt.

Drittens, und das ist der Punkt mit dem größten praktischen Gewicht: Die Verweildauer zwischen erstem Zugriff und Zielerreichung kollabiert in Richtung Maschinenzeit. Google beschreibt das so, dass Agenten selbst bei ausgelöster Erkennung ihr Ziel oft erreichen, bevor ein menschlicher Analyst den Alarm überhaupt gesichtet hat. Reine „Security through obscurity“, also Schutz durch mangelnde Dokumentation der eigenen Systeme, hält Google für faktisch tot, weil Agenten Netzwerk- und Systemdokumentation in einem Tempo auswerten, das kein manuelles Reconnaissance-Team erreicht.

Für Verteidigungsteams heißt das: Eine Erkennung, die drei Minuten nach dem Alarm greift, kann bei menschengeführten Angriffen ausreichen und bei agentischen Angriffen bereits zu spät sein. Wer Reaktionszeiten noch in Schichten und Eskalationsstufen plant, plant an der eigentlichen Bedrohung vorbei.

Wie Angreifer die Agenten-Ökonomie für sich nutzen

Google benennt fünf Muster, in denen Angreifer Agenten aus heutiger Sicht am wahrscheinlichsten einsetzen werden, und keines davon ist exotisch. Industrialisiertes Social Engineering steht oben auf der Liste: Weil das Anlegen und Pflegen glaubwürdiger Fake-Identitäten durch Automatisierung fast nichts mehr kostet, erwartet Google lang angelegte, personalisierte Phishing-Kampagnen, bei denen ein Agent über Wochen Vertrauen aufbaut, bevor er zuschlägt.

Ein zweites Muster betrifft automatisierte Angriffsketten samt lokal laufender Modelle, die kompromittierte Systeme triagieren, ohne verräterischen Netzwerkverkehr zu erzeugen – ein bewusster Verzicht auf große Datenübertragungen, um Erkennungssysteme zu unterlaufen. Ein drittes Muster verbilligt komplexe Lieferkettenangriffe, wie sie historisch enorme Vorbereitung erforderten – Google zieht hier ausdrücklich die Parallele zur xz-utils-Backdoor, einem der aufwendigsten bekannten Supply-Chain-Angriffe der vergangenen Jahre. Diese Einordnung passt zu einem Trend, den auch die Meldung über einen bereits realen, agentengetriebenen Angriff auf Hugging-Face-Infrastruktur zeigt: Was Google hier noch als Prognose formuliert, hat anderswo bereits begonnen.

Die verbleibenden zwei Muster – billige Angriffswerkzeuge, die sich Angreifer eher leisten können zu verbrennen, weil Nachschub kaum noch kostet, und die maschinelle Ausnutzung simpler Sicherheitshygiene wie schwacher Passwörter, offen liegender Zugangsdaten oder überprivilegierter Accounts – sind für sich genommen wenig überraschend. Ihre Kombination mit der oben beschriebenen Geschwindigkeit ist es, die den eigentlichen Unterschied macht: Fehler, die früher Tage bis zur Ausnutzung Zeit ließen, werden jetzt in Minuten gefunden und bewaffnet.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellseedream_v4_5; quality=high; 5120x2880PromptTwo gloved hands interrupt a chain of translucent action links before it reaches a locked resource vessel, with an isolated memory bead held aside for examination. A tight documentary composition emphasizes hands-on consequences in a fully text-free scene with blank surfaces and no legible markings. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

Speicher macht Fehler dauerhaft

Der am wenigsten diskutierte Teil der Google-Analyse betrifft nicht Angreifer, sondern die Architektur der eigenen Verteidigungssysteme. Agentische Systeme tragen Kontext über Sitzungen hinweg mit sich, in Form von Speicher, Werkzeugberechtigungen und mehrstufigen Handlungsprotokollen. Ein einzelner falscher Eintrag in diesem Speicher – etwa durch eine manipulierte Dokumentquelle oder einen kompromittierten Zwischenschritt – wirkt nicht nur einmal, sondern in jeder folgenden Aktion, die der Agent auf dieser Grundlage ausführt.

Klassisches Red Teaming prüfte einen Angriffsschritt und dessen unmittelbare Folge. Bei einem Agenten mit persistentem Speicher reicht das nicht mehr: Ein Test muss zeigen, ob ein einmal untergejubelter falscher Fakt drei, vier oder zehn Handlungsschritte später noch wirkt, und ob das System überhaupt in der Lage ist, eine solche Verkettung im Nachhinein zu erkennen. Genau diese Kettenprüfung, nicht die einzelne Schwachstelle, ist der eigentliche Maßstab für Red Teams in der agentischen Ära.

Für Sicherheitsverantwortliche in Unternehmen bedeutet das eine unbequeme Priorität: Speicherhygiene und Zugriffsprotokolle für Agenten verdienen mindestens so viel Aufmerksamkeit wie klassisches Patch-Management, weil ein einziger vergifteter Kontext-Eintrag sich über Dutzende automatisierter Aktionen fortpflanzen kann, bevor ihn jemand bemerkt. Wer Agenten produktiv einsetzt, ohne diese Kette regelmäßig zurückzusetzen und zu auditieren, sammelt über Wochen ein Risiko an, das bei einer einzelnen Modellabfrage niemals entstehen könnte.

Identität und Werkzeugrechte als durchgehende Kette

Der zweite blinde Fleck klassischer Sicherheitsmodelle liegt bei Identität und Werkzeugzugriff. Ein Agent agiert typischerweise unter einer Dienst-Identität mit Rechten auf mehrere Systeme gleichzeitig – Kalender, Dateiablage, interne APIs, manchmal Zahlungssysteme. Wird dieser eine Zugang kompromittiert, erbt der Angreifer nicht eine einzelne Berechtigung, sondern die gesamte Werkzeugkette, die der Agent im Namen des Nutzers ausführen darf.

Das ist der Punkt, an dem Googles Darstellung über reine Bedrohungsbeschreibung hinausgeht und zur impliziten Kritik an heutigen Berechtigungsmodellen wird, auch wenn der Beitrag das nicht explizit so benennt. Wer einem Agenten Lese- und Schreibrechte auf ein Ticketsystem, ein CRM und einen Cloud-Speicher gleichzeitig gibt, hat effektiv eine neue, oft schwach überwachte Rolle im Identitätsmanagement geschaffen. Red Teams müssen diese Rolle testen wie jede andere privilegierte Identität, nicht wie einen harmlosen Automatisierungs-Helfer.

Bezeichnend ist, dass Google diese Verkettung von Identität, Werkzeug und Speicher explizit als eine zusammenhängende Angriffsfläche beschreibt und nicht als drei getrennte Probleme. Für die Praxis heißt das: Eine isolierte Prüfung der Modell-Ausgaben, wie sie viele Unternehmen heute noch als KI-Sicherheit verstehen, deckt genau die Kette nicht ab, die laut Google inzwischen am ehesten ausgenutzt wird. Eine reine Modellprüfung ohne Blick auf Identität und Speicher testet damit nur einen Bruchteil der real relevanten Angriffsfläche.

Wie Red Teams selbst zu Agentenbauern werden

Googles praktische Antwort ist bemerkenswert konkret: Die Red Teams sollen keine fertige, vollautonome Angriffssimulation von heute auf morgen bauen, sondern schrittweise vorgehen. Jede manuelle Übung – Aufklärung, initialer Zugriff, seitliche Bewegung im Netzwerk – wird nach und nach in ein wiederverwendbares Modul, einen sogenannten Subagenten, überführt. Diese Module lassen sich anschließend über einen Orchestrator verbinden, sodass am Ende ganze Angriffsketten automatisiert nachgestellt werden können.

Diese Iterationslogik ist der eigentlich interessante Teil des Beitrags, mehr als jede Bedrohungsprognose. Sie beschreibt einen Weg, wie ein Sicherheitsteam ohne riesiges Extra-Budget von klassischen, punktuellen Übungen zu kontinuierlicher, agentischer Simulation kommt – vorausgesetzt, es dokumentiert jede Übung so, dass sie tatsächlich in ein Modul überführbar ist. Genau diese Disziplin, nicht die Technologie selbst, dürfte in vielen Teams der limitierende Faktor sein.

Wer daraus liest, jedes Unternehmen brauche jetzt sofort einen vollautomatisierten Red-Team-Agenten, überschätzt die Botschaft. Google selbst betont die Schrittweise, nicht den großen Sprung, und schreibt, dass ein Team nach einer Handvoll Übungen ein robustes System besitzt, das mit jeder weiteren Übung besser wird. Ein realistischer erster Schritt ist die Automatisierung eines einzigen, klar abgegrenzten Übungsbausteins – etwa der Aufklärungsphase – bevor überhaupt über einen Orchestrator gesprochen wird.

Was Googles Beitrag bewusst offen lässt

So belastbar der Rahmen ist, so auffällig sind die Lücken. Der Beitrag nennt keine einzige konkrete, öffentlich bestätigte Operation, bei der ein Angreifer bereits einen vollautomatisierten Agenten für einen mehrstufigen Angriff eingesetzt hat. Alle fünf beschriebenen Nutzungsmuster sind explizit als Prognose markiert, nicht als Beobachtung – Google schreibt selbst, dass belastbare Bedrohungsdaten zu real gebauten Angreifer-Agenten derzeit noch begrenzt sind.

Das relativiert die Dringlichkeit nicht, aber es sollte jede Ableitung „Google warnt vor X“ bremsen, wo eigentlich „Google erwartet X in den kommenden Monaten“ stehen müsste. Auch fehlen im Beitrag Kennzahlen zu Kosten, Ausfallzeiten oder tatsächlicher Erfolgsrate der beschriebenen Red-Team-Automatisierung bei Google selbst – eine überprüfbare Grundlage für den Nutzen dieses Ansatzes liefert der Konzern damit nicht, sondern lediglich eine plausible Methodik.

Interessant ist der Beitrag auch deshalb, weil er zeitlich in eine Reihe branchenweiter Bewegungen fällt. Parallel dazu haben etwa SAP, Microsoft und Google gemeinsam an Governance-Leitplanken für Unternehmensagenten gearbeitet, was zeigt, dass die Debatte längst über einzelne Blogbeiträge hinausgeht und in konkrete Betriebsvorgaben mündet, die Unternehmen jenseits von Google direkt betreffen.

Kontrollfragen für Sicherheitsverantwortliche

Google selbst formuliert drei Fragen, die jedes Verteidigungsteam beantworten sollte, und sie eignen sich als Ausgangspunkt für einen eigenen Check: Lässt sich der Datenverkehr legitimer, von Mitarbeitenden genutzter Agenten von dem böswilliger Agenten unterscheiden? Arbeiten die eigenen Erkennungspipelines nahe genug an Echtzeit, um agentische Angriffe überhaupt einzuholen? Und blockieren korrektive Kontrollen tatsächlich auf einen Menschen im Freigabeprozess, oder ist dieser Schritt inzwischen nur noch Formsache?

Aus diesen drei Fragen lässt sich ein greifbarer Prüfauftrag ableiten, der über die reine Modell-Sicherheit hinausgeht: Wer verantwortet die Berechtigungen, die ein Agent im Namen eines Nutzers ausüben darf, und wo endet diese Verantwortung? Welche Speicherinhalte eines Agenten wären im Ernstfall überhaupt forensisch nachvollziehbar? Und wie lange dürfte eine Erkennung heute maximal dauern, damit sie einen agentischen Angriff noch vor Zielerreichung stoppt?

Wer diese drei Fragen für die eigene Organisation nicht in Minuten, sondern erst nach tagelanger Recherche beantworten kann, hat bereits die Antwort auf die wichtigste Frage: ob das eigene Sicherheitsteam auf eine agentische Angriffskette vorbereitet ist, oder nur auf die Angriffe von gestern. Genau an dieser Lücke, nicht an fehlenden Werkzeugen, dürfte sich in den kommenden Monaten entscheiden, welche Organisationen den Vorsprung der Angreifer wieder einholen.