Google removes three ADK workflows after GitHub agent exploit chain
Google removed three AI agent workflows from the Agent Development Kit (ADK) Python repository after Pillar Security demonstrated that content in a public GitHub issue could manipulate a triage agent into activating a privileged code-fixing agent. The proof of concept achieved arbitrary code execution on a continuous integration runner and exposed credentials available to the job.
The deleted files were issue-analyze.yml, issue-fix.yml, and pr-analyze.yml. Google’s removal commit said the workflows processed untrusted issue and pull-request content while holding broad repository credentials. The commit metadata carries a June 9, 2026 author date; Pillar verified the files were absent on July 2 and said Google confirmed the fix on July 21.
How trusted automation became an authorization bridge
The public issue-analyze.yml workflow ran 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 published the generated analysis through the adk-bot account.
Pillar found that prompt injection could make the bot post the command /adk-issue-fix. A separate workflow listened for that command and allowed execution when its author was a repository owner, member, or collaborator. Because adk-bot was a collaborator, the generated comment passed the gate. The check established who posted the command, but not whether an outsider had manipulated that identity.
The pattern resembles agent use of exposed credentials against Hugging Face in showing how an agent can turn accessible secrets and delegated authority into an attack path.
Why the command allowlist did not contain the agent
The privileged workflow declared write access to issues, repository contents, and pull requests. Those permissions governed GitHub’s generated GITHUB_TOKEN, however, rather than the ADK_TRIAGE_AGENT personal access token used to check out the repository. The PAT’s exact scopes were not public.
The runner rejected shell metacharacters and accepted only commands whose first token was gh or git. Yet the script enabled CapabilitiesConfig(), which Antigravity SDK documentation says activates all tools, including file writes. The agent could write a payload and direct an allowed Git command to execute it through a custom hook path. Git supports executable hooks and permits core.hooksPath to point to another directory.
The proof of concept demonstrated runner execution and exfiltration of the bot PAT. The job environment also contained a Google API key and a Google Cloud service-account credential. Pillar said Google described the service account as having Vertex AI access in a dedicated GitHub-management project, but broader permissions were not disclosed.
Scope and business implication
The public evidence does not show exploitation in the wild, compromise of an ADK release, or whether the PAT could push directly to the main branch. The affected component was repository automation, not the distributed ADK Python package. A separate false-review chain described by Pillar still required a maintainer to merge the pull request.
Organizations operating similar repositories should separate bot identities, reduce token and tool scopes, and base privileged actions on authorization signals that untrusted text cannot produce. Command filtering is insufficient when an agent can write files and invoke extensible tools such as Git; workflow trust boundaries must account for both the displayed identity and the origin of its instructions.