Prompt Injection Turns Google ADK Agents Against Each Other

A Python toolkit with more than 90 million downloads became the test case for what Pillar Security calls the first real-world agent-on-agent exploitation method.

The target was google/adk-python, Google’s open source Agent Development Kit for Python, used to build and deploy AI agents, according to The Register Security. Google has fixed the underlying repository issue, but the reported exploit matters because it shows a new failure mode: one AI agent can be manipulated into triggering another agent with greater privileges.

That’s the part developers should care about. A poisoned pull request is no longer just suspicious code. In an agentic workflow, it can become an instruction channel.

Why poisoned pull requests matter in Google Agent Development Kit workflows

Pillar researcher Dan Lisichkin found that the repository ran two automated AI agent classes with different privilege levels that crossed a trust boundary. One was a lower-privilege, public-facing agent activated when users opened a pull request or issue. The other was a higher-privilege, maintainer-only agent.

The exploit path depended on prompt injection in a pull request. The attacker’s text was read by the lower-privilege agent, which could then emit a trusted handoff to the higher-privilege agent.

“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 wrote.

That quote is the useful frame. This was not a classic malware dropper or a dependency confusion attack. It was a workflow trust failure. The dangerous input was ordinary-looking text in a place an agent was expected to read.

For teams already experimenting with AI reviewers, triage bots, and code assistants, the lesson is blunt: if agents can read untrusted repository content and then act with useful permissions, repository text becomes part of the attack surface.

For adjacent Google AI risk context, XOOMAR readers can also revisit AI Floods Chrome With 1,072 Security Bug Fixes in June and Google Earth AI Gets Yanked After Fake Map Backlash. Different systems, same pressure point: AI features are moving faster than the operational habits around them.

How a pull request becomes an instruction channel

A poisoned pull request, in this case, means a PR that mixes legitimate-looking code work with malicious instructions meant for an AI system processing it.

Pillar’s reported sequence had two pull requests. First, an external user opened PR A, combining a real fix with malicious code, such as a modified package.json or malicious dependency. Then the public-facing agent read the attacker’s PR text and marked it for review.

The key detail is the permission bridge. The agent was tied to a high-privilege collaborator personal access token, or PAT, which let attacker-generated text trigger a gated workflow.

Then came PR B, containing the prompt injection. The triage agent emitted a trusted @gemini-cli handoff, which triggered the privileged-agent workflow and executed the malicious action.

Lisichkin summarized the illusion this chain created:

“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.”

That’s why this is harder than normal PR hygiene. The exploit does not need the AI to be “evil.” It needs the AI to be obedient in the wrong context.

Where Google Agent Development Kit fits into the risk

Google Agent Development Kit is an open source, code-first Python framework for building, evaluating, and deploying AI agents. The project’s public GitHub materials describe ADK 2.0 as including a graph-based Workflow Runtime and a Task API for structured agent-to-agent delegation, including multi-turn task mode and task agents as workflow nodes.

Those features are not inherently unsafe. They are exactly why developers use agent frameworks: agents can perform work, pass tasks, and operate inside larger automated flows.

The risk appears when three conditions stack together:

Pillar’s finding is less an indictment of one framework than a warning about the pattern. Agent-on-agent compromise means one agent’s input or output influences another agent across a boundary that humans assumed was safe.

Lisichkin told The Register that the workflows explaining how the agents worked were public, which meant “any person could have connected the dots” that one agent might theoretically call the other. He added: “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).”

A real software team could reproduce the same failure pattern

Scenario analysis, not a reported Pillar incident: imagine a company runs one AI agent to triage incoming PRs and another agent to prepare release notes or deployment summaries after changes are approved.

An attacker submits a PR that contains malicious instructions in the PR text. The review agent reads it, treats part of the attacker’s language as task context, and produces a clean-looking review artifact. A second agent then trusts that artifact because it came from an internal workflow.

The human maintainer sees a normal chain of events unless logs, permissions, or policy checks expose the handoff.

That is the uncomfortable lesson from the Google Agent Development Kit case. The weakest point may not be the model itself. It may be the boundary between agents, especially when one agent’s output becomes trusted input for another.

Why old code security checks struggle here

Traditional checks are built to catch risky code behavior, suspicious dependencies, or known vulnerable packages. Prompt injection is different because the “payload” can be plain language placed where an agent is expected to read.

Human review may not be enough either. A maintainer can inspect the code diff and miss the operational meaning of text that only matters because an AI agent will process it.

Permissions sharpen the risk. A read-only agent can still create noise, but an agent that can approve reviews, change labels, trigger workflows, or write to pull requests becomes a better target.

Google’s bug-bounty response leaned on that distinction. The company said the report showed exfiltration of a GitHub token with “pull-requests: write” permission, which could enable PR tampering but still required a maintainer to merge the malicious PR. Google said it does not reward reports requiring social engineering to enable a supply-chain compromise, though it credited the report and hardened the repository.

How teams should harden agentic development workflows now

Lisichkin’s practical recommendation is identity. Agents should not just be generic bots sharing broad access.

“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.

That gives engineering teams a concrete checklist:

• Separate identities: Give each agent its own role, token, and permission set.
• Least privilege: Don’t let triage agents hold permissions meant for maintainers.
• Human gates: Require human approval for sensitive actions, especially merges, workflow triggers, and dependency changes.
• Trust boundaries: Treat PR text, issue text, and agent messages as untrusted input.
• Tool-use rules: Limit which tools an agent can call based on source, task, and context.
• Monitoring: Log when agents change labels, approve reviews, write PR comments, or call other agents.

The next test is whether software teams model agent behavior as part of CI/CD security, not as a productivity add-on. If Google Agent Development Kit can surface this class of failure in a high-profile open source repository, smaller teams should assume their own agent workflows need the same scrutiny before attackers do the modeling for them.

Impact Analysis

• The exploit shows that prompt injection can cross privilege boundaries between AI agents.
• Poisoned pull requests can become instruction channels, not just suspicious code submissions.
• Teams using AI reviewers and triage bots need new threat models for agentic workflows.