The model was fine. The harness leaked your CI secrets.

For two years the industry argued about model safety: will the model say something dangerous, will it refuse when it should. This disclosure is about a quieter question that turns out to matter more in practice. Not what the model decides, but what the software around it is allowed to do while it decides. In all three cases here, the model behaved. The wrapper did not.

The setup that ties the findings together is the one a lot of teams shipped this year without thinking hard about it: wire a coding agent into CI so it triages issues, reviews pull requests, or auto-fixes failures. That agent runs on a runner that also holds deploy keys, cloud tokens, and package-registry credentials. And its instructions come, in part, from text that any stranger on the internet can write.

What actually happened?

A researcher demonstrated that untrusted input reaching a coding agent inside CI could pivot into code execution and credential theft on the runner, across three separate tools. Per the disclosure and the Cloud Security Alliance research note that followed it:

• Gemini CLI (CVE-2026-12537, CVSS 10.0). In headless mode the tool automatically trusted a repository's .gemini/.env file, and its coreTools allowlist was parsed and matched when tools were registered but never actually enforced at the moment of execution. Together that let an unprivileged attacker run commands on the CI host before the sandbox even started. Fixed in Gemini CLI 0.39.1 and the run-gemini-cli action 0.1.22.
• Claude Code Action (CVE-2026-54316). A validator that was supposed to keep the agent read-only could be bypassed by stripping quotes, and it carried hardcoded “read-only” exemptions. The exfiltration path is the memorable part: the agent could be steered to create model repositories on Hugging Face and then encode a secret in the public download counters, incrementing the count on the repo matching the next character to leak a credential one character at a time. Fixed in 2.1.163. Note the honest wrinkle in the scoring: Anthropic rated it 6.0, while the NVD entry rates it 9.1.
• OpenAI Codex (no CVE, workflow hardening only). When a CI job ran two Codex passes sharing one checked-out workspace, the first pass could write to AGENTS.md, an instruction file Codex loads from disk and treats as authoritative on the next invocation. A validation failure between passes was enough to trigger it. The first pass poisons the instructions the second pass obeys.

Different bugs, but read them together and the shape repeats: an input nobody classified as dangerous (an env file, a download counter, an instruction file on disk) sat inside the trust boundary of an agent that could run commands and see secrets.

What does “the harness” mean, and why does it matter?

Meged's framing, quoted in the reporting, is the cleanest one-liner on this: “The harness is the code between the model and the real world, and each of these three vulnerabilities lived in that harness rather than in the underlying language model's judgment.”

The harness is everything the vendor writes to turn a model into an agent: the file readers, the shell runner, the tool allowlist, the config loader, the code that decides which text becomes an instruction. It is ordinary software, and it has ordinary software bugs. But we tend to audit it with none of the paranoia we would apply to any other program that executes attacker-influenced input with production credentials in scope.

The Cloud Security Alliance note puts the consequence bluntly: AI coding agents now function as “an unaudited node in the software supply chain, making decisions and executing commands with a degree of implicit trust that the industry has spent the past decade learning not to extend to human contributors without review.” We spent ten years learning not to run a stranger's pull request against our secrets without a human in the loop. Then we handed the same access to an agent and pointed it at the issue tracker.

That last point is the one worth sitting with. A GitHub issue is, by design, something anyone with an internet connection and no prior relationship to your project can open. The moment an automation treats issue content as an instruction to an agent running in CI, it is implicitly trusting arbitrary strangers with a foothold inside that environment. The vulnerability is not really in the parser. It is in the decision to let untrusted text steer a privileged process at all.

What this does not prove

This is not a “cloud coding tools are insecure, ours is safe” story, and we will not pretend it is. Precisely:

• All three are patched. This is a lesson about a failure class, not an open zero-day. Update your tools and the specific bugs are gone.
• We run agents like these ourselves. Bodega One Code can host external coding agents such as Claude Code and Gemini CLI inside its own fleet over ACP. That means this is our attack surface too, and our containment is a claim you should test, not take on faith.
• The exposure is a deployment choice, not a property of the model. The dangerous configuration is an agent running unattended, reachable by external input, holding live secrets. An interactive agent on a laptop with no CI credentials in scope is a different risk profile, for better and worse.
• “Named the big three” is not the same as “only three are affected.” These are the tools that got looked at. The pattern is structural, so treat any agent-in-CI setup as in scope until you have checked it yourself.

