AI agents in CI: prompt injection to secrets

What happened

Researchers showed in 2026 that text an attacker writes into a GitHub issue, comment or repository file can steer an AI coding agent running in CI into leaking secrets. The model does what the text says; the harness around it decides how much damage that can do.

Claude Code GitHub Action. Microsoft found that injected text in an issue or pull request could make Claude Code’s Read tool open /proc/self/environ, which holds ANTHROPIC_API_KEY. Bash ran in a sandbox with a scrubbed environment, but Read ran in-process and was “not subject to the same sandboxing model”. The prompt told the model to drop the first seven characters of the key, which hid the sk-ant- prefix from the model’s refusals and from GitHub secret scanning. Microsoft reported it on 29 April 2026, and Anthropic fixed it in Claude Code 2.1.128 on 5 May by blocking reads of sensitive /proc files (Microsoft).
Gemini CLI, CVE-2026-12537 (CVSS 10.0). In headless (CI) mode Gemini CLI trusted the workspace automatically, so a malicious .gemini/ folder in the checkout could set environment variables that led to code execution. Under --yolo it also ignored tool allowlists. Fixed in @google/gemini-cli 0.39.1 and google-github-actions/run-gemini-cli 0.1.22. The fix requires headless workspaces to be trusted explicitly, which breaks some workflows (GitHub advisory).
Claude Code, CVE-2026-54316 (moderate). huggingface.co was pre-approved for WebFetch, so injected text could leak data through requests to an attacker’s model repository, counted as downloads. Fixed in Claude Code 2.1.163 (GitHub advisory).
OpenAI Codex (no CVE). OpenAI’s own repository ran two Codex passes in one job on a shared checkout. The first pass could write AGENTS.md, which the second pass loaded as instructions. OpenAI said the sandbox behaved as documented, split the passes into separate jobs, and now lists repository instruction files as untrusted input (The Hacker News).

Novee Security presented the Gemini, Claude Code and Codex chains at Black Hat USA on 5 August 2026. Its attacks started from a GitHub issue opened by an account with no repository privileges. They reached code execution on CI runners in Anthropic’s and Google’s repositories, and hijacked the next agent run in OpenAI’s (The Hacker News).

Am I affected?

Find every workflow that runs an agent, then check who can trigger it and what it can reach:

bash

# Workflows that run an AI coding agent
grep -rnE 'anthropics/claude-code-action|google-github-actions/run-gemini-cli|openai/codex-action|@anthropic-ai/claude-code|@google/gemini-cli|@openai/codex' .github/workflows/

# Triggers that outside users can fire, or that run with the base repo's secrets
grep -rnE 'pull_request_target|issue_comment|issues:|discussion|workflow_run' .github/workflows/

# Settings that widen who can drive the agent or what it may do
grep -rnE 'allowed_non_write_users|allowed_bots|--yolo|dangerously-skip-permissions|safety-strategy: *unsafe|gemini_cli_version' .github/workflows/

# The default GITHUB_TOKEN permissions for the repository
gh api repos/OWNER/REPO/actions/permissions/workflow

# Local CLI versions
claude --version; gemini --version; codex --version

A workflow is high risk when all three of these are true: someone outside your team can put text in front of the agent, the job holds secrets or a write-capable token, and the agent can reach the network or post comments.

What to do now

Upgrade. Claude Code 2.1.163 or later, Gemini CLI 0.39.1 or later, run-gemini-cli 0.1.22 or later. If a workflow pins gemini_cli_version or an old Claude Code version, update the pin.
Apply the “Rule of Two”. Microsoft’s rule: a workflow should never combine untrusted input, access to secrets or sensitive systems, and the ability to change state or communicate externally (Microsoft). Drop at least one. A triage bot that reads public issues should not hold deploy keys.
Keep outsiders out. claude-code-action lets only users with write access trigger it by default. Leave it that way. Its docs call allowed_non_write_users “a significant security risk” and say to use it only for workflows with very limited permissions (claude-code-action).
Give the job the least it needs. Set an explicit permissions: block. Use the short-lived GITHUB_TOKEN, not a personal access token. Give each workflow its own AI API key with a spend limit, and alert on unusual usage.
Treat repository files as untrusted input. AGENTS.md, .claude/, .gemini/ and agent config in a checkout can carry instructions. Do not let one agent step write files that a later agent step loads. Run separate passes in separate jobs (The Hacker News).
Do not auto-approve tools on untrusted input. Avoid --yolo and permission-skipping flags in any job an outsider can trigger. For Gemini CLI, only set GEMINI_TRUST_WORKSPACE: 'true' for trusted inputs (GitHub advisory).
For Codex, keep the default safety-strategy: drop-sudo, use disposable runners, and run the action as the last step in its job (codex-action).

Why this is part of the Vulnpocalypse

The Vulnpocalypse brings more bugs and more automation to fix them, and much of that automation is AI agents in CI. Those agents read text written by anyone on the internet and act with your pipeline’s permissions. That turns a public issue tracker into an input to your build system.

The fixes above are real, but they close specific paths. Prompt injection itself is not solved. The safe design is the one that still holds when the model obeys the attacker: an agent that reads untrusted text should not also hold secrets and an open line to the outside.

AI coding agents in CI: one GitHub issue can reach your secrets