Security researcher Dan Lisichkin of Pillar Security did something in Google's Agent Development Kit repository that had not been publicly demonstrated before: he used one AI agent to attack another one.
The setup is ordinary, which is what makes it worth reading about. The google/adk-python repository, a project the maintainers report at more than 90 million downloads, runs agents on its own pull requests. One of them is a public-facing reviewer that anybody's contribution can reach. It operates with a collaborator personal access token, which is to say a modest one. Another agent sits further in, with maintainer-level privileges.
The mechanism
A pull request is not just code. It has a title, a body, a diff, and comments, and all of that is text that an agent reads. Lisichkin put a prompt injection in that text. The low-privilege reviewer read it, and instead of only reviewing, it acted in a way that triggered the high-privilege agent.
Nothing was broken in the strict sense. Each agent did what it was built to do. The reviewer read untrusted input, because that is its job. The second agent trusted a signal coming from inside the repository, because inside the repository is supposed to be safe. What nobody had written down is the boundary between the two, and an unwritten boundary is not enforced.
Google patched it and refused to pay
This is the part worth sitting with, because both sides have a real argument.
Google fixed the issue. Google also declined the bounty, saying it does not reward vulnerability reports that require social engineering to enable a supply chain security compromise, and pointing out that a maintainer still has to click merge, since pull requests are not merged automatically after a bot review.
That is not a dodge. It is factually correct: the chain only completes if a human accepts a malicious pull request. Plenty of severity scales, reasonably, discount findings that need a human to cooperate.
The researcher's counter is also correct, and it is about design rather than severity. His position, in his own words, is that agents should have their own identity, which mandates what resources they are allowed to access and in what they are allowed to interact with these resources. An agent that borrows a human's token inherits a human's permissions, and no review step compensates for that.
You do not have to pick a winner. The honest reading is that this specific exploit needed a human mistake, and the architecture it exposed does not need one to be a problem next time.
Why "a human still has to merge" ages badly
Requiring a maintainer to merge is a real barrier today. It is a barrier that the entire industry is currently working to remove.
The direction of travel in agentic development is fewer human checkpoints, not more. Every auto-merge rule, every "the bot approved it so it goes in" policy, every pipeline where an agent's output feeds another agent without a person in between, removes exactly the step Google is counting on. The mitigation is organisational, and organisational mitigations decay.
What to do in your own repository
None of this requires Google's scale to apply. If you run agents on your repos:
- Give each agent its own identity. Sharing a personal access token between a human and a bot, or between two bots, means you cannot scope or revoke anything independently, and you cannot tell from an audit log who did what.
- Scope the token to the job. A reviewer needs to read a diff and write a comment. It does not need write access to branches.
- Treat everything an agent reads from outside as instruction-carrying. A pull request body from a stranger deserves the same suspicion as a form field on a public website. Our AI agent security guide covers the wider pattern.
- Do not let one agent's output be another agent's trusted trigger. If agent B acts on agent A's word, then whoever controls A's input controls B.
Do not confuse this with the litellm packages
A separate incident touches the same ecosystem and gets mixed up with this one. In March 2026, malicious versions of litellm, 1.82.7 and 1.82.8, were published to PyPI through compromised maintainer credentials, in a window of about three hours. Anyone installing google-adk with extensions during that window pulled them.
That is a classic dependency compromise: stolen credentials, poisoned package, short window. It has nothing to do with agents talking to each other. Both are supply chain incidents, but the defences are different, and treating them as one story means you will fix one and think you covered the other.
The takeaway
The finding is modest in immediate impact and large in what it signals. An agent is not a tool that runs when you press a button. It is an actor that reads, decides, and acts, and once you have two of them in the same repository with different privileges, you have a trust boundary whether or not you designed one.
Give agents identities before you give them permissions.
Sources
- Pillar Security research, reported by The Register, 3 August 2026.
