In brief: Prompt injections in public pull requests and issues in Google’s ADK repository could cause agents to trigger privileged GitHub workflows, manipulating reviews and exposing credentials.
Security researchers at Pillar Security demonstrated two attack paths in the GitHub workflows of the Agent Development Kit (ADK) for Python, through which publicly accessible AI agents could trigger more privileged automations. Affected were pull request reviews as well as access to credentials.
In the first attack path, Pillar Security exploited a triage agent that analyzes pull requests from external contributors and posts responses via the “adk-bot” account – an account with collaborator access to the repository. Through manipulative instructions embedded in a pull request, the agent could be induced to post the command “@gemini-cli,” thereby triggering a workflow actually intended for trusted users. This workflow allowed command execution within the CI runner. While the associated GitHub token could not push code, it did have write permissions for issues and pull requests. According to Pillar, this made it possible to alter maintainers’ comments, submit an approving review as “github-actions[bot],” and remove a legitimate review request – causing a manipulated pull request to appear mergeable. Pillar reproduced this attack chain in its own test environment; a maintainer still had to manually complete the merge. According to the report, Google subsequently hardened the repository.
Pillar found a second, separate attack path in newer workflows built around an Antigravity-based agent. A prompt injection in a public issue could prompt an analysis agent to post the command that starts a fixing workflow reserved for trusted repository users. This workflow was intended to restrict the agent to Git and GitHub commands only, but Pillar showed that arbitrary code execution was nevertheless possible via Git. The researchers demonstrated that adk-bot’s personal access token could be extracted from the runner to an attacker-controlled server; additionally, a Google Cloud service account key was accessible to the workflow. On July 2, Pillar confirmed that the affected workflows had been removed; Google informed the researchers on July 21 that the second issue had been fixed.
Pillar describes the finding as the “first practical, real-world case of agent-to-agent exploitation” in a production multi-agent system. Sanchit Vir Gogia, Chief Analyst at Greyhound Research, classifies the underlying weaknesses as known, but sees their interplay as reason to reassess how authority flows in agent-based systems: “Natural language has become part of the authorization path.” Accordingly, an agent’s reach should be measured not only by its assigned tools, but also by which more highly privileged systems its outputs can trigger or influence.
Sakshi Grover, Senior Research Manager at IDC Asia Pacific Cybersecurity Services, recommends that CISOs determine the materiality of such risks by asking three questions: Which agents process untrusted content such as pull requests, issues, emails, support tickets, or external documents? Can the output of these agents directly or indirectly trigger another agent or workflow with higher privileges? And what is the maximum effective capability of the identities, credentials, and tools involved? According to Grover, existing tools such as IAM, PAM, CIEM, and application security tools can uncover individual identities, permissions, and insecure workflow configurations, but often fail to recognize that these components together form a single, event-driven delegation path. Gogia summarizes this: inventory documents what exists – delegation mapping documents what can happen. Security teams should trace external inputs from the point they reach an agent to every downstream action that can result from it.
Source: www.csoonline.com · Published August 4, 2026
Lumi AI News — AI-assisted curation pursuant to Art. 50 EU AI Act. Paraphrasing and classification by Lumi News Pipeline v1.8.3.