Google Agent Development Kit Exposed to First-Ever Agent-on-Agent Attack via Prompt Injection

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

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. 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. "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. 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." 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."®

Google Deletes 3 ADK AI Workflows After Malicious GitHub Issue Could Trigger Privileged Agent

Google deleted three AI agent workflows from its Agent Development Kit (ADK) Python repository. Pillar Security showed that a public GitHub issue could manipulate a triage agent into triggering a privileged code-fixing agent. The researchers said the public agent could be prompt-injected into posting as . They identified the bot as a collaborator, so that comment satisfied the privileged workflow's owner, member, or collaborator gate. The trusted bot identity became the authorization bridge. The team demonstrated arbitrary code execution on the continuous integration (CI) runner and exfiltration of the bot personal access token (PAT). The privileged job also held a Google API key and a Google Cloud service-account credential. Its researcher-controlled proof-of-concept attacks do not identify in-the-wild exploitation or a compromised ADK release. The exposed component was the repository automation, not a flaw in the distributed ADK Python package. For similar repositories, Pillar recommends separate bot identities, narrower token and tool scopes, and an authorization signal that untrusted text cannot generate. The Hacker News contacted Google about the bot token's scopes, service-account permissions, and exploitation evidence, and Pillar Security about the proof-of-concept environment and credential access. Both responses were pending at the time of writing. The attack path began in the public workflow, which ran automatically whenever an issue was opened. It authenticated with , supplied and to Google's Antigravity coding agent, and posted the generated analysis as a comment using the bot account. A separate workflow listened for comments and restricted execution to an owner, member, or collaborator. The gate checked who posted the command, not whether an outsider had manipulated the trusted account behind it. The privileged job declared write access to issues, repository contents, and pull requests. Those settings applied to GitHub's generated , not the PAT the job actually used. Pillar said the PAT's exact scopes were not public. The job checked out the repository with the PAT, authenticated to Google Cloud, and ran the agent with the PAT and API key in its environment. The workflow was designed to edit code, create an fork, push a branch, and open a pull request. A bot-generated pull request from June 4 shows that the automation was operating in the repository. The runner rejected shell metacharacters and allowed only commands whose first token was or . But the script enabled , which Google's Antigravity SDK documentation says turns on all tools, including writes. The agent could therefore write a payload and make an allowed Git command execute it through a custom hook path. Git's documentation confirms that hooks are executable programs and that can redirect Git to another directory. The allowlist narrowed command syntax, but file writes and Git still left a route to code execution. Public artifacts do not establish whether the PAT could push directly to the main branch. Pillar said Google told it the service account had Vertex AI access in a dedicated GitHub-management project; broader permissions were not disclosed. Pillar's report describes runner execution and credential exposure, but the public record does not establish the downstream repository or cloud reach of those credentials. The report also described an earlier chain that could create a false review trail through privileged Gemini workflows, but a maintainer still had to merge the pull request. Google's removal commit says the workflows processed untrusted issue and pull-request content with broad repository credentials. Google deleted , , and in a patch whose metadata carries a June 9, 2026 author date. Pillar said it verified the workflows were absent on July 2 and that Google confirmed the issue fixed on July 21. A check by The Hacker News on August 4, 2026, found none of the three filenames in the repository's current -branch workflow directory.