Gemini Agent-to-Agent Attack: Leaking Secrets & Tampering in PRs

A new and highly dangerous Gemini agent-to-agent has been discovered by cybersecurity firm Pillar Security, targeting the Google Agent Development Kit (ADK) for Python. The attack allowed a malicious user to exploit a low-privileged agent to manipulate a high-privileged agent, leading to secret exposureandforged pull requests (PR). The discovery was described by The Register as “the world’s first true agent-to-agent exploit,” with serious implications for the security of the software supply chain.

See also: DAEMON Tools Supply Chain Attack: Government organizations targeted

The affected google/adk-python — an open-source Python toolkit for building and deploying AI agents with over 90 million downloads — used two classes of automated AI agents. The first class was low-privilege agents, accessible to external users via pull requests or issues. The second class was high-privilege agents, accessible only to repository maintainers. The issue was identified as the fact that these two classes inadvertently shared a common trust boundary, allowing the low-privilege agent to be used as a “bridge” to trigger the privileged workflow.

Pillar Security researcher Dan Lisichkin first discovered that the agent responsible for triaging pull requests was commenting on PRs as a Collaborator , meaning with high privileges in the repository. He then found a way to manipulate the agent to post a comment in the form of @gemini-cli , which enabled gemini-invoke and provided access to a more privileged workflow. The initial prompt triggered a response from the gemini_invoke.yml workflow , which leaked the tools that the privileged agent had access to via the MCP server .

How Gemini agent-to-agent attack works: Technical Details

This revelation showed that the bot had access to every bash command, which meant that the researcher could execute code remotely (Remote Code Execution) and potentially extract the GitHub token . According to Lisichkin, this allowed it to modify comments, PRs, and issues of other maintainers, collaborators, and members; reject reviews or approve changes to PRs; and trigger gemini-invoke and gemini-review against any PR. This also allowed the researcher to "poison" the PR approval cycle, although any malicious PR would eventually have to be approved and merged by a member, which required social engineering.

The attack scenario Lisichkin describes is particularly sophisticated: a malicious user would first have to build trust as a collaborator, then open a PR containing malicious code (along with a seemingly innocent fix), which would be marked for review. The malicious user could then open a second PR containing prompt injection, with instructions to the triage agent to mark the first PR as triaged, reviewed, and approved. As Lisichkin notes: “The triager’s comment processing uses primitive impersonation from issues: write; the bot publishing and approval uses the GITHUB_TOKEN extracted via RCE; the label and review-request changes fall under pull-requests: write. Together, they construct a complete, credible trail of ‘a human requested a review, Gemini ran it, Gemini approved it’ to the poisoned PR, none of which ever happened”.

See also: Supply Chain Attack: TeamPCP Targets Developer Tools

Gemini agent-to-agent attack: Wider Impacts and Related Incidents

The significance of this discovery goes far beyond a typical prompt injection in a chatbot. It is an agent-to-agent exploit chain that uses one automated agent to influence another with higher privileges. This is of particular importance for software supply chain security, asthe vulnerable workflow was located inside the repository and could affect actions during PR triage, dependency management, or other automations exclusively for maintainers. Related research published in July 2026 on Agent Data Injection (ADI) showed that structured data attacks succeed in 31% to 43% of cases across six models, while web-based attacks range from a third to 100% depending on the configuration.

Kaspersky reported prompt injection attacks against Gemini Assistant and Google Workspace with Gemini in 2026 , describing techniques such as indirect prompt injection, memory poisoning, delayed execution, and fake context alignment. In addition, another 2026 study described vulnerabilities in coding agents such as Claude Code , Codex , and Gemini CLI , with impacts ranging from remote code execution to supply chain attacks. It also reported the first documented case of agentic ransomware , where AI-assisted operators used AI tools during an attack and gained access to keys for OpenAI , Anthropic , DeepSeek , and Gemini in the victim’s environment.

Google was notified of the finding in early June and addressed the issue through hardening, but did not consider it worthy of a bug bounty, as it required social engineering to merge the malicious PR. Shortly thereafter, Pillar Security discovered a second vulnerability in the ADK repository, in the automation features of the Antigravity-SDK-, which could lead to Remote Code Execution without maintainer interaction. Google patched this vulnerability in late July.

Protection from Gemini agent-to-agent attack: Recommendations for Organizations

The cybersecurity community is converging on the conclusion that AI agents are vulnerable when operating on externally provided content and can perform actions with real privileges. To protect against such attacks, experts recommend the following: First, strictly separate trust boundaries between public agents and agents exclusively for maintainers, without allowing one agent to issue commands that another privileged agent will execute without independent verification. Second, treat all content visible to agents — including PR texts, issue content, comments, filenames, metadata, and handoff messages — as untrusted.

Third, require human approval for any action that changes secrets, merges code, modifies dependencies, or triggers privileged workflows. Fourth, validate structured inputs at the parser level, not just with model instructions, as ADI exploit the ambiguity between data and instructions. Fifth, minimize agent privileges so that public agents cannot reach maintainer-only capabilities, secrets, or actions that change the repository. Sixth, log and monitor agent handoffs to quickly identify suspicious cross-agent prompts, unusual PR triage paths, and unexpected tool usage. Finally, red-team agent workflows using prompt injection, metadata spoofing, and delayed-action scripts before deploying them to production.

See also: GitHub Actions: Supply chain attack steals CI/CD credentials

In conclusion, the discovery of Pillar Security is a significant milestone in AI agent security research. The fact that a toolkit with over 90 million downloads was vulnerable to such an attack highlights the need for more stringent security models in the design of multi-agent systems. As the adoption of AI agents accelerates in enterprise environments, understanding and addressing the risks associated with trust boundaries and agent privilege models becomes imperative for any organization that develops or uses automated AI agents in its workflows.