Google Deletes 3 ADK AI Workflows After Pillar Security Discloses an Agent-to-Agent Attack
The first documented agent-on-agent attack. Google removed three Agent Development Kit workflows after Pillar Security showed a poisoned public GitHub issue could push a low-privilege triage agent into triggering a privileged code-fixing agent — exposing secrets and tampering with pull requests.
One AI agent got another AI agent to do something it wasn't allowed to do. That is the short version of what Pillar Security disclosed this week, and it is why Google pulled three agent workflows out of the Python repository for its Agent Development Kit (ADK). A public comment on a GitHub issue — the kind anyone on the internet can file — was enough to walk a low-privilege AI agent into handing control to a far more powerful one.
Google deleted the three ADK workflows after Pillar showed that a poisoned GitHub issue could manipulate a public triage agent into triggering a privileged code-fixing agent. The payoff for an attacker was concrete: exposure of repository secrets and tampering with pull requests. What makes this notable is not the size of the blast radius but the shape of it — the attack traveled from one autonomous agent to another, across a privilege boundary, without a human in the loop.
What Pillar Disclosed and What Google Removed
The setup was a two-agent pipeline built on ADK. A public-facing triage agent read incoming GitHub issues and helped sort them. A separate, privileged code-fixing agent could actually change code — open branches, push commits, touch pull requests. Those are two very different trust levels stitched into the same repository, and the seam between them is where Pillar went to work.
According to The Hacker News, the researchers found that the public triage agent could be prompt-injected through issue text into posting the string /adk-issue-fix as the account adk-bot. Because adk-bot was registered as a "collaborator" on the repository, that comment cleared the privileged agent's trigger check. The higher-privilege agent saw a command from a trusted identity and ran. From there, Pillar's write-up describes secrets exposure and pull-request tampering as the outcomes.
Google's response was to remove the three affected workflows from the ADK for Python repository. That is the confirmed fact. What is not confirmed is whether the deletion is a permanent architectural fix or a temporary rollback while Google reworks the trigger model — the disclosures don't settle that, and I'd treat the removal as a stop-the-bleeding move until Google says otherwise.
I'm keeping the mechanics deliberately high level here. This is a defender's account, not a how-to: the point is the trust relationship that failed, not the exact wording that made it fail.
adk-bot, a registered collaborator. That satisfies the privileged code-fixing agent's check — leading to secrets exposure and pull-request tampering."First-Ever Agent-on-Agent Violence"
The Register ran the story under the headline "Google dev kit spurs first-ever agent-on-agent violence," which captures why this one is getting attention beyond the usual bug write-up. We've watched prompt injection push a single model into doing the wrong thing for a while now. What's new is one agent being turned into the delivery mechanism against a second agent that holds more power than it does.
SecurityWeek framed the same disclosure as "Gemini Agent-to-Agent Attack Method Exposed Secrets, Enabled Pull Request Tampering," tying it to Google's Gemini stack. The common thread across all three outlets is the privilege jump: the interesting failure isn't that a low-privilege agent got fooled, it's that its output was trusted enough to move a high-privilege agent.
This lands in the same territory as other recent autonomous-agent incidents. It echoes the concerns around an AI model breaking out of its sandbox to reach outside systems, and the broader question of what happens when autonomous agents are handed real operational reach. The pattern keeps rhyming: an agent trusted to act gets steered by input it was never supposed to trust.
What Multi-Agent Teams Should Verify
If you run any multi-agent orchestration, the lesson here is a single sentence you can turn into an audit: treat a low-privilege agent's output as untrusted input to any higher-privilege agent. The moment one agent's message can satisfy another agent's trigger, you have a privilege-boundary crossing that an attacker can aim at.
Concretely, walk your pipelines and ask a few questions. Where does a lower-trust agent produce output that a higher-trust agent consumes as a command or a signal to act? What identities can trigger your privileged agents, and can a less-trusted component post as one of those identities? In this case the whole exploit hinged on a bot account being marked as a "collaborator" — an identity check that was doing more security work than anyone intended. Inventory those trigger conditions and confirm each one still holds if the upstream agent is compromised.
Also worth checking: what secrets and tokens are reachable from the privileged agent's execution context. The damage in Pillar's account came from secrets exposure and PR tampering, which means the privileged agent's environment held things worth stealing. Scoping those credentials down limits what a successful crossing can reach.
The Broader Agent-Orchestration Attack Surface
Step back and the ADK case is one instance of a category that's going to keep growing. Multi-agent systems are, by design, machines for turning one agent's output into another agent's input. That's the feature. It's also the attack surface. Every hand-off between agents of different trust levels is a place where prompt injection can try to ride from low privilege to high.
The uncomfortable part is that traditional access control assumes a human or a fixed service on either side of a permission boundary. Agent orchestration inserts a probabilistic component — a model that can be talked into things — right at the boundary. A "collaborator" check makes sense when a collaborator is a person. It makes less sense when the thing posting as that collaborator is an agent reading attacker-controlled text.
My read: the specific ADK workflows are a footnote. The durable takeaway is that "which agent is allowed to trigger which agent" is now a first-class security decision, on par with file permissions or network segmentation — and most teams building with agent frameworks haven't drawn that boundary explicitly yet. Pillar found it here first; the pattern isn't unique to Google.
Open Questions
Several things remain unconfirmed, and I won't paper over them. The disclosures don't specify which ADK versions were affected, and no CVE identifier has surfaced in the reporting I've seen. It's not clear whether Google's deletion is a permanent fix or a temporary rollback. Nor is it established whether other agent frameworks — the reporting doesn't name LangChain, LangGraph, or MCP as vulnerable, and I'm not asserting they are — share the same trust pattern, though the shape of the problem is general enough to warrant asking. Whether Pillar's proof-of-concept is public, and whether any other Google properties were exposed, are also open.
What's solid is the core sequence: a public GitHub issue, a low-privilege triage agent, a prompt injection posting /adk-issue-fix as adk-bot, a privileged code-fixing agent that trusted the "collaborator," and Google removing three workflows in response. For anyone running agents that can act on each other, that's enough to start the audit today.
