Google’s ADK flaws expose the danger of trusting AI agents with code
Google’s ADK flaws expose the danger of trusting AI agents with code
Pillar Security researchers found two attack paths in Google’s Agent Development Kit for Python. Both let outsiders steer privileged automation through prompt injection. The flaws sit in workflows that hand off tasks between agents — one triaging pull requests, another attempting fixes — and both chains end with an attacker influencing a more powerful system without ever touching it directly.
How the first chain worked
A triage agent reviewed pull requests from external contributors and posted its analysis through adk-bot, a GitHub account with collaborator access. Buried in a malicious pull request, a prompt could induce the agent to post an @gemini-cli command. That command triggered a workflow reserved for trusted users — a workflow with a GitHub token that could write to issues and pull requests, approve reviews as github-actions[bot], and remove legitimate review requests. The malicious PR suddenly looked ready to merge.
Pillar reproduced this in their lab. Google hardened the repository after disclosure.
The second path: prompt injection via public issues
Newer workflows built around an Antigravity-based agent introduced a separate vector. An attacker places a prompt injection in a public issue. An analysis agent picks it up and posts the command that starts a fixing workflow — again, reserved for trusted users. That workflow tried to limit the agent to Git and GitHub commands, but Pillar showed Git itself can launch arbitrary code. Pillar extracted both the adk-bot personal access token and a Google Cloud service account key from the runner.
Google removed the affected workflows by July 2 and fixed the second issue by July 21.
Agent handoffs are the new attack surface
Pillar calls this the first practical, real-world case of agent-to-agent exploitation in a production multi-agent system. Here’s how it works: Agent A consumes untrusted input. Agent A’s output triggers Agent B, which holds higher privileges. The trust boundary collapses because the system treats Agent A’s natural-language output as an authorization signal.
Sanchit Vir Gogia, chief analyst at Greyhound Research, put it bluntly: “Natural language has joined the authorization path. That is the change worth reporting, not the ‘first-ever’ framing.”
An agent’s real authority isn’t just the tools it holds — it’s every downstream system its output can reach.
What CISOs should trace
Sakshi Grover, senior research manager for IDC Asia Pacific Cybersecurity Services, says materiality comes from tracing three things:
- Which agents consume untrusted content — pull requests, issues, emails, support tickets, external documents?
- Can those agents directly or indirectly trigger another agent or workflow with higher privileges?
- What is the maximum effective capability of the identities, credentials, and tools involved?
Existing tools — IAM, PAM, CIEM, application security scanners — expose individual permissions and unsafe configs. But they 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.
Human approval doesn’t close the gap
The first attack path still required a maintainer to merge the PR. But the manipulated automation influenced the evidence presented to that maintainer. “An attacker needs no merge rights when it can manufacture the evidence that persuades someone else to merge,” Gogia said. 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 be treated as security events and exported to an independent logging system the workflow’s own identity cannot alter.
Why this matters for African enterprises
African fintechs and enterprises are adopting AI coding assistants and agentic workflows fast. The GitHub Actions runner that executes your CI pipeline is often the same identity that deploys to production. A prompt injection in a public issue or a malicious pull request shouldn’t be able to reach that identity — but in the ADK case, it did.
eHawu operates at the network layer. We don’t inspect prompts or parse agent logic. We enforce that only authorized identities reach authorized destinations — regardless of what an agent says or what workflow it triggers. When the authorization path extends through natural language, the network boundary remains the only control that doesn’t hallucinate.
Map your agent delegation paths. Limit what untrusted input can trigger. Put a network-layer gate in front of every identity that touches production.
