Was passiert, wenn KI-gestützte Code-Agenten nicht nur Aufgaben abarbeiten, sondern sich auch untereinander „weiterreichen“? Genau dieser Frage ist Pillar Security nachgegangen. Das Ergebnis: Ein Agent-zu-Agent-Angriff in der Python-Umgebung der Google Agent Development Kit (ADK) zeigt, wie sich eingeschränkte Agenten so manipulieren lassen, dass sie die Fähigkeiten höher privilegierter Workflows ausnutzen. Dabei waren nicht nur interne Werkzeuge betroffen, sondern auch der Pull-Request-Lifecycle — ein Risiko mit potenziellen Auswirkungen auf die Software Supply Chain.
Im Folgenden ordnen wir ein, wie die Methode funktioniert, welche Schwachstellen-Punkte Pillar beobachtet hat und warum die Fixes zwar erfolgten, die Bewertung als Bug-Bounty-Fall jedoch am Bedarf nach Social Engineering scheiterte.
So war das Agent-System in ADK-Python aufgeteilt
Im google/adk-python-Repository beschreibt das ADK zwei Typen automatisierter KI-Agenten. Auf der einen Seite stehen niedrig privilegierte Agenten, die öffentlich zugänglich sind und Interaktionen durch Nutzer erlauben. Auf der anderen Seite gibt es hoch privilegierte Agenten, die nur für Maintainern erreichbar sind.
Die entscheidende Idee hinter dem Angriff: Wenn ein Angreifer einen öffentlichen Agenten so beeinflussen kann, dass er einen Prompt an den höher privilegierten Agenten übergibt, können die sonst geschützten Aktionen „nachgeladen“ werden — inklusive mächtiger Funktionen wie dem Ausführen von Kommandos.
Erste Auffälligkeit: Bot-Kommentare mit hoher Berechtigung
Pillar identifizierte zunächst einen Agent, der Pull Requests triagiert. Dieser Agent kommentierte PRs offenbar als Collaborator. Das bedeutet: Der Bot verfügte über hohe Rechte im Repository. Diese Beobachtung ist wichtig, weil sie die Angriffsfläche beschreibt: Ein Agent mit weitreichenden Privilegien kann leichter in eine missbrauchsfähige Richtung gedrückt werden.
Prompt-Manipulation: Vom öffentlichen Agenten zum privilegierten Workflow
Anschließend fand Pillar einen Mechanismus, um den öffentlichen Agenten in eine bestimmte Richtung zu lenken. Konkret gelang es dem Forscher, dass der Agent einen Kommentar mit dem Format @gemini-cli <prompt> auf einem Pull Request veröffentlichte.
Dieser Kommentar löste dann einen Prozess aus: Er triggert gemini-invoke und damit einen Workflow, der auf einen privilegierteren Pfad zugreift. So wurde der Weg frei, um an Informationen zu gelangen, die der „öffentliche“ Agent normalerweise nicht sehen dürfte.
Leck über den MCP-Server: Tools und Shell-Fähigkeiten
Der erste Prompt führte zu einer Reaktion, die Details der privilegierten Umgebung sichtbar machte. Pillar beschreibt, dass der Workflow über einen MCP-Server die Tools preisgab, auf die der hoch privilegierte Agent Zugriff hatte.
Mit diesen Informationen wurde klar: Der Bot hatte Zugriff auf jeden Bash-Befehl. Damit war die Tür zu Remote Code Execution geöffnet — und damit auch zur Möglichkeit, den GitHub Token des Agents auszulesen.
Ein Token-Auslesen ist für Angreifer besonders kritisch, weil es die Umgehung von Berechtigungsprüfungen erleichtert. Danach kann ein Angreifer Aktionen ausführen, die normalerweise nur für den Bot-Account oder geschützte Rollen vorgesehen sind.
Was der Angreifer mit dem GITHUB_TOKEN anstellen konnte
Nachdem Pillar den Ablauf so rekonstruieren konnte, zeigte sich das Angriffspotenzial in mehreren Schritten. Laut Dan Lisichkin hätte der Forscher dadurch unter anderem die folgenden Aktionen durchführen können:
- Kommentare, Pull Requests und Issues anderer Maintainern, Collaboratoren und Mitglieder ändern
- Reviews ablehnen oder PR-Änderungen bestätigen
- gemini-invoke und gemini-review gegen beliebige Pull Requests auslösen
Übergeordnet geht es dabei um Manipulation des Vertrauensmodells. Wenn ein Bot so agiert, dass er Review-, Triaging- oder Approval-Schritte „herstellt“, wirkt die PR möglicherweise wie geprüft — obwohl das in Wahrheit nicht stattgefunden hat.
PR-Vergiftung: So entsteht eine glaubwürdige „Review-Historie“
Der Angriff ermöglichte es außerdem, den PR Approval Lifecycle zu vergiften. Der entscheidende Punkt: Damit eine bösartige PR tatsächlich in den produktiven Code gelangt, musste sie dennoch durch einen Menschen genehmigt und gemergt werden.
Diese Hürde bedeutet nicht, dass das Risiko gering wäre — sie verschiebt es. Pillar beschreibt, dass der Angreifer Social Engineering einsetzen muss: Er braucht zunächst Vertrauen als Collaborator, erstellt dann eine PR mit schädlichem Code für die Review, und anschließend eine zweite PR mit Prompts, die den Bot veranlassen, die erste PR als triagiert, reviewed und approved zu markieren.
Lisichkin fasst die Logik so zusammen: Durch das Editieren von Kommentaren ließen sich Aktionen über Rechte wie „issues:write“ sowie „pull-requests:write“ aneinanderketten. Ergebnis ist eine vollständige, für Menschen plausible Spur — „ein Mensch hat um eine Review gebeten, Gemini hat es ausgeführt, Gemini hat genehmigt“ — obwohl die entscheidenden Schritte nie real passiert sind.
Benachrichtigung und Fix: Hardening bei Google
Pillar meldete die Erkenntnisse Anfang Juni an Google. Laut Bericht wurde die Schwachstelle daraufhin durch Hardening behoben. Gleichzeitig bewertete Google den Fall nicht als förderfähig für eine Bug-Bounty-Zahlung: Für eine erfolgreiche Ausnutzung war weiterhin Social Engineering erforderlich, um die bösartige PR am Ende tatsächlich mergen zu lassen.
Weitere Schwachstelle im ADK-Repository: Remote Code Execution möglich
Nur kurze Zeit später fand Pillar eine zweite Schwachstelle im ADK-Repository. Dieses Mal lag der Fokus auf den Automationsfunktionen eines Agents, der auf dem Antigravity-SDK basierte.
Die Beschreibung deutet darauf hin, dass es möglich gewesen wäre, Remote Code Execution zu erreichen — und zwar ohne die Interaktion eines Maintainners. Google schloss diese Lücke Ende Juli.
Warum solche Angriffe für die Praxis relevant sind
Die gezeigte Angriffskette illustriert, wie gefährlich die Kombination aus KI-Agenten, automatisierten Workflows und starken Berechtigungen werden kann. Selbst wenn einzelne Teile eines Systems „nur“ Kommentare erstellen oder Triaging übernehmen, kann ein Zusammenspiel unerwartet eskalieren.
Für Teams, die KI-Agenten in Entwicklungsprozesse integrieren, folgt daraus vor allem: Automatisierung darf nicht automatisch „Privilegien erben“, nur weil ein Bot mit Kommentaren oder Prompts arbeitet. Außerdem sollte überprüfbar sein, ob eine Approval- oder Review-Aktion tatsächlich durch den vorgesehenen Mechanismus zustande kam — und nicht durch eine manipulierte Botspur.
Fazit: Der Agent-zu-Agent-Angriff zeigt Grenzen von Vertrauen
Der von Pillar beschriebene Agent-zu-Agent-Angriff macht deutlich, dass Sicherheitsannahmen schnell kippen können, wenn ein öffentlich erreichbarer Agent in der Lage ist, privilegierte Workflows indirekt anzustoßen. In der ADK-Python-Umgebung führte die Kette zu potenziellem Geheimnis-Leak und zur Vergiftung von Pull-Request-Entscheidungen.
Google reagierte mit Hardening und späteren Fixes, dennoch unterstreicht der Fall eine wichtige Lehre: Je stärker die Rechte automatisierter Agenten und je weiter die Verbindung zwischen Agenten und Review-Prozessen, desto sorgfältiger müssen Validierung, Berechtigungen und Nachverfolgbarkeit gestaltet werden.
