June 9, 2026: Google removed three AI-agent workflows from its Agent Development Kit (ADK) Python repository after security researchers at Pillar Security showed a public GitHub issue could be used to manipulate a triage agent into triggering a privileged code‑fixing agent.
How the automation chain allowed a privileged action
The chain began in a public issue-analyze.yml workflow that ran automatically when issues were opened. That workflow authenticated using ADK_GCP_SA_KEY, supplied ADK_TRIAGE_AGENT and GOOGLE_API_KEY to Google's Antigravity coding agent, and posted the agent's generated analysis as a comment using a bot account.
A separate issue-fix.yml workflow listened for the literal comment command "/adk-issue-fix" and restricted execution to an owner, member, or collaborator. Crucially, that gate checked who posted the command, not whether an outside actor had manipulated the trusted account that made the comment — creating an "authorization bridge" from untrusted issue text to a privileged workflow.
The privileged job declared write access to issues, repository contents, and pull requests. Although those settings apply to GitHub's generated GITHUB_TOKEN, the job in practice used an ADK_TRIAGE_AGENT personal access token (PAT) instead. 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 the automation executing in the repository.
How the researchers demonstrated code execution and what the runner allowed
Pillar Security's proof-of-concept showed arbitrary code execution on the continuous integration (CI) runner and exfiltration of the bot's PAT. The runner's script rejected shell metacharacters and permitted only commands whose first token was gh or git, but the workflow enabled CapabilitiesConfig(), which Google's Antigravity SDK documentation states turns on all tools, including write capabilities. That combination let an agent write a payload and invoke it via a Git hook path.
Git's own documentation confirms hooks are executable programs and that core.hooksPath can redirect Git to another directory, creating a route from allowed Git commands and file writes to code execution despite the command allowlist.
Built by Nubivance.
OSINTSights' secure edge-first architecture, AI content pipeline, and serverless ops are designed by Nubivance. We do this for clients too.
Talk to us →Credentials in the wild: PAT, Google API key, and service account
Pillar reported that the privileged job also contained a Google API key and a Google Cloud service-account credential. The exact PAT scopes were not public. The public artifacts do not establish whether the PAT could push directly to the main branch, and Pillar said Google told it the service account had Vertex AI access in a dedicated GitHub-management project; broader permissions were not disclosed.
While the proof-of-concept demonstrates runner execution and credential exposure, Pillar's researchers did not identify in-the-wild exploitation or a compromised ADK release. The public record therefore does not establish the downstream repository or cloud reach of the exposed credentials.
Pillar Security's recommendations and the response timeline
Pillar advised separating bot identities, narrowing token and tool scopes, and adopting an authorization signal that untrusted text cannot generate. The Hacker News contacted Google about the bot token's scopes, the service-account permissions, and evidence of exploitation, and reached out to Pillar Security about the proof-of-concept environment and credential access; both responses were pending at the time of reporting.
Google's removal commit 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 — issue-analyze.yml, issue-fix.yml, or pr-analyze.yml — in the repository's current main-branch workflow directory.
What this means for repository maintainers, CI owners, and security teams
- Repository maintainers should treat automation that processes untrusted issue or PR content as potentially authoritative only when the actor identity and token are not conflated; separating bot identities and avoiding authorizations based on text generated by untrusted agents are practical steps Pillar recommends.
- CI owners must limit token scopes and tool capabilities — avoid enabling blanket capabilities that turn on all write tools — and ensure workflows actually use the credentials and permissions documented for the GITHUB_TOKEN rather than substituting broader PATs without review.
- Security teams should review workflows that hold service-account keys or API keys and validate the downstream reach of those credentials; Pillar's demonstration shows how CI execution can expose tokens even when the distributed package itself is untouched.
At bottom, the exposed component was repository automation — not the distributed ADK Python package — and Google moved to delete the implicated workflows. Pillar's proof-of-concept did not identify active exploitation, but the record leaves open how far the revealed credentials might have reached in specific repositories or cloud projects. For now the simple, sober lesson is technical: authorization gates that trust a bot's visible comment can be an authorization bridge when that bot's identity is reachable from untrusted text.
