Google ADK Security Flaw Reveals First-Ever AI Agent-to-Agent Attack in Production Environment

First Real-World Agent-to-Agent Attack Surfaces in Google ADK

Pillar Security researchers uncovered what they describe as the first-ever real-world agent-to-agent exploitation method in the repository behind Google's Agent Development Kit for Python1

1

. The security flaw demonstrated how one AI agent could be weaponized to control and compromise another AI agent with elevated privileges, marking a watershed moment in understanding AI-driven automation risks. The vulnerable google/adk-python repository, an open source Python toolkit with more than 90 million downloads, is widely used to build and deploy AI agents across CI/CD environments1

1

.

Dan Lisichkin from Pillar Security, who discovered and reported the vulnerability, emphasized the unprecedented nature of these agent-to-agent attacks. "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 stated in a technical write-up1

1

. He plans to present the findings at DEF CON AI Village on Friday, August 7 at 1600 PDT1

1

.

How Low-Privilege AI Agents Manipulate Privileged Ones

The core security flaw stemmed from how the repository ran two classes of automated AI agents with different privilege levels that unintentionally shared a trust boundary1

1

. A low-privilege, public-facing triage AI agent activated whenever users opened pull-request reviews or issues, while a second high-privilege, maintainer-only agent operated with elevated permissions. The critical vulnerability allowed the public-facing agent to be manipulated via prompt injection into triggering the maintainer-only agent that could execute malicious actions1

1

.

Pillar Security found that malicious instructions embedded in a malicious GitHub issue could induce the triage agent to post an "@gemini-cli" command through the adk-bot account, which held collaborator access to the repository2

2

3

3

. This comment satisfied the privileged workflow's owner, member, or collaborator gate, effectively turning the trusted bot identity into an authorization bridge3

3

. The attack demonstrates how AI agents trust the wrong message when conventional identity controls fail to account for prompt injection vectors.

The Attack Chain and Privilege Escalation Path

The attack sequence required careful orchestration across multiple pull requests. An external attacker would first create PR A, combining legitimate code fixes with malicious code such as a modified package.json or malicious dependency1

1

. The public-facing agent, tied to a high-privilege collaborator personal access token (PAT), would read the attacker's PR text and mark it for review, allowing the attacker-generated text to trigger a gated workflow1

1

.

Once the PR triage occurred, the attacker would open a second PR containing the prompt injection payload. The triage agent would emit the trusted @gemini-cli handoff, triggering the privileged-agent workflow and executing the malicious action1

1

. This privilege escalation path manufactured a complete, believable trail suggesting human review and Gemini approval of the poisoned PR, none of which actually happened1

1

.

The privileged workflow enabled arbitrary code execution inside its CI runner2

2

3

3

. While the GitHub token lacked direct code-push permissions, it held write access to issues and pull requests, which could be exploited to alter maintainer comments, submit approving reviews as github-actions[bot], and remove legitimate review requests2

2

.

Credential Exposure and Supply Chain Compromise Risks

Pillar Security demonstrated that the privileged job exposed far more than repository access. The researchers achieved exfiltration of the bot personal access token (PAT), along with a Google API key and Google Cloud service-account credential3

3

. The privileged workflow authenticated to Google Cloud and ran the agent with the PAT and API key in its environment3

3

. According to Pillar, Google confirmed the service account had Vertex AI access in a dedicated GitHub-management project, though broader permissions were not disclosed3

3

.

The attack path exploited Git's hook mechanism to achieve code execution. While the runner rejected shell metacharacters and allowed only commands whose first token was specific Git commands, the script enabled unrestricted tool access, which Google's Antigravity SDK documentation confirms turns on all tools, including writes3

3

. The agent could write a payload and make an allowed Git command execute it through a custom hook path3

3

. This illustrates how agentic workflows can turn trusted repository signals into supply chain compromise vectors that conventional CI/CD controls may not reveal.

Google's Response and the Social Engineering Debate

Google fixed the underlying issue but deemed the exploit non-rewardable because it involved social engineering1

1

. The company explained that the report demonstrated exfiltration of a GitHub token with pull-requests write permission, which enables tampering with a PR but still requires a maintainer to merge the malicious PR, as PRs are not automatically merged after a bot review1

1

. "We don't reward vulnerability reports that require social engineering to enable a supply chain security compromise," Google stated, though the company did recognize the report with credit and hardened the repository1

1

.

Google deleted three AI agent workflows from its Agent Development Kit Python repository in response to the findings3

3

. The removal commit indicated the workflows processed untrusted issue and pull-request content with broad repository credentials3

3

. Pillar verified the workflows were absent on July 2, and Google confirmed the issue fixed on July 213

3

. The exposed component was the repository automation, not a flaw in the distributed ADK Python package itself3

3

.

Why Agent Isolation Alone Fails

Lisichkin argues that agent isolation is insufficient to prevent these emerging threats. "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 explained1

1

. In this case, assigning a distinct bot identity to the initial triage agent could have prevented most of the attack1

1

.

For similar repositories, Pillar Security recommends implementing separate bot identities, narrower token and tool scopes, and authorization signals that untrusted text cannot generate3

3

. The research underscores that security teams must begin modeling agent identity and agent resource access within their threat models1

1

. "CISOs and security practitioners should start considering these scenarios, threat-modeling them, and calculating worst-case implications and blast radius," Lisichkin urged1

1

.

The attack required minimal technical sophistication. "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)," Lisichkin noted1

1

. While an attacker would likely need to make legitimate contributions first to build trust among maintainers, the low barrier to exploitation highlights the urgency of addressing these vulnerabilities as organizations increasingly deploy privileged AI agents in production environments.