Skip to content
Christopher Shaun Godwin cgodwin.io
Blog

One AI Agent Just Attacked Another: Inside Google's ADK Exploit

Christopher Shaun Godwin
Author

On August 3, 2026, Pillar Security published the first practical, real-world case of one AI agent attacking another (Pillar Security, 2026). The target was google/adk-python, the repository behind Google’s Agent Development Kit for Python. It is an open-source, code-first toolkit for building AI agents (Google, 2026). The repo has more than 90 million downloads (The Register, 2026).

The core breakdown

Section titled “The core breakdown”

The repository ran two classes of automated AI agents (Pillar Security, 2026). The first class was low-privilege and public-facing. It activated when a user opened a pull request or an issue. The second class was high-privilege and reserved for maintainers. It acted on the repository with real authority.

The vulnerability sat in the boundary between them. The low-privilege agent could be manipulated into triggering the high-privilege one (Pillar Security, 2026). The manipulation was prompt injection. The trigger was a trusted handoff between agents.

The attack ran in two pull requests (The Register, 2026):

  1. An attacker opened PR A with a real fix plus malicious code.
  2. A public-facing triage agent read PR A and marked it for review.
  3. The attacker opened PR B carrying the prompt injection.
  4. The triage agent emitted a trusted @gemini-cli handoff.
  5. The privileged workflow executed the malicious action.

The result was a fake audit trail. Researcher Dan Lisichkin described it as “a complete, believable ‘a human asked for a review, gemini ran it, gemini approved’ trail on the poisoned PR, none of which ever happened” (The Register, 2026).

Google fixed the underlying issue. It did not pay a bounty because the attack required social engineering, but it hardened the repository and will recognize the report with credit (The Register, 2026). Pillar confirmed the issue “has been mitigated” (Pillar Security, 2026).

Why CI/CD teams should care

Section titled “Why CI/CD teams should care”

The triage agent ran under a collaborator account with a personal access token, not under a bot identity (Pillar Security, 2026). That token carried pull-requests: write permission. A hijacked agent with that scope can edit comments, impersonate maintainers, and fabricate approvals on a malicious PR (The Register, 2026).

Lisichkin said agent isolation alone 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” (The Register, 2026). If Google had given the triage agent a bot identity, most of the attack could not have happened.

What to do about it

Section titled “What to do about it”
  1. Give every agent its own identity with scoped permissions.
  2. Model agent-to-agent boundaries in your threat model.
  3. Treat prompt injection as a supply-chain risk in CI/CD.
  4. Keep privileged agent workflows behind human approval.

The takeaway: AI agents in CI/CD are not just tools. They are principals with credentials. Attackers now know one agent can be used to compromise another. Plan for it before it happens in your pipelines.

Tags: