Security flaws in automated workflows in the GitHub repository for Google’s Agent Development Kit for Python could allow public-facing AI agents to trigger more privileged automation, opening one path to manipulate pull-request reviews and another to expose credentials, according to a report from Pillar Security.The first attack path involved a triage agent that analyzed pull requests submitted by external contributors. The agent posted its responses through adk-bot, an account with collaborator access to the repository. Pillar found that malicious instructions embedded in a pull request could induce the agent to post an “@gemini-cli” command, triggering a workflow intended for trusted users.That workflow could enable command execution inside its CI runner. Its GitHub token could not push code, but it had write access to issues and pull requests. Pillar said those permissions could be used to alter a maintainer’s comment, submit an approving review as github-actions[bot], and remove a legitimate review request, making a malicious pull request appear ready to merge.Pillar reproduced the first attack chain in its research environment. A maintainer still had to complete the merge, and the report said Google subsequently hardened the repository.The security firm also found a separate attack path in newer workflows built around an Antigravity-based agent. An attacker could place a prompt injection in a public issue and induce an analysis agent to post the command that started a fixing workflow reserved for trusted repository users.The fixing workflow attempted to limit the agent to Git and GitHub commands, but Pillar found that Git could still be used to launch arbitrary code. The researchers demonstrated that the adk-bot personal access token could be extracted from the runner to an attacker-controlled server, while a Google Cloud service account key was also available to the workflow.Pillar said it confirmed on July 2 that the affected workflows had been removed and that Google told the researchers on July 21 that the second issue had been fixed.Agent handoffs expose riskPillar described the findings as the “first practical, real-world case of agent-to-agent exploitation” involving a production multi-agent system.Sanchit Vir Gogia, chief analyst at Greyhound Research, said the underlying weaknesses were familiar, but their interaction required enterprises to reconsider how authority moves through agentic systems.“Natural language has joined the authorization path,” Gogia said. “That is the change worth reporting, not the ‘first-ever’ framing.”Gogia said an agent’s authority should be measured not only by its assigned tools, but also by the more privileged systems its output can trigger or influence.That broader reach should also shape how CISOs judge the severity of the risk, according to Sakshi Grover, senior research manager for IDC Asia Pacific Cybersecurity Services.“For CISOs, materiality should be determined by tracing three things,” said Grover. “First, which agents consume untrusted content such as pull requests, issues, emails, support tickets, or external documents? Second, can the output of those agents directly or indirectly trigger another agent or workflow with higher privileges? Third, what is the maximum effective capability of the identities, credentials, and tools involved?”Mapping transitive authorityExisting security tools may provide only a partial view of how authority moves between agents and workflows.Grover said IAM, PAM, CIEM, and application-security tools can expose individual identities, permissions, and unsafe workflow configurations, but may not recognize that those components form a single event-driven delegation path.“Inventory records what exists, while delegation mapping records what can happen,” Gogia said.Gogia added that security teams should follow external input from the point it reaches an agent through to any downstream system that acts on the result. The review should also account for handoffs embedded in shared workflow state, such as a comment that triggers a command.“The harder question is not whether Agent A can call Agent B but whether Agent A can alter anything Agent B already trusts,” he said.Human approval does not necessarily close that gap. Although the first attack path still required a maintainer to merge the pull request, the manipulated automation could influence the evidence presented to the maintainer.“An attacker needs no merge rights when it can manufacture the evidence that persuades someone else to merge,” Gogia said. He added that approval should bind an independently authenticated reviewer to the exact code or artifact examined. Any material change should invalidate that approval.Grover added that changes to reviews, comments, and approval states should also be treated as security events and exported to an independent logging system that the workflow’s own identity cannot alter.