Researchers at Pillar Security identified two vulnerabilities in the automation of the Google Agent Development Kit (ADK) for Python GitHub repository. These issues allowed an external attacker, via prompt injection, to force a low-privilege bot to launch a privileged workflow. The first scenario made it possible to forge the code review history, while the second enabled arbitrary code execution in the CI runner and extraction of secrets, including access tokens and cloud service credentials. According to the researchers, the problems did not affect the ADK Python package itself, but only the repository’s workflow configuration. Google has already fixed the vulnerabilities by removing the three problematic workflows.
Architectural issue: lack of isolation between agents
The root cause of both vulnerabilities lay in the repository’s automation architecture. According to researcher Dan Lisichkin, two classes of AI agents operated in the ADK repository. Low-privilege bots processed public issues and pull requests, while privileged agents — accessible only to maintainers — could execute commands, modify code, and work with secrets. The critical mistake was that these two groups were not properly isolated from each other: the actions of a low-privilege bot could trigger a privileged workflow.
First scenario: forging reviews via prompt injection
In the first described attack scenario, an attacker could open a pull request containing both a legitimate fix and malicious code, and then create a second pull request with a prompt injection. The initial review agent processed this request and posted a service command mentioning @gemini-cli in the discussion. Since the message came from a trusted account, it automatically triggered a privileged workflow.
According to the researchers, successful exploitation of this vector allowed an attacker to:
- Extract a GitHub token with extended permissions
- Manipulate comments, issues, and pull requests
- Dismiss others’ reviews and approve arbitrary changes
- Invoke Gemini for any pull request
- Create a completely forged code review history — simulating both a human review request and approval by Gemini
An important caveat: even if the attack succeeded, a maintainer still had to manually accept and merge the malicious pull request into the main branch. Thus, this scenario required an additional social engineering element — the fake review history served specifically to increase trust in the malicious code.
Second scenario: arbitrary code execution via adk-bot
The more dangerous attack vector involved a workflow based on the Antigravity SDK. A public agent automatically analyzed new issues and left comments on behalf of adk-bot, which had the collaborator role. Through prompt injection in the issue text, an attacker could force the bot to post the /adk-issue-fix command. Since the command originated from an account with the collaborator role, it passed validation and launched a privileged agent to fix the code.
The launched agent ran in an environment with access to the bot’s token, a Google API key, and Google Cloud service account credentials. As the researchers report, they demonstrated arbitrary code execution in the CI runner and extraction of the personal access token (PAT) used by the bot.
One aspect that deserves particular attention is the method used to bypass restrictions. The workflow attempted to limit the set of available commands, allowing only gh and git. However, the agent still had the ability to write files to disk. The researchers showed that it was possible to save a malicious payload to a file, specify a non-standard directory for Git hooks, and execute arbitrary code via the allowed git command — a classic example of bypassing an allowlist through side mechanisms.
Impact assessment
Exploitation status — a public PoC is available. The researchers emphasize that they did not find any compromised ADK releases or signs that these vulnerabilities were exploited in real-world attacks. Nevertheless, the potential impact was significant: compromising the CI/CD infrastructure of a major Google open-source project could have led to the insertion of malicious code into a codebase used by many developers.
This case is illustrative for the entire industry: as AI agents become more common in development workflows, the privilege boundaries between them are turning into a new attack surface. Prompt injection is moving from a theoretical threat to a practical tool for privilege escalation in CI/CD pipelines.
Mitigations and recommendations
Google engineers have already strengthened the repository’s security and removed the three problematic workflows: issue-analyze.yml, issue-fix.yml, and pr-analyze.yml. Users of ADK as a Python package do not need to take any additional action — the vulnerabilities did not affect the library code itself.
For teams using AI agents in their own CI/CD pipelines, researcher Dan Lisichkin formulated the following recommendations:
- Separate accounts — each bot should have its own account with the minimum necessary permissions
- Constrain tokens — limit token privileges to the bare minimum required for the specific task
- Do not trust commands automatically — the fact that a command comes from a bot does not make it trusted; independent validation is required
- Isolate privilege levels — actions of low-privilege agents must not be able to trigger privileged workflows
- Audit side capabilities — restricting the command list is useless if an agent can write files and use mechanisms such as Git hooks to bypass it
The discovered vulnerabilities highlight a fundamental problem: trust models designed for human interaction with CI/CD systems do not account for the specifics of AI agents that are susceptible to prompt injection. Teams implementing AI-driven automation in their development processes should audit privilege boundaries between agents and ensure that no publicly accessible bot can — directly or through a chain of calls — initiate privileged operations.
