Die kurze Antwort
Das Sicherheitsunternehmen Pillar Security hat eine Schwachstelle in der Automatisierung rund um Googles Open-Source-Agent Development Kit (ADK) für Python aufgedeckt: Ein öffentliches GitHub-Issue — von beliebigen Personen erstellbar — konnte einen niedrig-privilegierten Triage-Agenten per Prompt Injection dazu bringen, einen hochprivilegierten Code-Fix-Agenten aufzurufen. Das Ergebnis: beliebige Codeausführung auf dem CI-Runner sowie die Exfiltration des adk-bot-Tokens, eines Google-API-Schlüssels und eines Google-Cloud-Dienstkonto-Credentials. Pillar bezeichnet dies als den ersten praktischen, realweltlichen Fall von Agent-zu-Agent-Exploitation in einem produktiven Multi-Agenten-System. Google entfernte die betroffenen Workflows im Juli 2026; die Forschungsergebnisse wurden Anfang August veröffentlicht.
Die Geschichte geht über ein einzelnes Repository hinaus. Sie handelt von einem Design-Muster, das sich rasant verbreitet. Während Teams autonome KI-Agenten für Ticket-Triage, Pull-Request-Reviews und automatische Fixes einsetzen, kollabiert die Grenze zwischen „liest nicht vertrauenswürdigen Input" und „hält Produktions-Secrets" still und leise in einer einzigen automatisierten Kette — und Prompt Injection ist die Nutzlast, die diese Grenze überwindet.
Was Pillar Security herausgefunden hat
Das ADK ist Googles Framework zum Aufbau und zur Orchestrierung von KI-Agenten. Wie viele Open-Source-Projekte setzte auch das ADK-for-Python-Repository selbst Agenten ein, um seine eigene Wartung zu unterstützen. Forscher von Pillar Security analysierten die mit diesem Repository verknüpfte GitHub-Automatisierung und stellten fest, dass die Multi-Agenten-Workflows gegen das Projekt selbst gewendet werden konnten. Die Kernschwäche war kein Speicherfehler und kein fehlendes Patch — es war ein Vertrauensgrenzen-Versagen zwischen zwei Agenten, die niemals dieselbe Machtebene haben sollten.
Auf der einen Seite stand ein öffentlich exponierter Triage-Agent, dessen Aufgabe darin bestand, eingehende Issues und Pull Requests zu lesen — Inhalte, die jeder anonyme Nutzer verfassen kann. Auf der anderen Seite stand ein privilegierter Code-Fix-Agent, der auf Googles Antigravity-Coding-Agenten basierte, das Repository modifizieren konnte und mit Zugang zu Secrets ausgeführt wurde. Pillar zeigte, dass der erste Agent dazu gebracht werden konnte, den zweiten zu kommandieren. Da der Triage-Agent den Text eines GitHub-Issues als Anweisung behandelte, konnte ein Angreifer eine Direktive einbetten, die ihn veranlasste, als adk-bot einen Trigger-Kommentar zu posten und den privilegierten Fix-Workflow zu starten — als hätte ein vertrauenswürdiger Maintainer darum gebeten.
Wie ein Agent einen anderen übernahm
Der Einstiegspunkt war ein öffentlicher issue-analyze.yml-Workflow, der automatisch ausgeführt wurde, sobald ein Issue geöffnet wurde. Dieser Workflow authentifizierte sich mit einem Google-Cloud-Dienstkonto-Schlüssel (ADK_GCP_SA_KEY) und übergab einen Triage-Agenten sowie einen Google-API-Schlüssel (GOOGLE_API_KEY) an den Antigravity-Coding-Agenten. Mit anderen Worten: Eine Automatisierung, die für jeden anonymen GitHub-Nutzer erreichbar war, war bereits mit bedeutsamen Credentials verdrahtet.
Von dort aus demonstrierte Pillar die Eskalation. Per Prompt Injection eingebettete Anweisungen im Issue lenkten den niedrig-privilegierten Agenten dazu, den hochprivilegierten aufzurufen — die Forscher beschreiben es als das Posten von /adk-issue-fix als Bot —, was den Fix-Job mit erhöhten Berechtigungen startete. Unter Ausnutzung von Gits Fähigkeit, während dieses Jobs Code auszuführen, erreichte das Team beliebige Codeausführung auf dem CI-Runner und exfiltrierte das persönliche Zugangs-Token des Bots. Derselbe privilegierte Job enthielt auch einen Google-API-Schlüssel und ein Google-Cloud-Dienstkonto-Credential, sodass ein einziges präpariertes Issue zu Codeausführung und dem Zugriff auf mehrere aktive Secrets führen konnte. Pillar bestätigte die Entfernung der betroffenen Workflows am 2. Juli 2026; Google bestätigte einen Fix für das zweite Problem am 21. Juli 2026. Die Erkenntnisse wurden Anfang August veröffentlicht.
Warum das ein Muster ist, kein Einzelfall
Es wäre einfach, dies unter „Google hat einen Workflow falsch konfiguriert" abzuhaken und weiterzumachen. Das würde den eigentlichen Punkt verfehlen. Dieselbe Form taucht überall auf, wo ein niedrig-privilegierter Agent, der nicht vertrauenswürdige Inhalte konsumiert, direkt oder indirekt einen höher-privilegierten Agenten oder Job zum Handeln bringen kann. „Die Autorität eines Agenten sollte nicht nur an seinen zugewiesenen Tools gemessen werden, sondern auch an den höher-privilegierten Systemen, die sein Output auslösen oder beeinflussen kann", sagte Sanchit Vir Gogia von Greyhound Research gegenüber CSO Online — eine treffende Zusammenfassung des Problems der transitiven Autorität, das dieser Klasse von Bugs zugrunde liegt.
Prompt Injection ist der Enabler, weil natürlichsprachliche Anweisungen und Daten denselben Kanal teilen: Ein Agent kann nicht zuverlässig zwischen „analysiere diesen Bug-Report" und „analysiere diesen Bug-Report und starte dann den Fix-Workflow" unterscheiden. Ketten Sie zwei oder drei Agenten zusammen, und der Wirkungsradius entspricht nicht mehr den Berechtigungen des schwächsten Agenten — sondern der stärksten Berechtigung, die irgendwo nachgelagert erreichbar ist. Sakshi Grover von IDC Asia Pacific fasste die Schutzmaßnahmen in denselben Begriffen: Identifizieren Sie, welche Agenten nicht vertrauenswürdige Inhalte konsumieren, verfolgen Sie, ob deren Outputs höher-privilegierte Workflows auslösen können, und kartieren Sie die maximalen effektiven Capabilities der beteiligten Credentials.
Was das für US- und EU-Softwareteams bedeutet
Die meisten Teams pflegen kein Framework-Repository, aber sehr viele tun genau das, was diese Exploitation erst möglich machte: Sie richten Agenten auf GitHub-Issues, Support-Tickets, E-Mails oder Kundennachrichten aus und lassen diese Agenten nachgelagerte Automatisierungen anstoßen. Wenn ein Glied in dieser Kette Produktions-Secrets erreichen, Code deployen oder eine Änderung genehmigen kann, hat nicht vertrauenswürdiger Text einen Weg zu privilegierten Aktionen. Die unbequeme Version der Frage ist einfach: Wenn ein Angreifer in Ihr System schreiben kann — was ist die privilegierteste Aktion, zu der ein Agent in seinem Namen überredet werden könnte?
DACH-Markt: In Deutschland, Österreich und der Schweiz verschärft das neue KRITIS-Dachgesetz (Umsetzung von NIS-2) die Sicherheitspflichten für kritische Infrastrukturen und deren Softwarelieferketten — dazu zählen CI/CD-Pipelines, die in Produktion deployen. Das BSI empfiehlt im IT-Grundschutz (OPS.1.1.6 Software-Tests und Freigaben) ausdrücklich, automatisierte Build-Prozesse mit separaten Vertrauenszonen für privilegierte und nicht-privilegierte Akteure zu betreiben. Genau diese Grenze hat der Google-ADK-Angriff überwunden. Teams im DACH-Raum, die unter KRITIS-Dachgesetz oder DSGVO-Rechenschaftspflichten stehen, sollten die transitive-Autoritäts-Analyse ihrer Agent-Pipelines als Teil der Dokumentationspflichten für sichere Softwareentwicklung betrachten.
Für regulierte Branchen sind die Konsequenzen konkret. In FinTech, Zahlungsverkehr und Healthcare sind unbefugter Zugriff und Change-Control-Integrität geprüfte Pflichten unter Rahmenwerken wie SOC 2, DORA und dem EU AI Act — und „ein KI-Agent hat es getan" ist keine Verteidigung, wenn der Agent einen Dienstkonto-Schlüssel hielt. Die zusätzliche Komplexität liegt in der Nachvollziehbarkeit: Agentengesteuerte Aktionen können wie gewöhnliche Bot-Aktivität aussehen, sodass ein Kommentar, der einen privilegierten Job ausgelöst hat, in Ihren Logs überhaupt nicht auffällt. Agent-Output — Kommentare, Reviews, Workflow-Trigger — als sicherheitsrelevante Ereignisse zu behandeln und das Verhalten von Agenten mit derselben Sorgfalt zu validieren, die Sie auf ein Security-Audit privilegierter Automatisierung anwenden, ist nun Teil des verantwortungsvollen Umgangs mit Agenten.
So härten Sie ein Multi-Agenten-System ab
Sie müssen agentische Automatisierung nicht abschaffen, um auf diesen Befund zu reagieren. Sie müssen lediglich verhindern, dass ein Agent, der nicht vertrauenswürdigen Input liest, still die Privilegien eines anderen ausleiht.
- Agenten mit nicht vertrauenswürdigem Input isolieren. Jeder Agent, der Issues, Tickets, E-Mails oder Pull Requests von außerhalb Ihrer Vertrauensgrenze liest, ist selbst nicht vertrauenswürdig — lassen Sie seinen Output niemals automatisch einen höher-privilegierten Agenten oder Workflow aufrufen.
- Transitive Autorität kartieren. Erstellen Sie ein Diagramm, welche Agenten welche Jobs auslösen können, und berechnen Sie die maximale effektive Capability jedes Credentials in der Kette — nicht nur des Credentials, das ein Agent direkt hält.
- Secrets von nicht vertrauenswürdigen Pfaden fernhalten. Dienstkonto-Schlüssel, API-Schlüssel und persönliche Zugangs-Tokens dürfen sich in keinem Job befinden, den anonymer Input erreichen kann; schränken Sie jedes Token auf minimale Berechtigungen ein.
- Menschliche oder signierte Freigabe für privilegierte Aktionen fordern. Deploys, Merges und Secret-Zugriffe, die von einem Agenten initiiert werden, sollten eine Out-of-Band-Genehmigung erfordern, die nicht vertrauenswürdiger Text nicht fälschen kann.
- Freigaben an den exakt geprüften Code binden. Wenn sich das geprüfte Material nach der Freigabe ändert, muss die Freigabe invalidiert werden — eine Genehmigung für einen Diff darf nicht auf einen anderen übertragen werden.
- Agentenaktionen als Sicherheitsereignisse protokollieren. Behandeln Sie agentengesteuerte Kommentare, Reviews und Workflow-Trigger als auditierbare Ereignisse mit eigenständiger Protokollierung, damit ein bösartiger Trigger sichtbar wird, anstatt im Bot-Rauschen unterzugehen.
Das strategische Signal aus Pillars Arbeit ist präzise und nützlich: Multi-Agenten-Automatisierung verlagert das Risiko von den Berechtigungen eines einzelnen Agenten auf die stärkste Berechtigung, die über die gesamte Kette erreichbar ist. Teams, die das beim Design berücksichtigen — nicht vertrauenswürdige Leser isolieren, privilegierte Aktionen absichern und Agent-Output genauso überwachen wie menschliche Handlungen — erhalten die Hebelwirkung agentischer Delivery, ohne anonymen Fremden einen Weg zu ihren Produktions-Secrets zu öffnen.
FAQ
Was hat Pillar Security im Google-ADK-Repository gefunden?
Pillar Security stellte fest, dass die Multi-Agenten-Automatisierung im Open-Source-Repository von Googles Agent Development Kit (ADK) für Python gegen sich selbst gewendet werden konnte. Ein öffentliches GitHub-Issue oder ein Kommentar, der von beliebigen Personen verfasst werden kann, konnte einen niedrig-privilegierten, internetexponierten Triage-Agenten per Prompt Injection dazu bringen, in seinem Namen einen hochprivilegierten Code-Fix-Agenten aufzurufen. Die Forscher demonstrierten beliebige Codeausführung auf dem CI-Runner und die Exfiltration des persönlichen Zugangs-Tokens von adk-bot, während der privilegierte Job zudem einen Google-API-Schlüssel und ein Google-Cloud-Dienstkonto-Credential enthielt. Pillar bezeichnete dies als den ersten praktischen, realweltlichen Fall von Agent-zu-Agent-Exploitation in einem produktiven Multi-Agenten-System.
Wie funktionierte der Agent-zu-Agent-Angriff?
Der Angriff begann in einem öffentlichen Workflow issue-analyze.yml, der automatisch ausgeführt wurde, sobald ein GitHub-Issue geöffnet wurde. Dieser Workflow authentifizierte sich mit einem Google-Cloud-Dienstkonto-Schlüssel und übergab einen Triage-Agenten sowie einen Google-API-Schlüssel an Googles Antigravity-Coding-Agenten. Da der Triage-Agent den vom Angreifer kontrollierten Issue-Text als Anweisungen las, konnte er dazu gebracht werden, als adk-bot einen Trigger-Kommentar (etwa /adk-issue-fix) zu posten, wodurch der privilegierte Fix-Workflow gestartet wurde. Ein niedrig-privilegierter Agent, der ausschließlich nicht vertrauenswürdige Inhalte konsumierte, konnte so eine Vertrauensgrenze überwinden und einen hochprivilegierten Agenten mit Zugang zu Secrets und dem CI-Runner steuern.
Wurde die Google-ADK-Schwachstelle behoben?
Ja. Google entfernte die verwundbaren Workflows aus dem ADK-for-Python-Repository. Pillar bestätigte, dass die betroffenen Workflows am 2. Juli 2026 entfernt wurden; Google bestätigte einen Fix für das zweite Problem am 21. Juli 2026. Die Erkenntnisse wurden Anfang August 2026 öffentlich bekannt gemacht. Die entfernten Automatisierungen waren an Googles eigenem Repository gebunden, sodass die unmittelbare Exposition dieses Projekt betraf und nicht Anwendungen, die mit dem ADK gebaut wurden. Das Design-Muster, das den Angriff ermöglichte, ist jedoch in Multi-Agenten-Systemen weit verbreitet.
Bedeutet das, dass KI-Coding-Agenten unsicher sind?
Nein. Das Problem liegt nicht darin, dass Agenten grundsätzlich unsicher sind, sondern dass ein niedrig-privilegierter Agent, der nicht vertrauenswürdigen Input konsumiert, in der Lage war, einen hochprivilegierten Agenten mit Zugang zu Secrets auszulösen — ohne dass eine Grenze das Least-Privilege-Prinzip zwischen ihnen durchgesetzt hätte. Agentische Automatisierung bleibt für Triage, Review und Fehlerbehebung nützlich. Die Lehre lautet: Die echte Autorität eines Agenten umfasst jede höher-privilegierte Aktion, die sein Output auslösen kann. Diese transitiven Pfade müssen kartiert, isoliert und überwacht werden, statt als sicher angenommen zu werden.
Wie können Teams, die Multi-Agenten-Systeme entwickeln, sich dagegen schützen?
Behandeln Sie jeden Agenten, der nicht vertrauenswürdige Inhalte liest, selbst als vollständig nicht vertrauenswürdig, und lassen Sie seinen Output niemals automatisch einen höher-privilegierten Agenten oder Workflow aufrufen. Kartieren Sie die transitiven Autoritätspfade zwischen Agenten, damit Sie die maximale effektive Capability jedes Credentials in der Kette kennen. Halten Sie Secrets wie Dienstkonto-Schlüssel und persönliche Zugangs-Tokens aus Jobs heraus, die nicht vertrauenswürdiger Input erreichen kann, und schränken Sie Tokens auf das Minimum notwendiger Berechtigungen ein. Binden Sie Freigaben an den exakt geprüften Code und invalidieren Sie sie bei Änderungen. Protokollieren Sie agentengesteuerte Kommentare, Reviews und Workflow-Trigger als sicherheitsrelevante Ereignisse.
Quellen
The Hacker News — Google löscht 3 ADK-KI-Workflows nach Exploit durch bösartiges GitHub-Issue
The Register — Google Dev Kit verursacht erste Agent-gegen-Agent-Attacke
CSO Online — Google-ADK-Schwachstellen zeigen, was passiert, wenn KI-Agenten der falschen Nachricht vertrauen