Google Pulled ADK Agent Workflows After Repo Bot Privilege Chain

TL;DR: Google removed three workflows from its ADK Python repo after Pillar Security showed that a public GitHub issue could steer a low-privilege triage agent into triggering a higher-privilege code-fixing agent. The important part is not the "first-ever" claim; it's that natural-language output became an authorization bridge inside CI.

Workflow chain

The vulnerable path started with issue-analyze.yml, a public-facing workflow that ran automatically on new issues. It authenticated with ADK_GCP_SA_KEY, passed ADK_TRIAGE_AGENT and GOOGLE_API_KEY into Google's Antigravity coding agent, then posted the result as a comment from adk-bot.

That comment mattered because a second workflow, issue-fix.yml, listened for /adk-issue-fix commands. Its gate was simple: only an owner, member, or collaborator could trigger the privileged workflow. On paper, that sounds reasonable. In practice, the researchers showed an outsider could prompt-inject the public agent into emitting /adk-issue-fix as adk-bot. Since adk-bot counted as a collaborator, the command passed the trust check.

That is the core failure: the workflow verified who posted the comment, not whether the content of that comment had been manipulated by untrusted input upstream.

Authorization bridge

This is why the story matters beyond one Google repository. The triage bot was not the final privileged actor. It became the bridge that transferred outside influence into a trusted channel.

Security teams usually model permissions at the identity level: service account A can do X, bot B can do Y, workflow C has repo write access. That model misses the real path here. The path was event-driven and linguistic:

1. outsider opens issue
2. public agent reads issue
3. public agent posts trusted comment
4. trusted comment triggers privileged workflow
5. privileged workflow runs with stronger credentials

Nothing in that chain requires a classic auth bypass. The permissions were technically working as configured. The weakness came from how authority moved between components.

Pillar's framing is useful here: inventory tells you what identities and tools exist; delegation mapping tells you what can happen when one system's output is trusted by another.

Runner exposure

The impact was not theoretical. Pillar demonstrated arbitrary code execution on the CI runner and exfiltration of the bot PAT. The privileged job also carried a Google API key and a Google Cloud service-account credential.

There are still important limits in the public record. Pillar did not report in-the-wild exploitation. It did not identify a compromised ADK release. And the exposed target was the repository automation, not the shipped ADK Python package itself.

That distinction matters. This was a repo and CI trust problem with supply-chain implications, not evidence that end users pulled a backdoored package.

Tooling gap

One subtle detail makes this case stronger. The runner rejected shell metacharacters and only allowed commands whose first token was gh or git. That sounds like a decent containment layer. It wasn't enough.

The workflow also enabled a capabilities configuration that turned on all Antigravity tools, including writes. Combined with a command allowlist, file writes plus Git were sufficient for code execution.

This is a recurring problem in agent security reviews: controls are evaluated one by one, while attackers chain them. "Only git and gh" is not a meaningful boundary if the agent can also write files and reconfigure how those tools behave.

Scope uncertainty

Some parts remain unknown. The PAT's exact scopes were not public. Public artifacts do not show whether it could push directly to main. Google reportedly told Pillar that the service account had Vertex AI access in a dedicated GitHub-management project, but broader cloud permissions were not disclosed.

So the confirmed blast radius is runner execution plus credential exposure. The downstream repository and cloud reach of those credentials is less clear from public evidence.

That uncertainty should temper the claims. There is enough here to call the design unsafe. There is not enough public evidence to map the maximum possible damage with precision.

Google response

Google removed issue-analyze.yml, issue-fix.yml, and pr-analyze.yml. The removal commit explicitly said the workflows processed untrusted issue and pull-request content with broad repository credentials. Pillar later verified the workflows were gone, and the repository currently does not contain those filenames in the main workflow directory.

The company's bug bounty panel reportedly treated the issue as non-rewardable for a payout because exploitation required a social-engineering element, though the researcher received an honorable mention. That classification may fit program rules, but it undersells the structural point. When natural-language input can move authority between bots, calling it "social engineering" risks minimizing a systems problem.

Builder implications

If you run agentic workflows in GitHub, Jira, support queues, or internal ops tooling, treat every agent output as potentially attacker-influenced if it touched untrusted input anywhere upstream. Do not let comments, summaries, labels, or generated PR text act as trust-bearing signals for more privileged automation without a second verifier that ignores agent-authored content. Map delegation paths, not just IAM roles: which agents read public data, which outputs trigger downstream jobs, and what credentials sit on those jobs. The practical move is simple: break the chain between untrusted language and privileged execution before your bot becomes someone else's collaborator.