A public, untrusted GitHub issue on Google's Agent Development Kit (ADK) Python repository could be crafted to impersonate the repository's own bot account and trigger a privileged CI workflow with write access to issues, contents, and pull requests — an attack Pillar Security named an "authorization bridge." Google's response was to delete the three affected workflows outright rather than patch around them.

What Pillar Security found

Pillar Security discovered that a public GitHub issue on Google's ADK Python repository could be prompt-injected into posting a magic comment — /adk-issue-fix — as the repository's own bot account, an account already listed as an authorized collaborator. Because the privileged workflow's authorization check simply looked for that comment from that authorized account, the injected content satisfied the check without any human ever approving it. Pillar termed the pattern an "authorization bridge": untrusted, public content reaching a privileged internal process by riding on a trusted account's own authority (The Hacker News, 4 Aug 2026).

The workflow that got triggered, issue-fix.yml, held write access to issues, repository contents, and pull requests. Once triggered under the bot's identity, researchers achieved arbitrary code execution on the CI runner and exfiltrated the bot's personal access token, along with a Google API key and a Google Cloud service-account credential exposed in the same environment (The Hacker News, 4 Aug 2026).

Google's response was structural rather than incremental: it deleted three workflows from the ADK Python repository — issue-analyze.yml, issue-fix.yml, and pr-analyze.yml. The removal commit itself states the workflows "processed untrusted issue and pull-request content with broad repository credentials" (The Hacker News, 4 Aug 2026). Deleting the automation, rather than attempting to narrow its permissions or add stricter input validation, is itself a signal about how hard this class of flaw is to patch incrementally.

As of the 4 August 2026 source article, no CVE or formal Google advisory had been issued for this finding. The disclosure timeline: a patch was authored 9 June 2026, Pillar verified the workflow removal on 2 July 2026, Google confirmed the fix on 21 July 2026, and the finding was published 4 August 2026 — about two weeks between Google confirming the fix and the finding going public.

Why this is a distinct attack pattern, not a restatement of prompt injection

The underlying mechanism is prompt injection, but the target and blast radius are different from the runtime-agent scenarios most prompt-injection coverage focuses on. This wasn't a deployed agent talking to a user; it was a CI/CD pipeline where a privileged automation account acted on public, untrusted GitHub content by design — the workflow existed to read and respond to issues and pull requests from anyone.

That design intent is exactly the trap. A workflow built to process public content needs to authenticate what it's allowed to act on, not just whether the triggering text matches an expected format. Here, the authorization check trusted the account name attached to a comment, and the injection vector was precisely that account's own automated posting behavior — the bot account became the confused deputy, authorized by its identity but manipulated in its content.

Notice, too, how many independent credentials were exposed once the runner was compromised: the bot's personal access token, a Google API key, and a Google Cloud service-account credential, all reachable from the same CI environment (The Hacker News, 4 Aug 2026). That is a second lesson independent of the authorization-bridge mechanism itself — a single compromised entry point yielded three separate categories of credential because they all lived in reach of the same over-privileged runner, rather than being isolated by the specific task each was meant to support.

This is a meaningfully different failure than the goal-hijacking pattern covered in goal hijacking in AI agents, where an agent's own task gets redirected by injected instructions. Here, the "agent" being hijacked was a CI automation, and the escalation path ran through GitHub's own collaborator-authorization model rather than through an agent's tool-calling loop directly. It's closer in shape to a delegation-abuse problem — a downstream process inheriting the authority of an upstream identity it shouldn't fully trust — which is the same structural risk covered in A2A delegation abuse, applied here to a bot-account-to-CI-runner relationship instead of agent-to-agent.

It's also worth being precise about scope: this vulnerability lived inside ADK's own CI pipeline — the automation Google runs to triage its own open-source repository — not inside a customer's deployed ADK agent. Google Cloud's governance offerings for ADK deployments — described in search-indexed Google Cloud material as of late August 2026 as spanning agent identity, gateway, security, and registry capabilities through the Gemini Enterprise Agent Platform — are a separate surface from the repository automation Pillar attacked. That distinction matters when scoping your own exposure: if you build agents on ADK, this specific incident is not evidence that your deployed agent inherited the flaw — but the underlying pattern (privileged automation triggered by untrusted public content, authorized by identity rather than validated content) generalizes to any CI/CD pipeline your own agents or agent-adjacent tooling touch.

Controls that prevent this class of failure

Three controls generalize past this specific incident to any privileged automation that processes public or otherwise untrusted content:

  1. Never let content-based triggers double as authorization. A comment matching an expected string, from an account that happens to be a collaborator, is not the same as a human explicitly approving a privileged action. Authorization checks should validate the actor and the intent of an action through a channel the attacker cannot influence — not through content the attacker can shape.
  2. Scope CI credentials to the minimum the workflow needs, and rotate them. A workflow that only needs to comment on an issue does not need write access to repository contents and pull requests simultaneously. The excessive-permissions component of this incident — broad write access bundled into one credential — is the same failure mode covered generally in excessive agency controls for OWASP LLM06: more functionality and more permission than the task requires, waiting to be exercised by whatever reaches the automation.
  3. Treat any pipeline that ingests public content as an untrusted-input boundary. Issue text, pull-request descriptions, and comments from unauthenticated or low-trust submitters should be handled the same way an agent handles retrieved external content in an indirect-injection threat model: scanned, constrained, and never given the ability to trigger privileged downstream actions on their own. The AI agent security guide covers the layered identity, authorization, and monitoring controls that apply equally to agent runtimes and the CI automation that increasingly surrounds them.

A fourth, more structural point worth adding for platform teams standardizing on agent-adjacent CI automation: audit which of your bot or service accounts are listed as repository collaborators, and confirm none of them can be impersonated through content a public account can post. Google's own remediation — deleting the workflows rather than patching around the authorization check — is itself informative. When the fastest reliable fix for an identity-and-content confusion problem is to remove the automation entirely, that's a signal the underlying design pattern (trusted identity, untrusted content, no separation between the two) is worth avoiding from the start in anything new you build, rather than something to patch defensively after the fact.

This kind of incident is also a useful case study for why agent-adjacent automation deserves the same identity discipline as the agents themselves. A CI bot account that can be triggered by public content and holds broad write permissions is functionally no different from an over-permissioned agent — it just isn't usually described as one, reviewed as one, or scoped as tightly as one, which is precisely why it can sit unnoticed until a researcher goes looking.

FAQ

Was a CVE ever issued for this Google ADK finding? No. As of the 4 August 2026 source article, no CVE or formal Google security advisory had been published; Google's response was to delete the affected workflows rather than issue a numbered advisory.

Does this mean Google ADK agents deployed by customers are vulnerable? Not directly. The flaw lived in ADK's own repository CI automation, not in a customer-deployed agent — but the underlying pattern (privileged automation triggered by untrusted content, authorized by identity rather than validated intent) is worth checking for in any pipeline you operate.

How did Google fix it? Google deleted the three affected workflows (issue-analyze.yml, issue-fix.yml, pr-analyze.yml) from the ADK Python repository rather than patching them in place, per the removal commit Pillar Security cited.