Google ADK Lets Low-Trust Agents Influence Privileged Automation

Key Takeaways

• The attack crossed trust boundaries between cooperating agents.
• A GitHub pull request supplied the malicious instructions.
• Higher-privilege automation inherited low-trust agent context.
• Potential outcomes included code approval and pipeline compromise.
• Google remediated the reported paths before public reporting.

Agent-to-Agent Trust Created a Privilege Escalation Path

Researchers demonstrated how a low-privilege agent built with Google’s Agent Development Kit could pass attacker-controlled context into a more privileged automation agent. Dark Reading reported that a malicious GitHub pull request could influence downstream review and CI/CD activity, turning normal agent collaboration into a path toward higher authority.

What We Know

The researchers reported the issue to Google in early June 2026. Remediation was delivered in July, and the work was widely reported on August 5. The proof of concept focused on multi-agent automation built with the Python version of Google ADK.

A public-facing agent processed untrusted pull-request content, while a second agent had greater authority to review, approve, or act on development changes. The weakness arose when the higher-trust workflow accepted context or conclusions from the lower-trust agent without preserving the original content’s provenance and applying a new authorization decision.

Public reporting described possible influence over code approval and CI/CD operations. Google released fixes before broad disclosure, with version history available in the Google ADK Python releases.

What Could Happen

An attacker submits content to a low-trust interface such as a public pull request, issue, support request, or external application. The first agent is authorized to read and summarize the content but not to change protected assets.

Through indirect prompt injection, the attacker persuades that agent to generate a recommendation or message designed to influence a second agent.

• If the receiving agent treats the message as trusted internal context, it may approve code, invoke a deployment tool, disclose information, or perform another action unavailable to the attacker and the first agent.
• The escalation does not require stealing a human identity.
• It exploits an authorization model that checks each agent separately but fails to carry source provenance and delegated scope through the full chain.

Why It Matters

Multi-agent applications distribute work across specialized components, often assigning different tools and privilege levels to each. This makes the receiving agent’s trust decision as important as conventional API authorization. If provenance is lost, an internal-looking agent message can conceal instructions originating from an anonymous external contributor.

The potential business consequences include unauthorized source changes, compromised builds, exposure of deployment credentials, and reduced confidence in automated review. Although this case was remediated and no production attack was confirmed, it shows why organizations need an inventory of agents, owners, communication paths, tools, and delegated permissions.

Security reviews should test not only whether one agent resists prompt injection, but whether injected context can cross into another agent with greater authority.

PointGuard AI Perspective

PointGuard AI addresses cross-agent risk by combining identity, contextual authorization, and pre-execution policy enforcement. Agent Mission Control establishes verifiable agent identity and evaluates actions against assigned scope before execution.

MCP Security Gateway applies least-privilege controls to agent tool calls and connected resources, reducing the authority available when a handoff is manipulated. AI Governance supports ownership, policy, and auditable oversight across the AI lifecycle.

Multi-agent workflows should carry the provenance of external content, the identity and scope of every intermediary, the originating task, and any transformations applied along the way. Receiving agents should not inherit broader authority simply because a message came from another registered agent.

Organizations should define explicit delegation rules, use short-lived scoped credentials, and require approval for code merges, deployments, credential access, or other high-consequence actions. Continuous observation should flag unusual delegation patterns and goal drift across agent chains.

Incident Scorecard Details

Total AISSI Score: 7.2/10

Criticality: 8, The path could reach protected code, CI/CD operations, and privileged automation. AISSI weighting: 25%

Propagation: 8, The trust-transfer flaw can recur across multi-agent frameworks and connected workflows. AISSI weighting: 20%

Exploitability: 5, A proof of concept was demonstrated, with no confirmed active exploitation. AISSI weighting: 15%

Supply Chain: 9, The scenario involves a widely adopted external framework and software development ecosystem. AISSI weighting: 15%

Business Impact: 6, Potential supply-chain harm was credible, but realized customer impact was not reported. AISSI weighting: 25%

Sources

Third-Party Sources

• Dark Reading: Google ADK Agent-to-Agent Attack
• Google ADK Python Releases