Automated AI agents can speed up development work, but they can also introduce new attack paths—especially when agents can interact with each other and with version-control workflows. A recent disclosure by Pillar Security describes an agent-to-agent attack method in Google’s Agent Development Kit (ADK) for Python that could expose secrets and manipulate pull request (PR) processes.
The core issue revolves around how the toolkit separates agents by privilege level. In the affected setup, some agents were designed to be publicly reachable and user-facing, while more powerful agents were restricted to maintainers. The researcher demonstrated that an attacker could use the public-facing agent as a stepping stone to trigger actions in the higher-privileged workflow.
How the agent privilege boundary was bypassed
In the google/adk-python repository, two categories of AI agents were identified: lower-privileged agents that could be interacted with by users, and high-privileged agents reserved for maintainers. On paper, that division should reduce risk—public interactions shouldn’t be able to reach restricted capabilities like code execution.
However, the researcher found a way to manipulate the lower-privileged agent into passing a crafted prompt to the high-privileged agent. Once that handoff happened, the attacker gained access to restricted abilities, including command execution. That raised the stakes beyond a single compromised session, because it could potentially enable wider supply chain compromise through repository workflow manipulation.
A triage bot became a high-privilege collaborator
The investigation began when Pillar Security noticed an agent responsible for triaging pull requests. That agent was leaving comments on PRs with the role of a Collaborator, meaning it effectively had high permissions in the repository.
Next, the researcher identified a method to influence what the agent posted. By manipulating the agent, they could cause it to write an @gemini-cli <prompt> command as a comment on a PR. That action triggered gemini-invoke and, crucially, opened access to a more privileged workflow than the attacker started with.
This is where the agent-to-agent attack path becomes clear: the public-facing agent was steered to produce content that activated a higher-privileged automation pipeline.
Tool and command exposure through workflow leakage
After the crafted prompt triggered the relevant workflow, the response from the gemini_invoke.yml process revealed details about what the privileged agent could access. According to the report, the workflow leaked tool access via the MCP server.
The impact was concrete: the researcher observed that the privileged bot had access to essentially every bash command. With remote command execution capabilities, the attacker could potentially execute code and work toward extracting sensitive credentials, including the repository’s GitHub token.
Once a malicious actor can obtain a GitHub token and commands, the compromise can shift from “workflow abuse” to “repository control,” depending on what the token is allowed to do.
What PR tampering looked like in practice
The report describes a range of manipulations made possible once the attacker could act as the privileged automation and issue commands. The researcher claimed they could modify comments, PRs, and issues belonging to other maintainers, collaborators, and members.
Beyond editing content, the attacker could also influence review and validation outcomes. The described actions included dismissing reviews or approving PR changes, and invoking gemini-invoke and gemini-review against PRs—potentially turning automated assistance into an attack vehicle.
In other words, the automation that normally helps teams move fast could be repurposed to create a misleading approval trail and alter the PR approval lifecycle.
Why malicious code still required human trust
The scenario was not described as a fully automatic “merge without anyone noticing” attack. For a malicious PR to reach the codebase, the report states it would still need to be approved and merged by a repository member. That requirement introduces an additional barrier, but it also highlights a real-world security weakness: automation can generate the appearance of legitimacy, which can be exploited through social engineering.
The attacker model described in the disclosure involved earning trust as a collaborator, opening a PR containing harmful code for review, and then using a second PR to supply prompts that would instruct the agents to mark the first PR as triaged, reviewed, and approved.
Because the process could be made to look like “normal” agent activity, the human approval step could be manipulated—even though the underlying actions never truly occurred the way the trail suggests.
The mechanics behind the impersonation chain
The researcher summarized the chaining of permissions and actions as a coordinated use of repository capabilities. They pointed to primitives aligned with issue writing and pull request writing, tied to the actions performed by the automation.
In the report’s framing, editing the triager’s comment, posting and approving under the bot’s identity after extracting the GITHUB_TOKEN through remote command execution, and changing labels and review requests are all parts of a combined sequence. The end result is a believable audit trail—one that implies a human asked for a review and Gemini carried it out—despite the fact that the approvals were produced through an abusive path.
This detail matters because it shows the danger isn’t only about code execution; it’s also about workflow integrity—how trust is encoded into review systems.
Disclosure and remediation timeline
Pillar Security notified Google of the finding in early June. Google then addressed the issue through hardening measures. However, according to Pillar’s account, the submission did not meet the threshold for a bug bounty reward because the attack required social engineering to merge malicious PRs.
That doesn’t reduce the risk to zero. In practice, many compromises aim to influence human decision-making rather than fully bypass it. If the PR approval workflow can be shaped convincingly, attackers may only need minimal human interaction to reach their goals.
Shortly afterward, Pillar Security reported another weakness in the ADK repository. This second issue related to automation features based on the Antigravity-SDK-based agent and could lead to remote code execution without a maintainer’s interaction. Google fixed that separate vulnerability in late July.
Why this matters for agent-driven development
AI agents are increasingly embedded into day-to-day development workflows: triaging PRs, suggesting fixes, and helping with reviews. The disclosure underscores a recurring theme in agent security: once agents can take actions in shared systems, privilege separation must be robust against creative prompt- and workflow-based escalation.
Even when a high-privileged agent is not directly exposed, an attacker might still reach it indirectly—by manipulating the inputs, comments, or triggers used to activate automation. The agent-to-agent attack pattern described here is a reminder that “public-facing” does not automatically mean “harmless,” especially in systems that chain multiple automated steps together.
Takeaways for teams using agent automation
- Harden workflow triggers: Ensure that prompts or comments cannot safely escalate into privileged actions without strong verification.
- Audit agent permissions: If an automation bot holds collaborator-level rights, treat that as high risk and monitor its behavior closely.
- Reduce token impact: Limit what tokens can do and rotate credentials if command execution is ever plausible.
- Protect approval integrity: Add safeguards so review approvals reflect genuine review activity, not merely a fabricated trail.
While Google implemented hardening after the report, the broader lesson remains relevant: as agent capabilities expand, so must defenses against indirect privilege escalation and PR lifecycle manipulation.
Conclusion
Pillar Security’s research shows how an agent-to-agent attack in Gemini ADK Python could lead to secret exposure and PR tampering by leveraging public-facing agent interactions to trigger higher-privileged workflows. The findings highlight weaknesses in how automation can leak tool access and ultimately enable command execution, while the PR lifecycle abuse demonstrates how easily trust signals can be manufactured.
Google responded with hardening in early June and later fixed a separate remote code execution weakness. For developers adopting agent-driven automation, this disclosure is a clear prompt to strengthen privilege boundaries, audit permissions, and ensure that review and approval workflows remain trustworthy—even when agents are involved.
