Gemini agent-to-agent handoff crossed a CI/CD privilege boundary

Pillar Security has disclosed a vulnerable automation pattern in Google’s Python Agent Development Kit repository. A public-facing issue and pull-request agent could pass user-controlled instructions to a more privileged Gemini workflow. Untrusted PR data thereby became control input for an agent with MCP tools, shell access and a GitHub token.

Google hardened the automation after disclosure and fixed a later, separate issue in late July. The lesson is broader than one repository: an agent-to-agent handoff is a trust-boundary call, not merely a conversation between two models.

How the escalation path formed

Pillar Security’s account identifies two automation tiers. A triage agent accepted user content and commented on pull requests with Collaborator permissions. Other workflows, invoked through @gemini-cli, were intended for maintainers and held much stronger tools.

The researcher caused the first agent to post a special comment that triggered gemini-invoke. Its response exposed the tools available to the privileged agent through MCP, including unrestricted bash execution. That created a path to environment secrets and the GitHub token.

According to the researcher, the resulting permissions could modify comments, issues and pull requests, dismiss reviews, trigger further analysis, and create a convincing but false approval history. A malicious PR still required a human to merge it, so part of that scenario depended on social engineering. That constraint reduces exploitability but does not repair the privilege-boundary failure.

Pillar later found a second issue in Antigravity SDK-based automation that could lead to code execution without maintainer interaction. Google fixed it in late July.

A model is not an authorisation mechanism

The architecture fails when it assumes the agent will infer the “safe intent” of a forwarded message. An LLM processes text as context; it is not a reference monitor. If a low-privilege agent can generate the format that activates a high-privilege workflow, data changes trust level without cryptographic or programmatic evidence.

This resembles a classic confused deputy. A privileged component performs an operation for a source it should not trust. MCP and tool calling increase the consequences because model output can become a command for a shell, repository or cloud environment.

Secure design for CI/CD agents

• Do not let text generated by a public agent independently trigger privileged workflows.
• Carry source identity and trust level as immutable metadata outside the prompt.
• Use separate least-privilege tokens for triage, review, labels and merge; no agent should receive “every bash command”.
• Validate allowed actions with deterministic code and policy after model output.
• Require fresh, explicit human approval for code changes, secrets and publication—not approval reconstructed from an editable comment.
• Isolate runners, restrict networking and secret mounts, and issue tokens only for a specific action.
• Log the provenance of every handoff, prompt, tool and decision in a record the agent cannot edit.
• Test indirect prompt injection in issues, commits, branch names, logs and tool output.

See our patterns for AI agent sandbox architecture and MCP security for implementation guidance.

Primary facts versus Breachroad analysis

Pillar Security documents the ADK repository demonstration, resulting capabilities and responsible disclosure. SecurityWeek reports that Google hardened the first mechanism and fixed the second issue. Public sources do not indicate that this chain was used to maliciously merge code.

Breachroad’s conclusion is to treat every agent-to-agent handoff as an API call requiring explicit authorisation. Secure AI implementation training helps teams design those boundaries, while AI red teaming can test indirect prompts, tools, tokens and escalation paths before production.