Google dev kit spurs first-ever agent-on-agent violence - The Register

Security Google dev kit spurs first-ever agent-on-agent violence Poisoned pull requests contain prompt injection that allows one to control another Jessica Lyons Jessica Lyons Cybersecurity Editor Published mon 3 Aug 2026 // 21:30 UTC In what they call the first-ever real-world agent-to-agent exploitation method, Pillar Security researchers say they discovered an exploit in the repository behind Google's Agent Development Kit for Python that could allow attackers to compromise supply chains. In other words, now we know that one AI agent can be used to control and compromise another one that has more privileges. The security snafu existed in google/adk-python , an open source Python toolkit with more than 90 million downloads used to build and deploy AI agents. Google has since fixed the underlying issue in the repository but deemed the exploit non-rewardable because it involved social engineering. Even so, it illustrates the risks of using AI agents in CI/CD workflows for triage, pull request (PR) reviews, and discussions. REG AD It also shows how one AI agent could attack another in a production environment, according to Pillar’s Dan Lisichkin, who found and reported the vulnerability. REG AD “Our world is changing quickly, and new attack surfaces are not yet reflected in threat models because these attacks never could exist in the first place in the ‘pre-agent’ world,” Lisichkin said in a technical write-up published on Monday. He will also discuss the findings during a poster talk at DEF CON's AI Village on Friday, August 7 at 1600 PDT. “CISOs and security practitioners should start considering these scenarios, threat-modeling them, and calculating worst-case implications and blast radius,” Lisichkin wrote. The issue stems from the way that the repo ran two classes of automated AI agents with different privilege levels that unintentionally share a trust boundary. One is a low-privilege, public-facing AI agent activated whenever a user opens a pull request (PR) or issue, and a second is a high-privilege, maintainer-only agent. Pillar’s team found that the low-privilege, public-facing agent could be manipulated via prompt injection into triggering a maintainer-only agent that can execute malicious actions. “Because workflows that explain how these agents work behind the scenes are also public, any person could have connected the dots that one agent should be able - at least theoretically - to 'call' the other,” Lisichkin told The Register . "When it comes to building the attack, you just need to know English to build the prompt injection (or just ask an AI to do it for you)." There is one caveat: an attacker would first likely need to make legitimate contributions to the repository to build trust among the maintainers before moving on to prompt injection. But assuming someone was willing to put in the time, here’s how the attack would play out. First, an external user - this would be the attacker - creates a new PR. Lisichkin calls this PR A, and it combines a real fix with malicious code, such as a modified package.json or malicious dependency. REG AD Then, a public-facing agent tied to a high-privilege collaborator personal access token (PAT) reads the attacker’s PR text and marks the PR for review. This level of trust - the collaborator PAT - allows the attacker-generated text to trigger a gated workflow. Once the PR A triage happens, the attacker opens a second PR - PR B - with the prompt injection, and the triage agent emits the trusted @gemini-cli handoff. This triggers the privileged-agent workflow and executes the malicious action. “Strung together, they manufacture a complete, believable ‘a human asked for a review, gemini ran it, gemini approved’ trail on the poisoned PR, none of which ever happened,” Lisichkin wrote. Google did not respond to The Register ’s inquiries, but Lisichkin confirmed that the underlying issue was fixed. Still, his findings, Google said, “did not meet the bar” for a bug-bounty payout. “This report demonstrates exfiltration of a GitHub token with a 'pull-requests: write' permission, which enables tampering with a PR but still requires a maintainer to take an action to merge the malicious PR as PRs are not automatically merged after a bot review,” Google explained. “We don't reward vulnerability reports that require social engineering to enable a supply chain security compromise,” the rationale continued. “Nonetheless, we have taken an action to harden the repository so we will be recognizing this report with credit.” MORE CONTEXT Google's fix for critical Gemini CLI bug might break your CI/CD pipelines DEF CON bans Meta-style 'pervert glasses' Excuses like 'AI did it' don't exist in the eyes of the law Anthropic and OpenAI are competing to see whose agents can go rogue harder Lisichkin told us the research shows agent isolation is not enough. "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," he said. "In this case, if Google had just given a bot identity to the initial triaging agent, most of the attack could have been prevented. Security teams need to start modeling agent identity and agent resource access within their threat models."® ai and ml ai google security