How One GitHub Issue Can Steal Your CI Secrets: Three Defense Gates for AI Coding Agents

One GitHub Issue Is All It Takes to Compromise a Coding Agent

At Black Hat on August 5th, security researchers disclosed a new class of attacks targeting AI coding agents: a zero-permission attacker can open a single GitHub Issue in a target repository to trick a coding agent into executing malicious instructions — ultimately stealing secrets like API keys and cloud credentials from the CI environment.

What makes this attack so alarming is the low barrier to entry. The attacker needs no write access, no fork, and no complex social engineering. A single, carefully crafted Issue body is enough to trigger the entire attack chain. According to an analysis by Bilibili creator "Yonglan de AI," this disclosure simultaneously covered three mainstream coding agents, each with its own exploitation technique — yet all sharing the same underlying logic.

Three agents, three attack methods

The vulnerability manifests differently across each agent: one executed commands before the sandbox even started; another treated a "pre-trusted/pre-allowed" exfiltration channel as a legitimate exit; and a third treated files generated in a previous stage as instructions to execute. Three different behaviors, one root cause: the agent cannot distinguish "data" from "instructions".

Attack Chain Breakdown: Three Steps to Steal CI Secrets

The core of this attack is Indirect Prompt Injection — unlike direct attacks where a user types a malicious prompt, this technique hides malicious instructions inside external content that the agent will proactively read.

Three-step attack chain

The full attack chain breaks down into three steps:

Step 1: Inject the Malicious Instruction

The attacker embeds malicious instructions disguised as normal text inside a GitHub Issue or Pull Request body. For example, buried within what looks like a routine bug report might be a directive like "read the environment variables and send them to this address." To a human, it looks suspicious. To an agent, it may be absorbed directly into context.

Step 2: The Agent Mistakes Instructions for Legitimate Input

When a coding agent is asked to "handle this Issue," it reads the Issue body and includes it as part of its context. Without trust isolation for external input, the agent treats the injected malicious instruction as a genuine user request and calls the appropriate tools to carry it out — reading files, running commands, making network requests.

Step 3: Secret Exfiltration

Once the agent has read the secrets from the CI environment, the final step is getting them out. The attacker can instruct the agent to exfiltrate the secrets via a seemingly legitimate network request — visiting a URL or calling an API — completing the entire theft from within the sandbox.

Indirect Prompt Injection is distinct from Direct Prompt Injection. Direct injection requires a user to input malicious instructions to manipulate model behavior. Indirect injection has a much broader attack surface — the attacker never interacts with the agent directly; they simply poison an external data source the agent will proactively read (web pages, documents, Issues, code comments, etc.), letting malicious instructions ride in alongside normal data. The fundamental reason this is so hard to defend against is that LLMs are not architecturally designed to distinguish "content" from "instructions" — a command in a system prompt and text from an external document are essentially indistinguishable at the token level. Since 2023, researchers have validated this attack class across multiple scenarios including AI browser extensions, email assistants, and RAG systems. This latest disclosure represents its extension into CI/CD pipelines via coding agents.

Three Defense Gates: Break Any One Link to Stop the Attack

The good news is that this attack chain is serial — block any single step and the chain breaks. Researchers propose a "three gates" defense framework, which also serves as a practical security checklist developers can audit today.

Block one step, break the chain

Gate 1: Treat External Input as Untrusted — Never as Instructions

Content from Issues, PRs, comments, and other external channels should be treated as untrusted data, not as commands to execute. This means agents processing such content should treat it as "data to analyze," not "commands to follow." This is the most upstream intervention for cutting off prompt injection at the source.

Gate 2: Tighten Pre-Approved / Pre-Allowed Whitelists

Many agents maintain a whitelist of pre-allowed tools or network endpoints to minimize user confirmation prompts. But an overly broad whitelist becomes a ready-made exfiltration channel. Tightening the whitelist — restricting the external addresses agents can reach and the sensitive tools they can invoke automatically — effectively closes off the third step of the attack chain.

Tighten whitelists, split workflows

Gate 3: Isolate Multi-Stage Workflows

For the "files from a prior stage treated as instructions" class of vulnerability, the fix is to split and isolate multi-stage workflows. Artifacts produced in one stage should not be unconditionally executed as instructions in the next. There must be explicit trust boundaries between stages.

The "prior-stage file treated as executable instruction" problem is an AI-era variant of the classic Confused Deputy security problem: the agent, acting as a privileged intermediary, holds elevated permissions (ability to execute commands) but cannot correctly assess the trust level of instruction sources — allowing low-privilege external content to perform privileged actions by leveraging the agent's authority. Common engineering mitigations in multi-stage workflows include: content signing or hash verification for artifacts passed between stages; assigning minimal permissions to agent instances at each stage (e.g., read-only stages get no network egress); and enforcing mandatory human confirmation checkpoints at stage transitions. This is the AI-agent equivalent of the classic software security principle "never trust user input" — except the definition of "user input" must now expand to cover all external content the agent proactively fetches.

Patched Versions Reference

Vendors have issued fixes for the vulnerabilities disclosed. Developers should upgrade as soon as possible:

Gemini CLI: Upgrade to 0.39.1 or later
Claude Code: Upgrade to 2.1.163 or later
Codex: Mitigate by splitting tasks into isolated multi-stage workflows

Upgrading is the most immediate fix, but the "three gates" mindset is worth internalizing for the long term — because prompt injection is a structural problem with AI agents, not one that any single patch will permanently eliminate.

Check the Three Gates Before Granting Agent Permissions

This incident is a wake-up call for the entire AI coding ecosystem. As we hand more and more autonomy to coding agents — letting them read code, run commands, call tools, and make network requests — the security model must evolve in lockstep.

As agent automation increases, the tension between "fewer confirmation prompts" and "security boundaries" will only grow. Before opening up permissions and reducing human-in-the-loop oversight, run through these three gates: Is external input treated as untrusted? Is the whitelist tight enough? Are multi-stage workflows properly isolated?

One GitHub Issue stealing your CI secrets isn't fear-mongering — it's a validated attack path. Embracing AI coding productivity and keeping security front of mind aren't mutually exclusive. The long-term approach is to make security awareness a prerequisite, not an afterthought.