Google removed three ADK AI workflows from the Agent Development Kit (ADK) Python repository. The trigger was a security issue investigated by Pillar Security: a public GitHub issue could be used to manipulate a triage agent, starting an agent with higher privileges.
One key detail: Google stated that this involved abuse within the repository automation process, not a vulnerability in the ADK library distribution itself. Still, the case makes clear how quickly “trusted” AI automation can go off the rails when authorization boundaries aren’t properly defined.
What Google removed: three AI workflows from ADK
According to the The Hacker News report, Google took down issue-analyze.yml, issue-fix.yml, and pr-analyze.yml. These workflows were part of the repository automation and processed untested input coming from issues and pull requests.
The removal was shipped in a patch whose metadata shows an author date of June 9, 2026. Pillar Security later confirmed the workflows were indeed no longer present, and Google confirmed the issue was resolved on July 21.
The heart of the abuse: prompt injection into a privileged agent
Pillar describes an attack path in which a public GitHub issue could send the triage agent to execute a command that normally should only be triggered from a trusted context.
Specifically: the public agent could be prompt-injected so that it posted a response in the form of /adk-issue-fix, as if it came from adk-bot. This worked because the bot identity was recognized as a collaborator.
This created an “authentication bridge”: the system did not validate the origin of the content in a way that excludes manipulation. Instead, it checked who posted the command—and in the proof of concept, that was the bot.
From triage to code fixing: why the gate failed
The issue-fix.yml workflow listened for comments containing the /adk-issue-fix command. Execution was then restricted to commenters who had a certain role (owner, member, or collaborator).
The problem was in how the gate was implemented: it mainly limited who could post the request, not whether that post was produced via manipulation of a trusted agent. In other words, the gate recognized the “trusted bot,” but it couldn’t prevent the command itself from being generated through prompt injection.
CI execution and token leakage in the proof of concept
Pillar demonstrated in a controlled environment that there could be arbitrary code execution on the CI runner. In addition, the publication describes that a personal access token (PAT) belonging to the bot could be exfiltrated.
The privileged job also had access to sensitive secrets such as:
- a Google API key
- a Google Cloud service account credential
The researchers also note that the PoC does not prove that abuse was already carried out in the wild, or that a published ADK release had been compromised.
Google also pointed out that, according to Pillar, the vulnerable component was in the repository automation. In other words: not in the shared ADK Python package, but in how GitHub workflows combined credentials and AI agents.
Where the attack started: issue-analyze.yml as the entry point
The attack path began with issue-analyze.yml. This workflow runs automatically when an issue is opened. In the described chain:
- the workflow used ADK_GCP_SA_KEY (service account key)
- it delivered ADK_TRIAGE_AGENT and GOOGLE_API_KEY to an “Antigravity coding agent”
- the generated analysis was posted as a comment using the bot account
A separate workflow, issue-fix.yml, then reacted to commands in those comments.
Why “GITHUB_TOKEN” vs the actual PAT caused confusion
According to the report, the privileged job had write permissions for issues, repository contents, and pull requests. This often leads people to think of the standard GitHub setup GITHUB_TOKEN—but the description states that the job actually used a different token, namely ADK_TRIAGE_AGENT PAT.
In other words: the permissions configured for the job did not necessarily correspond to the token the agent ultimately used. That makes it difficult to determine, based on workflow permissions alone, what impact a misuse scenario could have.
Token scopes were not public: still, a clear misuse model exists
Pillar notes that the exact PAT scopes were not publicly available. What is described, though, is that the job checked out the repository portion using the PAT, then performed authentication toward Google Cloud, and ran the agent with both the PAT and the API key in an environment.
The workflow was designed to modify code, create an adk-bot fork, push a branch, and then open a pull request.
This shows that the system could make changes on behalf of the automation. A bot-generated pull request (dated June 4) was cited as an indication that the automation was actually active.
Command allowlists weren’t enough: hooks and capabilities made it possible
The CI runner enforced restrictions: shell metacharacters would be rejected, and only commands were allowed whose first token was gh or git.
But Pillar shows that this syntactic allowlist didn’t provide full protection. A possibility is described in which the agent could enable “all tools” via the SDK CapabilitiesConfig(), including tools that allow writing.
It’s also relevant that Git supports hooks being executable programs. With core.hooksPath, Git can be redirected to a directory containing custom hook executables. That leaves a route to code execution open, even if only certain command formats pass the check.
What does this say about real exploits? Not proven yet
The publication also states that public artifacts don’t definitively show whether the PAT could push directly to the main branch. Pillar describes that Google said the service account had Vertex AI access in a specific GitHub management project, but broader permissions were not made public.
So the misuse model is concrete for the researchers’ environment, but the downstream impact (for example, exact repository and cloud reach) remains unclear in the public information.
Recommendations: separate bots, narrow scopes, and don’t treat AI input as an authorization signal
Google confirms not only the workflow removals; Pillar also provides recommendations for similar environments. The key points:
- Use separate bot identities for different roles and steps (triage versus fix).
- Limit token and tool scope to exactly what’s needed.
- Use an authorization signal that cannot be imitated by untrusted text (such as prompt-injected input generated by AI).
These lessons align closely with a broader theme in software supply chain security: automation should build in less “trust” than you might think—especially when AI agents can generate content that activates downstream flows.
Comparable risks in AI and security automation
If you look at other incidents involving AI workflows, you see the same pattern: the weakness often isn’t a single “bug,” but the chain that turns input into execution. The issue then lies in governance, authorization, and preventing unintended escalation.
That’s why it’s also useful to read how researchers approach AI agent governance, for example in AI agent governance with Obsidian Security. And if you’re interested in how supply-chain attacks via tooling actually work, see also malicious npm packages via supply chain.
Conclusion: the removal is a start, but the design must be revisited
Removing the ADK AI workflows is a clear step: Google responded to evidence that public input via GitHub automation could influence the activation of privileged code-fixing. At the same time, the case shows why “who posted the command” alone isn’t enough when an AI agent generates that command under manipulation.
For teams using AI automation in CI/CD and repository workflows, this is a warning. Use separated bot identities, minimal scopes, and authorization that can’t be traced back to signals formed from untrusted text. Only then can you prevent triage from turning into loss of control.
Source: https://thehackernews.com/2026/08/google-deletes-3-adk-ai-workflows-after.html
