Poisoned PRs Let One AI Agent Control Another

Researchers found a real-world workflow flaw in Google’s Agent Development Kit (Python) repo where a low-privilege AI triage bot could be manipulated with prompt injection to trigger a higher-privilege maintainer agent. The attack uses “poisoned” pull requests to create a believable review/approval trail and potentially tamper with a supply-chain change. Google says it fixed the issue, but noted the scenario relies on social engineering and still requires a maintainer to merge.

Key findings

• Exploit described as a “real-world agent-to-agent exploitation method” where a lower-privilege agent can trigger a higher-privilege agent via prompt injection.
• Attack chain relies on “poisoned pull requests” and public CI/CD workflow details to cross an unintended trust boundary between two bots with different privileges.
• Workflow described uses two PRs: PR A (legit fix + malicious change) to get triaged, then PR B with prompt injection to trigger a trusted “@gemini-cli handoff” and privileged actions.
• Google stated the report showed GitHub token exfiltration with 'pull-requests: write' permission; however, a human maintainer still must merge the PR.
• Research highlights that bot/agent identity separation and resource access controls are needed, not just “agent isolation.”

Who’s being targeted

• Commonly targeted roles: Software engineering, Open source maintainers, DevOps / CI-CD teams, Application Security, Security leadership (CISO/VP Security).
• Affected industries: Software development, Open source software, DevOps / CI/CD, Technology vendors using AI agents.
• Attack channels: github.
• Impersonated: Trusted repository automation (triage bot / “@gemini-cli” maintainer workflow), Legitimate community contributor.

Awareness takeaways

• Treat PR text and issue comments as untrusted input for automation (including AI agents); don’t let them trigger privileged actions without strict controls.
• Require strong separation of identities and permissions between bots/agents, especially across CI/CD workflows.
• Don’t accept an “automated approval trail” as proof of human review; verify who actually approved and what was executed.
• Flag contributor trust-building followed by a risky change (dependencies/config) as a supply-chain warning sign; apply extra review steps.

Red flags to watch for

• A new contributor tries to force a specific bot/agent handoff (e.g., explicitly calling “@gemini-cli”).
• PR text contains instructions aimed at automation rather than humans (prompt-injection style directives).
• A believable automated approval trail appears without a real human review.
• PR includes unrelated build/dependency changes (e.g., package.json) alongside a small code fix.
• Contributor’s change history appears designed to “build trust” before a risky change.
• Reviewer relies heavily on automated agent feedback instead of verifying the actual diff.