A first practical, real-world case of agent-to-agent exploitation inside a production multi-agent system, a novel attack class that turns one AI agent against another to compromise a software supply chain.
The flaw was found in google/adk-python, the repository behind Google’s Agent Development Kit for Python, an SDK widely used by developers to build their own AI agents.
The adk-python repository ran two tiers of automated AI agents. A low-privileged agent handled public-facing interactions, triggered whenever a user opened a pull request or issue, while a high-privileged agent was reserved for trusted maintainers with real authority over the codebase.
Pillar’s researchers discovered that the low-privileged, internet-exposed agent could be manipulated through prompt injection to reach across this boundary and invoke the high-privileged agent on its behalf.
AI Agent Against Its Own CI/CD Pipeline
The chain began with an agent called adk_pr_triaging_agent, which was tied to a human-style collaborator account rather than a scoped bot identity.
By crafting a pull request comment disguised as a legitimate contribution note, researchers tricked the triaging agent into posting a comment starting with “@gemini-cli,” which triggered the privileged gemini-invoke and gemini-review workflows. Because the agent commented using a real collaborator account, GitHub treated the trigger as coming from a trusted human.
From there, researchers found the extracted GitHub token, though narrowly scoped to issues and pull-request write permissions, was enough to edit other users’ comments, impersonate maintainers, and even trigger fake automated code reviews that displayed convincing “approved” markers.
Chained together, these primitives allowed an attacker to fabricate an entire believable approval trail on a malicious pull request without any human ever actually reviewing it.
Days after initial disclosure, Google added new Antigravity SDK-based automation to the same repository, which introduced a fresh vulnerability. A command allowlist meant to restrict the agent to safe “git” and “gh” operations could be bypassed using git’s own scripting features, such as hooks and shell aliases, effectively granting remote code execution on the CI runner.
Because the runner held a long-lived personal access token and Google Cloud service account credentials, an attacker who simply opened a GitHub issue, no privileged access required, could potentially exfiltrate sensitive secrets from the pipeline.
Google confirmed the findings and hardened the adk-python repository, though it did not classify the social-engineering-dependent supply chain scenario as reward-eligible since a maintainer action was still technically required to merge malicious code. Pillar Security received an honorable mention for the disclosure.
The broader takeaway for security teams is that agentic AI workflows introduce a new category of attack surface that traditional threat models were never built to address.
Any AI agent that ingests untrusted text, such as issues, pull requests, or support tickets, while holding credentials should be treated as a potential attacker-controlled entity.
Experts recommend giving agents narrowly scoped, auditable identities instead of tying them to personal access tokens, enforcing strict tool allowlists, and preserving human guardrails like branch protection and mandatory code review to prevent a single compromised agent from cascading into a full supply chain breach.
Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.
