Critical Flaws in Google Cloud AI Let Attackers Hijack CI/CD Pipelines

Key Takeaways

• Researchers uncovered critical vulnerabilities in Google’s Agent Development Kit for Python (ADK), enabling novel agent-to-agent exploitation.
• The flaws could allow attackers to manipulate AI agents within Google Cloud’s CI/CD pipelines, potentially leading to supply chain compromise.
• The attack leveraged prompt injection and bypasses in command allowlists to achieve remote code execution and credential exfiltration.
• Google has acknowledged the findings and implemented fixes, although the initial social engineering aspect was not deemed bug bounty eligible.

Cybersecurity researchers have unveiled a groundbreaking attack methodology demonstrating the first practical agent-to-agent exploitation within a live multi-agent system. This novel attack class, discovered in Google’s Agent Development Kit (ADK) for Python, illustrates how one AI agent can be turned against another to compromise critical software supply chains.

The vulnerabilities were identified in the google/adk-python repository, which underpins Google’s ADK for Python – a software development kit widely adopted by developers for constructing their own AI agents.

The adk-python repository operated with a two-tiered system of automated AI agents. A low-privileged agent was designed to handle public-facing interactions, activating whenever a user submitted a pull request or opened an issue. In contrast, a high-privileged agent was designated for trusted maintainers, possessing significant authority over the codebase.

Researchers from Pillar Security successfully demonstrated that the internet-exposed, low-privileged agent could be manipulated through prompt injection techniques. This allowed it to bypass security boundaries and invoke actions typically reserved for the high-privileged agent.

AI Agent Against Its Own CI/CD Pipeline

The initial phase of the attack chain targeted an agent named adk_pr_triaging_agent. Crucially, this agent was linked to a human-style collaborator account, rather than a more secure, scoped bot identity.

By carefully crafting a pull request comment that appeared to be a legitimate contribution, the researchers tricked the triaging agent. This caused the agent to post a comment beginning with “@gemini-cli,” which subsequently triggered the privileged gemini-invoke and gemini-review workflows. Since the comment originated from a real collaborator account, GitHub processed the trigger as a trusted action from a human maintainer.

From this point, the researchers managed to extract a GitHub token. Although this token was narrowly scoped to issue and pull-request write permissions, it proved sufficient to edit comments made by other users, impersonate maintainers, and even initiate fake automated code reviews that displayed convincing “approved” markers.

When chained together, these individual primitives enabled an attacker to forge an entirely believable approval trail on a malicious pull request. This could occur without any actual human review, making it appear as if legitimate maintainers had sanctioned the changes.

Second Vulnerability Post-Disclosure

Within days of the initial disclosure, Google implemented new Antigravity SDK-based automation into the same repository, inadvertently introducing a fresh vulnerability. A command allowlist, intended to restrict the agent to safe “git” and “gh” operations, was found to be bypassable. This was achieved by leveraging git’s own scripting features, such as hooks and shell aliases, effectively granting remote code execution capabilities on the CI runner.

Because the CI runner possessed a long-lived personal access token and Google Cloud service account credentials, an attacker could potentially exfiltrate sensitive secrets from the pipeline. This could be initiated simply by opening a GitHub issue, requiring no prior privileged access.

Google has since confirmed the findings and hardened the adk-python repository. However, the company did not classify the social-engineering-dependent supply chain scenario as reward-eligible, reasoning that a maintainer action was still technically required to merge malicious code. Pillar Security received an honorable mention for their disclosure.

This incident underscores a critical insight for security teams: agentic AI workflows introduce an entirely new category of attack surface. Traditional threat models were not designed to account for the unique risks posed by interconnected AI agents.

Any AI agent that processes untrusted text—such as content from issues, pull requests, or support tickets—while simultaneously holding credentials, should be treated as a potential vector for attacker control.

What You Should Do

• Assign AI agents narrowly scoped, auditable identities instead of broad personal access tokens.
• Enforce strict tool allowlists to limit the commands an agent can execute.
• Maintain human guardrails, such as branch protection and mandatory code reviews, to prevent a single compromised agent from escalating into a full supply chain breach.
• Regularly audit AI agent configurations and their interactions within CI/CD pipelines.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.