Agent-to-agent privilege escalation hit Google's own repo

If you have wired an AI agent into GitHub Actions to triage issues, read this one carefully. Pillar Security demonstrated agent-to-agent privilege escalation against Google's own Agent Development Kit repository: an outsider posts a GitHub issue, a public triage agent reads it, and that agent talks a privileged agent into executing code on the CI runner. Google's fix was to delete the workflows.

What actually happened

Per Pillar Security's write-up and The Hacker News' August 4 report, three workflows in the ADK for Python repo formed the chain: issue-analyze.yml, issue-fix.yml, and pr-analyze.yml.

issue-analyze.yml fired automatically whenever anyone opened an issue. It authenticated with ADK_GCP_SA_KEY, handed ADK_TRIAGE_AGENT and GOOGLE_API_KEY to Google's Antigravity coding agent, and posted the resulting analysis as a comment from the adk-bot account.

issue-fix.yml sat behind what looked like a real gate. It only ran when a comment contained /adk-issue-fix, and only if the commenter was an owner, member, or collaborator. That check answered the wrong question. It verified who posted the command — and adk-bot passes that check every time. It never asked whether an outsider had steered the bot into posting it.

So the attack is: put instructions in a public issue, let the triage agent ingest them as content, and get it to emit /adk-issue-fix under its trusted identity. The privileged agent runs. Pillar demonstrated arbitrary code execution on the CI runner and exfiltration of the bot's personal access token plus the environment variables in scope — ADK_TRIAGE_AGENT, GOOGLE_API_KEY, ADK_GCP_SA_KEY.

Google's remediation, in a patch dated June 9, 2026, was to remove all three workflows. The commit noted they processed untrusted issue and pull-request content with broad repository credentials. Researchers confirmed the workflows were gone on July 2; Google confirmed the fix on July 21. No CVE was assigned — this is a repository configuration, not a shipped product defect. Pillar describes it as the first practical case of agent-to-agent exploitation in a production multi-agent system.

Why this matters for your CI pipeline

The reusable lesson is not "Google made a mistake." It is that identity-based authorization breaks the moment one of your identities is an LLM reading attacker-controlled text.

Every access check in that chain was written correctly for a world where the actor behind an account chose to act. adk-bot is a member. Members can trigger fixes. That logic is fine until the member is a language model whose input is a public form field. Prompt injection does not need to defeat your permissions — it borrows an identity that already has them.

Three things to check in your own repo today, and none of them require new tooling:

• Find every workflow triggered by issues, issue_comment, or pull_request_target. Those events carry untrusted text and, in the pull_request_target case, repository secrets. If an AI step reads that text, treat its output as untrusted too.
• Stop gating on identity alone. If a bot can invoke a privileged job, the gate needs a human in it — a maintainer's approval on the action itself, not a check that some trusted account said the magic word.
• Scope the credentials down. The blast radius here was a service account key and API keys sitting in the same environment as an agent reading public input. Separate the read-only triage job from the job that can write, and give them different secrets.

The uncomfortable part is that this is a design pattern, not a bug. Two agents, one public and one privileged, connected by a channel that carries text. If you have built that, you have built this.

Sources: Pillar Security, The Hacker News.