More than 90 million downloads: that is how widely used the google/adk-python toolkit was when Pillar Security researchers found what they call the first-ever real-world agent-to-agent exploitation method — a chain that lets a low-privilege AI agent manipulate a higher-privilege AI agent and, in turn, perform malicious actions inside a repository’s workflows.
Pillar Security’s finding and public disclosure
Pillar Security researcher Dan Lisichkin published a technical write-up describing the discovery and confirmed to The Register that he reported the vulnerability to Google and that the underlying issue has been fixed. Lisichkin will also present the research at DEF CON's AI Village on Friday, August 7 at 1600 PDT. In his write-up he warned that "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."
How the agent-on-agent exploit worked, step by step
The vulnerability stemmed from a trust boundary that unintentionally existed between two classes of automated AI agents running in the repository. One was a public-facing, low-privilege triage agent that ran whenever a user opened a pull request (PR) or issue. The other was a maintainer-only, high-privilege agent tied to a collaborator personal access token (PAT).
Pillar’s sequence, as described by Lisichkin, unfolded like this:
- An external user creates PR A that mixes a legitimate fix with malicious changes (for example, a modified package.json or a malicious dependency).
- The public-facing triage agent, running with the collaborator PAT, reads the attacker's PR text and marks PR A for review — emitting a trust signal that a maintainer-level flow can accept.
- The attacker opens a second PR, PR B, containing a prompt injection that causes the triage agent to emit a trusted handoff (the trusted "@gemini-cli handoff" in Pillar’s description).
- The handoff triggers the privileged agent workflow, which then executes the malicious actions the attacker encoded through prompt injection.
Strung together, the chain "manufacture[s] a complete, believable ‘a human asked for a review, gemini ran it, gemini approved’ trail on the poisoned PR," Lisichkin wrote — a trail that never actually reflected human approval.
Built by Nubivance.
OSINTSights' secure edge-first architecture, AI content pipeline, and serverless ops are designed by Nubivance. We do this for clients too.
Talk to us →Limits of the attack and Google’s response
Pillar noted a pragmatic caveat: an attacker would likely need to build trust with maintainers first by contributing legitimate work before attempting the prompt-injection stage. Google also argued that the report did not meet its bug-bounty criteria because the exploit relied on social engineering.
According to Google, the 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 added, "We don't reward vulnerability reports that require social engineering to enable a supply chain security compromise," though it said it "have taken an action to harden the repository so we will be recognizing this report with credit." Pillar’s Lisichkin confirmed the repository hardening to The Register; Google did not respond to additional inquiries from The Register.
Technical takeaway: agent identity and isolation are not the same
Lisichkin emphasized that simple isolation of agents is insufficient. "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 wrote. He argued that if the initial triaging agent had been given a distinct bot identity — rather than operating through a collaborator PAT tied to a maintainer — "most of the attack could have been prevented."
The root problem was a shared trust boundary: public workflows and documentation made it possible to infer that one agent could call another, and the publicly visible triage logic let an attacker "connect the dots." Lisichkin warned practitioners to model how agents interact and which identities they use when accessing resources.
What this means for CISOs and security practitioners, and for open-source maintainers
- CISOs and security practitioners: Lisichkin advised they "should start considering these scenarios, threat-modeling them, and calculating worst-case implications and blast radius." The case shows that CI/CD workflows using AI agents for triage, PR reviews, and discussions introduce new attack surfaces that should be incorporated into threat models.
- Open-source maintainers: repositories that tie triage or public-facing agents to collaborator PATs risk creating a trusted handoff that can be weaponized. Pillar’s research suggests maintainers should harden repository workflows, assign explicit bot identities where appropriate, and evaluate what permissions agents hold.
The immediate, concrete outcomes in this instance were a repository hardening by Google and public credit for the report, a planned public walkthrough by the researcher at DEF CON, and a warning that agent-to-agent attacks — once impossible in a pre-agent world — are now feasible. The discovery reframes what a secure software supply chain must protect against: not just human attackers and malicious packages, but chains of automated actors that can be manipulated to do a maintainer's work for them.
