Google Threat Intelligence Group beschreibt in seinem AI Threat Tracker vom 8. September 2026 Angriffe, bei denen nicht nur AI als Werkzeug eingesetzt wird. Angreifer zielen zunehmend auf die AI-Infrastruktur selbst.
Dazu gehören laut GTIG proprietäre Modelle, Quellcode, Prompts, Skills, API-Zugangsdaten und Cloud-Ressourcen. Mandiant untersuchte im zweiten Quartal 2026 mehrere Vorfälle, bei denen solche Assets zusammen mit anderen Unternehmensdaten gestohlen wurden. Parallel beobachtete Google Kampagnen, bei denen kompromittierte Accounts und Cloud-Umgebungen für unautorisierte AI-Workloads oder groß angelegte Modellabfragen verwendet wurden.
Der Bericht stammt von Google und basiert auf eigener Threat-Intelligence- und Mandiant-Telemetrie. Er ist keine vollständige Statistik des gesamten Marktes. CSO griff die Befunde am 15. September auf und ordnete vor allem den Diebstahl von AI-Credentials, Modellen und Cloud-Ressourcen ein.
Ein AI-System hat mehr schützenswerte Assets als seinen API-Key
Bei einer klassischen SaaS-Anwendung gehören Secrets, Kundendaten, Quellcode und Produktionszugänge in das Threat Model. Ein AI-Produkt erweitert diese Liste.
GTIG nennt unter anderem Modellgewichte, Prompts, Skills, Forschungsergebnisse und die Infrastruktur, auf der Modelle ausgeführt werden. In einem untersuchten Vorfall bei einem Unternehmen aus dem Gesundheitssektor wurden neben Unternehmens- und Forschungsdaten auch proprietäre AI-Modelle entwendet. Bei einem Anbieter für AI-Mediengenerierung umfassten die gestohlenen Daten laut Google Quellcode, Prompts, Skills, Model-Skripte und Secrets.
Auch ein SaaS-Team ohne eigenes Frontier-Modell kann solche Assets besitzen. Ein RAG-Setup enthält interne Datenquellen und Retrieval-Logik. Ein Agent bildet über Tool-Definitionen und Policies Geschäftsprozesse ab. Ein Model Gateway hält Provider-Credentials und Nutzungsregeln. Eigene Prompts oder Skills können Teil der Produktlogik sein.
Diese Artefakte liegen häufig in Repositories, CI/CD-Systemen, Konfigurationsdateien oder Cloud-Accounts. Sie befinden sich damit in denselben Umgebungen, die bei normalen Softwareangriffen bereits interessant sind.
Gestohlene AI-Zugänge haben einen direkten Ressourcenwert
Ein API-Key zu einem leistungsfähigen Modell kann Datenzugriff ermöglichen und gleichzeitig bezahlte Rechenleistung freischalten.
GTIG beobachtet gestohlene Entwickler-Credentials, kompromittierte AI-Accounts und gekaperte Cloud-Infrastruktur. Google verwendet für die unautorisierte Nutzung fremder Cloud-Ressourcen für AI-Workloads den Begriff „LLMJacking“.
Ein geleakter Token kann damit Kosten erzeugen, Quotas aufbrauchen oder den Zugang zu automatisierten AI-Workflows öffnen. Für Model Gateways und Agentenplattformen reicht die Prüfung „Credential gültig“ deshalb nicht immer aus. Zugriffe können zusätzlich an Identität, Umgebung, Modell, Budget und erlaubte Operationen gebunden werden.
Quavon hat diese Richtung zuletzt bei Vercels Host-basierten Credentials und Tailscales Identitätsmodell betrachtet. Googles Threat-Daten zeigen die Gegenseite: AI-Credentials werden aktiv gesammelt und für weitere Workloads verwendet.
Distillation-Kampagnen überschreiten laut Google 100 Millionen Prompts
GTIG berichtet von koordinierten Distillation-Kampagnen gegen Googles Modelle, von denen einzelne mehr als 100 Millionen Prompts umfassten.
Dabei werden Fähigkeiten eines proprietären Modells über sehr viele Abfragen in Trainingsdaten für ein anderes System überführt. Das unterscheidet sich vom direkten Diebstahl von Modellgewichten. Die API bleibt technisch verfügbar, wird aber in einer Größenordnung und mit einem Zweck benutzt, den der Anbieter nicht vorgesehen hat.
Google beschreibt dafür verteilte Proxy-Infrastruktur und viele kompromittierte oder betrügerisch angelegte Accounts. Ein einfaches Rate Limit pro API-Key deckt ein solches Muster nur begrenzt ab, wenn eine Kampagne ihre Anfragen über viele Identitäten verteilt.
Für kleinere AI-SaaS-Produkte ist die Größenordnung eine andere, das Grundproblem bleibt ähnlich. Wenn ein wertvoller Workflow über einen öffentlichen Endpoint erreichbar ist, sollte Abuse Detection auch Muster über mehrere Accounts und Sessions hinweg berücksichtigen. Quotas und Exportgrenzen gehören dann zur Produktarchitektur, nicht nur zur Abrechnung.
Agentische Workflows reduzieren die menschliche Wartezeit im Angriff
Im selben Bericht beschreibt GTIG einen finanziell motivierten Angreifer, der nach einer kompromittierten Cloud-Umgebung ein autonomes Multi-Agent-System einsetzte. Google zufolge wurde eine groß angelegte Credential-Harvesting-Kampagne in weniger als sechs Stunden geplant, aufgebaut und ausgeführt.
Das Agentensystem soll während des Ablaufs Fehler selbst bearbeitet und mehrere Schritte ohne fortlaufende menschliche Steuerung koordiniert haben. Automatisierte Scans und Credential-Diebstahl sind nicht neu; die zusätzliche Fähigkeit liegt in der dynamischen Orchestrierung während des laufenden Angriffs.
GTIG schreibt zugleich, bislang keine vollständig autonomen Zero-Day-Angriffspipelines von Bedrohungsakteuren in freier Wildbahn beobachtet zu haben. Der Bericht belegt eine Entwicklung zu stärker agentischen Workflows, nicht den vollautomatischen Angriff auf beliebige Ziele.
Mehrere konkrete Fälle stützen damit die Aussage, dass AI Teile von Angriffen beschleunigen kann. Die weitergehende Behauptung, Angreifer ließen Frontier-Modelle bereits selbstständig neue Zero-Days finden und massenhaft ausnutzen, decken Googles veröffentlichte Beobachtungen nicht.
Agent-Konfigurationen werden Teil der Software-Lieferkette
GTIG beschreibt Angriffe auf Entwicklungsumgebungen, bei denen Dateien und Konfigurationen gezielt dort platziert oder verändert wurden, wo Coding-Assistenten und Agenten sie automatisch einlesen. Kontextdateien eines Agenten sind nicht nur Dokumentation, wenn sie spätere Tool-Aufrufe beeinflussen.
Repositories enthalten damit neben ausführbarem Code eine weitere Art von steuerndem Input. Workspace-Regeln, Agent-Konfigurationen, MCP-Server und Tool-Beschreibungen können beeinflussen, welche Aktionen ein Assistent beim Öffnen oder Bearbeiten eines Projekts ausführt.
Bei Reviews sollte deshalb nicht nur geprüft werden, ob neuer Code ausführbar ist. Änderungen an Agent- und Tool-Konfigurationen können ebenfalls Sicherheitswirkung haben. In automatisierten Coding-Workflows sollten solche Dateien denselben Herkunfts- und Review-Anforderungen unterliegen wie andere sicherheitsrelevante Konfiguration.
Viele Gegenmaßnahmen bleiben klassische Security-Arbeit: Secrets begrenzen, Rechte trennen, Builds nachvollziehbar machen, ungewöhnliche Nutzung erkennen und sensible Assets nicht unnötig in jede Runtime geben. Der Unterschied liegt in der Asset-Liste. Modellzugänge, Prompts, Skills, Agent-Konfigurationen und Compute-Quotas gehören bei produktiven AI-Systemen inzwischen ausdrücklich dazu.
Quellen
Google Threat Intelligence Group, 8. September 2026: https://cloud.google.com/blog/topics/threat-intelligence/from-prompting-to-autonomy-the-evolution-of-adversarial-ai
CSO Online, 15. September 2026: https://www.csoonline.com/article/4221307/threat-actors-are-coming-for-your-ai-assets-to-operationalize-their-use-of-ai.html