Google Deletes 3 ADK AI Workflows After Malicious GitHub Issue Could Trigger Privileged Agent

Swati KhandelwalAug 04, 2026AI Security / DevSecOps

Google deleted three AI agent workflows from its Agent Development Kit (ADK) Python repository. Pillar Security showed that a public GitHub issue could manipulate a triage agent into triggering a privileged code-fixing agent.

The researchers said the public agent could be prompt-injected into posting /adk-issue-fix as adk-bot. They identified the bot as a collaborator, so that comment satisfied the privileged workflow's owner, member, or collaborator gate. The trusted bot identity became the authorization bridge.

The team demonstrated arbitrary code execution on the continuous integration (CI) runner and exfiltration of the bot personal access token (PAT). The privileged job also held a Google API key and a Google Cloud service-account credential. Its researcher-controlled proof-of-concept attacks do not identify in-the-wild exploitation or a compromised ADK release.

The exposed component was the repository automation, not a flaw in the distributed ADK Python package. For similar repositories, Pillar recommends separate bot identities, narrower token and tool scopes, and an authorization signal that untrusted text cannot generate.

The Hacker News contacted Google about the bot token's scopes, service-account permissions, and exploitation evidence, and Pillar Security about the proof-of-concept environment and credential access. Both responses were pending at the time of writing.

The attack path began in the public issue-analyze.yml workflow, which ran automatically whenever an issue was opened. It authenticated with ADK_GCP_SA_KEY, supplied ADK_TRIAGE_AGENT and GOOGLE_API_KEY to Google's Antigravity coding agent, and posted the generated analysis as a comment using the bot account.

A separate issue-fix.yml workflow listened for /adk-issue-fix comments and restricted execution to an owner, member, or collaborator. The gate checked who posted the command, not whether an outsider had manipulated the trusted account behind it.

The privileged job declared write access to issues, repository contents, and pull requests. Those settings applied to GitHub's generated GITHUB_TOKEN, not the ADK_TRIAGE_AGENT PAT the job actually used.

Pillar said the PAT's exact scopes were not public. The job checked out the repository with the PAT, authenticated to Google Cloud, and ran the agent with the PAT and API key in its environment. The workflow was designed to edit code, create an adk-bot fork, push a branch, and open a pull request. A bot-generated pull request from June 4 shows that the automation was operating in the repository.

The runner rejected shell metacharacters and allowed only commands whose first token was gh or git. But the script enabled CapabilitiesConfig(), which Google's Antigravity SDK documentation says turns on all tools, including writes. The agent could therefore write a payload and make an allowed Git command execute it through a custom hook path.

Git's documentation confirms that hooks are executable programs and that core.hooksPath can redirect Git to another directory. The allowlist narrowed command syntax, but file writes and Git still left a route to code execution.

Public artifacts do not establish whether the PAT could push directly to the main branch. Pillar said Google told it the service account had Vertex AI access in a dedicated GitHub-management project; broader permissions were not disclosed. Pillar's report describes runner execution and credential exposure, but the public record does not establish the downstream repository or cloud reach of those credentials.

The report also described an earlier chain that could create a false review trail through privileged Gemini workflows, but a maintainer still had to merge the pull request.

Google's removal commit says the workflows processed untrusted issue and pull-request content with broad repository credentials. Google deleted issue-analyze.yml, issue-fix.yml, and pr-analyze.yml in a patch whose metadata carries a June 9, 2026 author date.

Pillar said it verified the workflows were absent on July 2 and that Google confirmed the issue fixed on July 21. A check by The Hacker News on August 4, 2026, found none of the three filenames in the repository's current main-branch workflow directory.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.