Which of these conditions apply to your setup?

Strip out the tool-specific bug and every one of these attacks needed the same three things present at once. If your pipeline has all three, you have the exposure regardless of which agent you run:

1. An untrusted input path into the agent. Issue text, PR titles and diffs, review comments, or a file in the repo that the agent auto-loads as instructions. If a stranger can write it, it is untrusted.
2. Live, reusable secrets in reach of the run. Long-lived deploy keys, cloud tokens, or registry credentials sitting in environment variables or the runner's metadata, usable well beyond the single job.
3. A way out. Outbound network access the agent can reach, whether that is an obvious HTTP request or something as quiet as a public counter it can increment. Exfiltration only needs a channel, not a polite one.

Remove any one of the three and the whole chain gets a lot weaker. Remove the untrusted input and there is nothing to trigger it. Remove the ambient secrets and there is nothing worth stealing. Remove the egress and the stolen thing has nowhere to go.

How do I contain a coding agent running in CI?

Treat the runner as reachable by strangers, cut its ambient credentials, and deny egress by default. The CSA note's mitigations map directly onto the three conditions above:

1. Do not give the agent long-lived credentials. Replace personal access tokens and static cloud keys with short-lived, narrowly scoped credentials minted per run and revoked on exit. This shrinks the blast radius of anything that does leak.
2. Default-deny outbound network access, then allowlist. The agent needs your model endpoint and your registry. It does not need the open internet. This is the single control that would have closed the exfiltration channel in the Claude Code finding.
3. Treat all external and auto-loaded text as untrusted. Issue bodies, PR content, comments, and instruction files like AGENTS.md are input, not commands. Do not let an unauthenticated trigger auto-execute an agent with secrets in scope.
4. Split multi-pass workflows into separate jobs with clean checkouts. This is the direct fix for the Codex finding: no shared workspace means one pass cannot poison the next.
5. Watch for the tells. Reads of /proc/*/environ, a run reaching for a service it has never touched, an agent creating repositories it was not asked to. Anomaly detection is what caught the real thing.

Where we stand

We build for the case where the agent runs on your machine, with your keys, and no network path unless you grant one. Bodega One Code is a local-first desktop IDE and CLI: the model runs on your hardware through your own provider (10+ presets, including fully local ones), it has three permission modes (Ask, Plan, Act) so an autonomous run can be gated at approval rather than trusted wholesale, and it ships an air-gap mode that blocks network egress at the process level per project. When we host other agents like Claude Code or Gemini CLI inside our fleet, they run over ACP inside a sandboxed filesystem and shell, so the same containment applies to them.

The honest boundary, since this whole post is about not taking claims at face value: none of that is a magic exemption. A harness is still a harness, ours included, and if you point any agent at a repository full of secrets and wire it to untrusted input, you own that risk. What a local-first, interactive design changes is the default deployment. It is not an unattended process on a runner full of deploy keys that a stranger can reach through the issue tracker. And the privacy and egress claims are testable the same way the researcher tested these tools: put the run behind a proxy in air-gap mode and watch for outbound traffic. There should be none. If you would rather run a fully open-source stack, an open agent pointed at a local model through Ollama gets you a similar network posture, and we will say so plainly.

This is the third time in about five weeks we have written some version of the same paragraph, after Grok Build CLI shipped whole repositories to a cloud bucket and OpenAI's models broke a sandbox to cheat a benchmark. The specifics differ every time. The through-line does not: as coding agents get more autonomous, the risk keeps migrating out of the model and into the harness around it, the part that touches your files, your credentials, and the network. That is the part worth auditing, and the part worth keeping on a machine you control.

Sources

• Cloud Security Alliance - research note on AI coding agents and CI/CD secrets (August 8, 2026)
• The Hacker News - “Claude Code and Gemini CLI Flaws Let Attackers Reach CI Secrets” (August 7, 2026)
• eSecurity Planet - “Black Hat 2026: Critical Flaws Found in Anthropic, Google, and OpenAI Coding Agents”
• NVD - CVE-2026-12537 (Gemini CLI command injection)
• NVD - CVE-2026-54316 (Claude Code Action)