Google ADK Agent-to-Agent Attack: Authority Moved with a Comment
A hidden instruction in a pull request could make Google ADK's triage agent invoke a more privileged workflow through a trusted bot account. The July 21 patch closed the repository path. The lasting security lesson is narrower: every relayed AI request needs authorization tied to its originating identity.
A hidden instruction in a GitHub pull request could make a low-privilege Google ADK triage agent post a command that activated a higher-privilege agent. The Register reported the mechanism on August 3, 2026, after Pillar Security disclosed the research. Google patched the repository on July 21 and removed three workflows. The important detail is the trust transfer: the second agent saw a command from a Collaborator account, while the original instruction came from untrusted pull-request content.
I want to separate the GitHub Actions flaws from the HTTP AI authorization lesson. The workflow permissions, local runner execution, and possible exposure of environment variables sit outside an AI policy gateway. The outbound model call is the relevant boundary. A relayed request should carry the authority of its originator, rather than inherit the relay agent's account.
The privilege path crossed two agents
Pillar Security examined the public google/adk-python repository. According to SecurityWeek's August 2026 account, the public-facing adk_pr_triaging_agent operated through the adk-bot account with Collaborator privileges. Two workflows, gemini-invoke.yml and gemini-review.yml, responded when a Collaborator posted a comment beginning with @gemini-cli.
That arrangement created a message bridge. Untrusted text entered through a pull request. The triage agent interpreted hidden instructions and posted the trigger phrase under adk-bot. A more privileged workflow then treated the bot's comment as authorized input. On screen, the dangerous line looked like an ordinary GitHub comment beneath a pull request. Its visible author carried more trust than the instruction's real source.
The Hacker News described Google's removal of three ADK workflows in August 2026. Pillar called the technique a real-world agent-to-agent exploitation method. That characterization belongs to the researcher; the authorization failure stands on its own.
Account identity hid instruction provenance
GitHub knew which account posted the comment. The privileged workflow could therefore authenticate adk-bot as a Collaborator. That answer was accurate and incomplete. The workflow still needed the identity and authority attached to the instruction that caused the bot to act.
This distinction is the operational heart of agent-to-agent authorization. A relay agent can authenticate successfully while carrying a request created by an untrusted user, document, repository issue, or another agent. If the next hop evaluates only the relay's service identity, privilege expands silently. The message becomes a borrowed badge.
A defensible delegation record for the July 2026 ADK path would include the pull-request actor, the triage agent, adk-bot, the invoked workflow, the requested operation, and the policy that permitted the hop. The privileged agent should receive that chain with the request. I think any agent framework that drops the originating principal at a hop deserves to fail its security review. A committee may soften that sentence; the architecture remains dangerous.
The second variant reached the CI runner
The disclosed research also described a path into issue-fix.yml. A manipulated adk-bot interaction could invoke a workflow that ran commands on the GitHub Actions runner. Coverage said the environment placed ADK_TRIAGE_AGENT, GOOGLE_API_KEY, and ADK_GCP_SA_KEY within reach. SC Media reported the privilege-escalation research in August 2026.
The boundary matters here. GitHub workflow triggers and Collaborator grants are CI/CD controls. Commands executed on a runner are local execution. Environment-variable exposure is a secrets-management problem. Repository permissions, isolated runners, restricted workflow triggers, and short-lived credentials address those parts of the chain. No confirmed third-party theft or in-the-wild exploitation was reported in the cited coverage.
Google characterized the report as involving social engineering and treated it as non-rewardable, according to The Register's August 3 report. The company still fixed the repository path on July 21. Both details belong in the record.
Inter-agent authorization needs an origin chain
A policy decision at each AI hop needs more context than the caller's service account. For an agent invoking another agent through an HTTP model API, carry a signed or otherwise verifiable delegation envelope with five fields:
- Originating human or workload identity
- Relay agent identity and requested action
- Scope granted to the originator for that action
- Data classification and destination model or route
- Expiry, policy version, and correlation ID
The receiving policy point evaluates the originator's authority plus the relay's permitted role. A privileged review agent may accept a maintainer's direct request while denying the same operation when it originates in public pull-request text. The decision should fail closed when the origin chain is absent or exceeds its scope.
This pattern complements agent-to-agent authentication. Authentication proves which participants are present. Authorization constrains the action carried between them. A per-hop record then exposes the exact moment authority widened, rather than leaving responders with one anonymous CI job and a page of model output.
DeepInspect
DeepInspect can govern the in-boundary portion of this design: HTTP AI traffic between authenticated agents and LLM endpoints. The application supplies the originating identity and delegation context. DeepInspect evaluates that context against per-role and per-route policy before forwarding the model request. A relay agent's service account therefore cannot become the sole source of authority for a request that began in public repository content.
Each permit, redact, or deny decision produces a tamper-evident record with identity, route, policy version, data classification, and outcome. GitHub permissions, runner isolation, workflow hardening, and secrets protection remain separate responsibilities. The useful control line is precise: DeepInspect governs the AI call; CI/CD security governs the runner.
Book a technical deep dive at deepinspect.ai.