Der Sicherheitsforscher Dan Lisichkin von Pillar Security hat im Agent-Development-Kit-Repository von Google etwas gezeigt, was zuvor öffentlich noch nicht demonstriert worden war: Er benutzte einen KI-Agenten, um einen anderen anzugreifen.
Der Aufbau ist gewöhnlich, und genau das macht ihn lesenswert. Das Repository google/adk-python, das die Maintainer mit über 90 Millionen Downloads angeben, lässt Agenten auf den eigenen Pull Requests laufen. Einer davon ist ein öffentlich zugänglicher Reviewer, den jeder Beitrag erreichen kann. Er arbeitet mit einem Personal Access Token eines Mitarbeiters, also mit bescheidenen Rechten. Ein anderer Agent sitzt weiter innen, mit Maintainer-Rechten.
Der Mechanismus
Ein Pull Request ist nicht nur Code. Er hat einen Titel, einen Text, ein Diff und Kommentare, und all das ist Text, den ein Agent liest. Lisichkin platzierte eine Prompt-Injection in diesem Text. Der Reviewer mit niedrigen Rechten las ihn, und statt nur zu prüfen, handelte er so, dass der Agent mit hohen Rechten ausgelöst wurde.
Im engen Sinn war nichts kaputt. Jeder Agent tat, wofür er gebaut wurde. Der Reviewer las nicht vertrauenswürdige Eingaben, denn das ist seine Aufgabe. Der zweite Agent vertraute einem Signal aus dem Inneren des Repositories, denn das Innere gilt als sicher. Was niemand aufgeschrieben hatte, ist die Grenze zwischen beiden, und eine nicht aufgeschriebene Grenze wird nicht durchgesetzt.
Google hat gepatcht und die Zahlung verweigert
Bei diesem Punkt lohnt es sich zu verweilen, denn beide Seiten haben ein echtes Argument.
Google hat das Problem behoben. Google lehnte aber auch die Prämie ab, mit der Aussage, man belohne keine Schwachstellenmeldungen, die Social Engineering benötigen, um eine Kompromittierung der Lieferkette zu ermöglichen, und mit dem Hinweis, dass ein Maintainer weiterhin auf "mergen" klicken muss, da Pull Requests nach einer Bot-Review nicht automatisch zusammengeführt werden.
Das ist keine Ausrede. Es stimmt sachlich: Die Kette schliesst sich nur, wenn ein Mensch einen bösartigen Pull Request annimmt. Viele Schweregrad-Skalen stufen Funde, die die Mitwirkung eines Menschen brauchen, mit gutem Grund herab.
Die Erwiderung des Forschers ist ebenfalls richtig, und sie betrifft das Design statt den Schweregrad. Seine Position, in seinen eigenen Worten: Agenten sollten eine eigene Identität haben, die vorgibt, auf welche Ressourcen sie zugreifen dürfen und auf welche Weise sie mit diesen Ressourcen interagieren dürfen. Ein Agent, der sich das Token eines Menschen leiht, erbt die Rechte eines Menschen, und kein Review-Schritt gleicht das aus.
Man muss keinen Sieger küren. Die ehrliche Lesart ist: Dieser konkrete Exploit brauchte einen menschlichen Fehler, und die Architektur, die er offenlegt, braucht beim nächsten Mal keinen mehr, um ein Problem zu sein.
Warum "ein Mensch muss noch mergen" schlecht altern wird
Dass ein Maintainer mergen muss, ist heute eine echte Hürde. Es ist eine Hürde, an deren Beseitigung die ganze Branche gerade arbeitet.
Die Richtung in der agentischen Entwicklung geht zu weniger menschlichen Kontrollpunkten, nicht zu mehr. Jede Auto-Merge-Regel, jede Politik nach dem Muster "der Bot hat zugestimmt, also geht es rein", jede Pipeline, in der die Ausgabe eines Agenten ohne Menschen dazwischen einen anderen Agenten speist, entfernt genau den Schritt, auf den Google baut. Die Abhilfe ist organisatorisch, und organisatorische Abhilfen verfallen.
Was im eigenen Repository zu tun ist
Nichts davon braucht Googles Grössenordnung. Wenn du Agenten auf deinen Repos laufen lässt:
- Gib jedem Agenten eine eigene Identität. Ein Personal Access Token zwischen Mensch und Bot oder zwischen zwei Bots zu teilen heisst, dass sich nichts mehr unabhängig einschränken oder widerrufen lässt und dass ein Audit-Log nicht mehr verrät, wer was getan hat.
- Begrenze das Token auf die Aufgabe. Ein Reviewer muss ein Diff lesen und einen Kommentar schreiben. Schreibzugriff auf Branches braucht er nicht.
- Behandle alles, was ein Agent von aussen liest, als anweisungstragend. Der Text eines Pull Requests von einem Fremden verdient dasselbe Misstrauen wie ein Formularfeld auf einer öffentlichen Website. Unser Leitfaden zur Sicherheit von KI-Agenten behandelt das grössere Muster.
- Lass die Ausgabe eines Agenten nicht zum vertrauten Auslöser eines anderen werden. Wenn Agent B auf das Wort von Agent A hin handelt, dann kontrolliert B, wer A's Eingabe kontrolliert.
Nicht mit den litellm-Paketen verwechseln
Ein getrennter Vorfall betrifft dasselbe Ökosystem und wird oft mit diesem vermischt. Im März 2026 wurden über kompromittierte Maintainer-Zugangsdaten bösartige Versionen von litellm, 1.82.7 und 1.82.8, auf PyPI veröffentlicht, in einem Fenster von etwa drei Stunden. Wer in diesem Fenster google-adk mit Extensions installierte, zog sie sich.
Das ist eine klassische Kompromittierung einer Abhängigkeit: gestohlene Zugangsdaten, vergiftetes Paket, kurzes Fenster. Mit Agenten, die miteinander reden, hat das nichts zu tun. Beides sind Vorfälle in der Lieferkette, aber die Abwehr unterscheidet sich, und wer beides als eine Geschichte behandelt, behebt das eine und glaubt, das andere sei abgedeckt.
Das Fazit
Der Fund ist in der unmittelbaren Wirkung bescheiden und in dem, was er signalisiert, gross. Ein Agent ist kein Werkzeug, das läuft, wenn man einen Knopf drückt. Er ist ein Akteur, der liest, entscheidet und handelt, und sobald zwei davon mit unterschiedlichen Rechten im selben Repository sitzen, hat man eine Vertrauensgrenze, ob man sie entworfen hat oder nicht.
Gib Agenten Identitäten, bevor du ihnen Rechte gibst.
Quellen
- Forschung von Pillar Security, berichtet von The Register, 3. August 2026.
