Securing AI Coding Agents in CI: A Hardening Guide

At Black Hat USA on August 5, researchers from Novee Security presented work showing that a GitHub issue opened by an account with no repository privileges was enough to execute code on the CI runners behind major vendors' own coding-agent repositories. Two CVEs came out of it. Both are patched. The vendors moved quickly and the disclosure was handled properly, and that is genuinely the good news here.

The better news is that the research produced the clearest curriculum yet for a problem every engineering team now has: an AI coding agent running in continuous integration is a program that reads untrusted input and holds credentials. This guide covers what happened, which versions to run, and the hardening steps that hold regardless of which agent you use.

• Two CVEs were disclosed and patched: CVE-2026-12537 in Gemini CLI and CVE-2026-54316 in Claude Code
• Gemini CLI fixes shipped in 0.39.1 and run-gemini-cli 0.1.22; Claude Code fixes shipped in 2.1.163
• The root pattern is untrusted input reaching a privileged CI context, not a defect unique to any one vendor
• Both issues were reported through coordinated disclosure and fixed before public presentation

Quick Picks: The Seven Things to Do Today

• Pin your agent to a patched version and enable automated dependency updates on it
• Never run an agent on untrusted input inside a workflow that holds repository secrets
• Replace long-lived API keys with short-lived OIDC tokens scoped to a single job
• Put the agent's network egress behind an allowlist, not an allow-by-default policy
• Treat every pre-approved tool integration as a potential exfiltration channel and review the list
• Require a human approval gate between an agent's plan and any write operation
• Log every tool invocation and outbound host, and alert on hosts that are not on the allowlist

What Actually Happened at Black Hat 2026?

Novee ran its attack against each vendor's agent in the configuration that vendor ships by default. That detail is what makes the research worth your attention — this was not a contrived misconfiguration but the out-of-the-box setup.

CVE-2026-12537 carries a CVSS v4 score of 10.0 and is an OS command injection in Gemini CLI's container launcher, reachable through a crafted environment file. It let an unprivileged attacker run code on the host of a headless CI platform before the sandbox even started — a sandbox escape that never needed to enter the sandbox. It is fixed in Gemini CLI 0.39.1 and run-gemini-cli 0.1.22.

CVE-2026-54316 in Claude Code is the more architecturally instructive of the two. It abused the agent's pre-approved access to Hugging Face, turning that service's public download counter into an exfiltration channel that leaked an API key one character at a time. No malicious server, no unusual destination — just a legitimate, allowlisted service used as a side channel. It affects versions 0.2.54 through 2.1.162 and is fixed in 2.1.163.

Which Versions Should You Be Running?

Check these first, because everything else in this guide is secondary to being patched:

• Gemini CLI: 0.39.1 or later
• run-gemini-cli GitHub Action: 0.1.22 or later
• Claude Code: 2.1.163 or later

If you pin agent versions in a workflow file — and you should — this is the moment to confirm the pin is current rather than eighteen months stale. Automated dependency updates on your CI actions are the cheapest control on this entire list.

Why Does Untrusted Input Reach a CI Runner at All?

This is the question worth internalizing, because the specific CVEs will age out and the pattern will not.

The pull_request_target Trap

GitHub Actions offers a trigger that runs workflows in the context of the base repository, with access to its secrets, in response to events from outside contributors. It exists for legitimate reasons — labeling pull requests, posting review comments — and it is the single most common way untrusted input reaches a privileged context.

Add an AI agent to such a workflow and the exposure changes shape. A traditional script does a fixed, auditable thing with untrusted input. An agent reads the untrusted input as instructions and decides what to do next. Prompt injection stops being a chat-window curiosity and becomes remote code execution with your repository's credentials attached.

Pre-Approved Tool Allowlists

The Claude Code finding illustrates the second pattern. Agents ship with pre-approved integrations so common operations do not require constant confirmation, and Hugging Face access is an entirely sensible default for a coding agent.

But any allowlisted service that reflects observable state back to the world is a potential covert channel. A public download counter is not an obvious exfiltration path until someone increments it in a pattern that encodes a secret. When you review an agent's pre-approved tool list, the question is not only whether each service is trustworthy — it is whether each service can be observed from outside.

Seven Hardening Steps in Detail

1. Separate the untrusted-input workflow from the privileged workflow. Handle outside contributions in a job with no secrets and read-only permissions. If a privileged action is needed afterward, hand off through a separate workflow triggered by a trusted event. This one change neutralizes the majority of this attack class.

2. Use short-lived credentials. Replace static API keys with OIDC-issued tokens scoped to a single job and a single resource. A key exfiltrated one character at a time is only valuable if it is still valid when assembled — a fifteen-minute token usually is not.

3. Allowlist network egress. Default-deny outbound traffic from CI runners and permit only the hosts the job genuinely needs. This is the control that would have made the download-counter channel visible, because the traffic pattern becomes anomalous against a small allowlist even when the host is permitted.

4. Constrain repository permissions per job. Set the default GitHub token permissions to read-only at the workflow level and grant writes only in the specific job that needs them. Least privilege is unglamorous and it works.

5. Gate writes behind human approval. Let the agent plan, comment, and propose freely. Require a human to approve before it merges, pushes, publishes, or provisions. Agentic autonomy and irreversible actions should not share a scope — a principle also central to OWASP's Subtractive Security Top 10.

6. Audit the pre-approved tool list. Enumerate every integration your agent can reach without confirmation and ask what an attacker could observe through it. Tooling for exactly this job is emerging, including NVIDIA's SkillSpector for scanning agent skills.

7. Log and alert on tool invocations. Record every tool call and every outbound host, and alert on anything off the allowlist. Detection matters precisely because the next covert channel will use a service nobody flagged.

How Do You Detect Exfiltration Through a Legitimate Service?

This is the hardest problem on the list, and it deserves an honest answer: you usually detect it by shape, not by destination.

Secret exfiltration through a low-bandwidth side channel produces a distinctive signature — many small, regular requests to one endpoint over a sustained period, where the job's actual work would produce a few large ones. Rate and regularity are the signals. If your CI egress logs capture request counts per host per job, a simple threshold catches the pattern without needing to know which service will be abused next. That is the same detection philosophy behind agent-monitoring work like Microsoft's Project Perception.

Is It Still Safe to Run AI Agents in CI?

Yes, with the controls above in place — and the reasoning matters more than the verdict.

Every one of these findings is a well-understood vulnerability class arriving in a new context: command injection, secret exposure, covert channels. None required novel exploitation theory. That is genuinely encouraging, because it means existing security engineering applies directly rather than needing to be reinvented for agents.

What changed is the threat model's entry point. Untrusted input used to be data your code parsed; with an agent, untrusted input is instructions your code may follow. Design accordingly: assume anything the agent reads may try to steer it, and ensure that even a fully steered agent cannot reach anything valuable.

The disclosure itself is the model worth copying. Researchers tested default configurations, vendors patched before public presentation, and the findings were published with version numbers teams could act on immediately. More of that in our AI security coverage.

Sources: The Hacker News — August 7, 2026; Novee Security — August 2026; eSecurity Planet — August 2026; Hackread — August 2026.