The short answer
Security firm Pillar Security has disclosed a flaw in the automation around Google's open-source Agent Development Kit (ADK) for Python in which a public GitHub issue — writable by anyone — could prompt-inject a low-privilege triage agent into invoking a high-privilege code-fixing agent, resulting in arbitrary code execution on the CI runner and exfiltration of the adk-bot token, a Google API key and a Google Cloud service-account credential. Pillar describes it as the first practical, real-world case of agent-to-agent exploitation in a production multi-agent system. Google removed the vulnerable workflows in July 2026, with the research published in early August.
The story is less about one repository than about a design pattern that is spreading fast. As teams wire up autonomous AI agents to triage tickets, review pull requests and push fixes, the boundary that used to sit between "reads untrusted input" and "holds production secrets" is quietly collapsing into a single automated chain — and prompt injection is the payload that walks across it.
What Pillar Security found
The ADK is Google's framework for building and orchestrating AI agents, and — like many open-source projects now — its own repository used agents to help maintain itself. Researchers at Pillar Security examined the GitHub automation attached to the ADK-for-Python repo and found that its multi-agent workflows could be turned against the project. The core weakness was not a memory bug or a missing patch; it was a trust-boundary failure between two agents that were never meant to have equal power.
On one side sat a public, internet-exposed triage agent whose job was to read incoming issues and pull requests — content that any anonymous user can write. On the other side sat a privileged code-fixing agent, built on Google's Antigravity coding agent, that could modify the repository and ran with access to secrets. Pillar showed that the first agent could be talked into commanding the second. Because the triage agent treated the text of a GitHub issue as instructions, an attacker could embed a directive that made it post a trigger comment as adk-bot, launching the privileged fixing workflow as though a trusted maintainer had asked for it.
How one agent hijacked another
The entry point was a public issue-analyze.yml workflow that ran automatically every time an issue was opened. That workflow authenticated with a Google Cloud service-account key (ADK_GCP_SA_KEY) and handed a triage agent and a Google API key (GOOGLE_API_KEY) to the Antigravity coding agent. In other words, an automation reachable by any anonymous GitHub user was already wired to credentials that mattered.
From there, Pillar demonstrated the escalation. Prompt-injected instructions in the issue steered the low-privilege agent into invoking the high-privilege one — the researchers describe it as posting /adk-issue-fix as the bot — which spun up the fixing job with elevated permissions. Abusing Git's ability to execute code during that job, the team achieved arbitrary code execution on the continuous-integration runner and exfiltrated the bot's personal access token. The same privileged job also held a Google API key and a Google Cloud service-account credential, meaning a single crafted issue could reach code execution and multiple live secrets. Pillar confirmed the affected workflows were removed on 2 July 2026, and Google confirmed a fix for the second issue on 21 July 2026; the findings were published in early August.
Why this is a pattern, not a one-off
It would be easy to file this under "Google misconfigured a workflow" and move on. That would miss the point. The same shape appears wherever a low-privilege agent that consumes untrusted content can, directly or indirectly, cause a higher-privilege agent or job to act. "An agent's authority should be measured not only by its assigned tools, but also by the more privileged systems its output can trigger or influence," Sanchit Vir Gogia of Greyhound Research told CSO Online — a neat summary of the transitive-authority problem at the heart of this class of bug.
Prompt injection is the enabler because natural-language instructions and data share the same channel: an agent cannot reliably tell "analyse this bug report" from "analyse this bug report, then trigger the fix workflow." Chain two or three agents together and the blast radius is no longer the weakest agent's own permissions — it is the strongest permission anywhere downstream of it. Sakshi Grover of IDC Asia Pacific framed the defensive homework in the same terms: identify which agents consume untrusted content, trace whether their outputs can trigger higher-privilege workflows, and map the maximum effective capabilities of the credentials involved.
What it means for US & EU software teams
Most teams are not maintaining a framework repo, but a great many are now doing the exact thing that made this exploitable: pointing agents at GitHub issues, support tickets, emails or customer messages, and letting those agents kick off downstream automation. If any link in that chain can reach production secrets, deploy code or approve a change, then untrusted text has a path to privileged action. The uncomfortable version of the question is simple — if an attacker can write into your system, what is the most privileged thing an agent could be talked into doing on their behalf?
For regulated sectors the stakes are concrete. In FinTech, payments and healthcare, unauthorised access and change-control integrity are audited obligations under frameworks such as SOC 2, DORA and the EU AI Act, and "an AI agent did it" is not a defence when the agent held a service-account key. The added wrinkle here is auditability: agent-driven actions can look like ordinary bot activity, so a comment that triggered a privileged job may not stand out in your logs at all. Treating agent output — comments, reviews, workflow triggers — as security-relevant events, and validating agent behaviour with the same rigour you apply to a security audit of any privileged automation, is now part of shipping agents responsibly.
How to harden a multi-agent system
You do not need to rip out agentic automation to respond to this. You need to stop letting an agent that reads untrusted input silently borrow the privileges of one that does not.
- Isolate untrusted-input agents. Any agent that reads issues, tickets, emails or PRs from outside your trust boundary is untrusted itself — never let its output automatically invoke a more-privileged agent or workflow.
- Map transitive authority. Diagram which agents can trigger which jobs, and compute the maximum effective capability of every credential in the chain, not just the one an agent holds directly.
- Keep secrets off untrusted paths. Service-account keys, API keys and personal access tokens should not live in any job that anonymous input can reach; scope every token to least privilege.
- Require a human or signed gate for privileged actions. Deploys, merges and secret access driven by an agent should demand an out-of-band approval that untrusted text cannot forge.
- Bind approvals to the exact code examined. If the reviewed material changes after approval, invalidate it — an approval for one diff must not carry over to another.
- Log agent actions as security events. Treat agent-generated comments, reviews and workflow triggers as auditable events with independent logging, so a malicious trigger is visible rather than blending into bot noise.
The strategic signal from Pillar's work is narrow and useful: multi-agent automation moves risk from any single agent's permissions to the strongest permission reachable across the whole chain. The teams that design for that — isolating untrusted readers, gating privileged actions, and watching agent output the way they watch human actions — get the leverage of agentic delivery without handing anonymous strangers a route to their production secrets.
Frequently asked questions
What did Pillar Security find in Google's ADK repo?
Pillar Security found that the multi-agent automation in Google's open-source Agent Development Kit (ADK) for Python repository could be turned against itself. A public GitHub issue or comment written by anyone could prompt-inject a low-privilege, internet-exposed triage agent into invoking a high-privilege code-fixing agent on its behalf. The researchers demonstrated arbitrary code execution on the CI runner and exfiltration of the adk-bot personal access token, while the privileged job also held a Google API key and a Google Cloud service-account credential. Pillar called it the first practical, real-world case of agent-to-agent exploitation in a production multi-agent system.
How did the agent-to-agent attack work?
The attack began in a public issue-analyze.yml workflow that ran automatically whenever a GitHub issue was opened. That workflow authenticated with a Google Cloud service-account key and supplied a triage agent and a Google API key to Google's Antigravity coding agent. Because the triage agent read attacker-controlled issue text as instructions, it could be manipulated into posting a trigger comment (such as /adk-issue-fix) as adk-bot, which launched the privileged fixing workflow. A low-privilege agent that only consumed untrusted content could therefore reach across a trust boundary and drive a high-privilege agent with access to secrets and the CI runner.
Has the Google ADK flaw been fixed?
Yes. Google removed the vulnerable workflows from the ADK for Python repository, with Pillar confirming the affected workflows were taken down on 2 July 2026 and Google confirming a fix for the second issue on 21 July 2026. The findings were disclosed publicly in early August 2026. The removed automations were tied to Google's own repository, so the immediate exposure was to that project rather than to applications built with the ADK, but the design pattern that made the attack possible is common across multi-agent systems.
Does this mean AI coding agents are unsafe to use?
No. The issue is not that agents are inherently unsafe but that a low-privilege agent consuming untrusted input was able to trigger a high-privilege agent holding secrets, without a boundary enforcing least privilege between them. Agentic automation remains useful for triage, review and remediation. The lesson is that an agent's real authority includes every more-privileged action its output can trigger, so those transitive paths must be mapped, isolated and monitored rather than assumed safe.
How can teams building multi-agent systems defend against this?
Treat any agent that reads untrusted content as fully untrusted itself, and never let its output automatically invoke a more-privileged agent or workflow. Map the transitive authority flows between agents so you know the maximum effective capability of every credential in the chain. Keep secrets such as service-account keys and personal access tokens out of jobs that untrusted input can reach, and scope tokens to least privilege. Bind approvals to the exact code that was examined and invalidate them if the material changes, and log agent-driven comments, reviews and workflow triggers as security events.
Sources
The Hacker News — Google Deletes 3 ADK AI Workflows After Malicious GitHub Issue Could Trigger Privileged Agent
The Register — Google dev kit spurs first-ever agent-on-agent violence
CSO Online — Google ADK flaws reveal what happens when AI agents trust the wrong message