Black Hat 2026: Coding Agents’ Trust Boundary Failures

Novee’s talk at Black Hat USA 2026 didn’t rely on clever model jailbreaks. One carefully written GitHub issue was enough. Remote code execution, API keys, GitHub tokens, and in one case persistent instructions left sitting in the agent’s working files.

They hit Anthropic’s Claude Code, Google’s Gemini CLI, and OpenAI’s Codex—each tested against the vendor’s own repositories under default configurations. Not some exotic third-party setup. The official ones.

What actually broke

Claude Code took the prompt injection from a GitHub issue and turned it into RCE. The agent could read arbitrary files and pull GitHub and Anthropic API credentials. Anthropic assigned CVE-2026-54316 and started shipping patches while the disclosure was still in flight.

Gemini CLI’s problem was its execution restrictions. The assumptions around restricted shell commands and environment isolation didn’t hold up under pressure. Researchers converted the bypass into credential theft and a workable path toward supply-chain compromise. Google gave it a CVSS 10.0 and changed how the tool handles trust in non-interactive environments.

Codex was quieter and more persistent. Writable AGENTS.md files let an attacker drop instructions that survived into later stages of the workflow. Once that file was poisoned, later runs kept following the attacker’s lead. OpenAI hardened the repo workflows and began treating AGENTS.md as untrusted input.

Notice the pattern. In all three cases the model wasn’t the primary failure point. The harness was—the layer that decides which files the agent can touch, which commands it’s allowed to run, and which intermediate files it treats as ground truth. Once that layer accepts untrusted content without verification, everything downstream tends to go along for the ride.

Why this keeps happening

Coding agents need broad permissions to be useful. They have to read the repo, run tests, propose changes, sometimes open PRs. At the same time they swallow large amounts of untrusted text—issue bodies, PR descriptions, comments, and the files they’re supposed to edit.

Most designs still treat that untrusted text the same way a chat window treats ordinary user input. The agent accepts the content, then the rest of the pipeline treats the resulting actions and files as trusted. That’s the same structural gap that keeps showing up in multi-agent systems: missing boundary verification between components.

A recent paper on adversarial attacks in multi-agent LLM pipelines (arXiv 2608.00718) calls the missing piece boundary verification—explicit checks on content, identity, execution intent, and state integrity whenever data crosses from one agent or stage to another. Without those checks, intermediate outputs become implicit trust assumptions. The Black Hat findings are just the single-agent version of that problem. The GitHub issue is the untrusted input. The agent’s internal plan files and tool calls are where that input gets promoted to trusted status.

An attacker doesn’t need to touch the model weights or the cloud provider. They just need a carefully worded issue in a repository the agent is allowed to work on. The agent’s helpfulness and the lack of verification do the rest.

This is also why Excessive Agency landing at number three in the OWASP GenAI LLM Top 10 2026 feels right. The community vote and the incident data are pointing at the same place.

What to change if you’re running these things

Stop treating anything the agent writes as trusted by default. AGENTS.md, plan files, temporary scripts, draft PR content—give all of it the same scrutiny you’d give untrusted network input. Schema validation, strict allow-lists for the next stage, and a human or secondary check before privileged actions fire are the practical controls. In most cases that means inserting a lightweight policy gate between stages instead of letting the agent’s own output become the next system prompt.

Least privilege still works better than most of the other ideas people reach for. The agent shouldn’t inherit the full privileges of a developer laptop or a CI runner. Isolate its workspace, hand out short-lived credentials, and make network and filesystem access something you grant explicitly. Several of the Black Hat failures only became serious because the agent could reach credentials and write outside its intended sandbox.

Treat every GitHub issue—and any other external text—as potentially hostile. Keep that content in the data category, not the instruction category. Prompt-level guardrails have never been enough on their own; the harness has to enforce the separation.

Instrument the agent’s actions the way you would instrument a privileged service account. Every tool call, every file write, every outbound request needs enough of a trail that you can reconstruct what happened. When an agent starts opening PRs or touching production credentials, the audit log should be as readable as the one you already keep for CI service accounts.

None of these controls are exotic. They’re the same operational hygiene we’ve applied to CI/CD and infrastructure-as-code for years. The difference is that the code is now being written—and sometimes executed—by a model that can be steered by the text of a GitHub issue. The controls transfer more cleanly than a lot of teams seem to expect.

Looking ahead

Vendors moved reasonably fast. Patches and trust-model updates are already shipping. That’s good. The harder part is that the basic design pattern—high-privilege agent, large untrusted context, weak checks on intermediate files—is still the default in too many environments.

The same week these findings appeared, the broader conversation about agentic risk kept expanding. The AISI evaluation disclosures and the Paperclip platform CVEs (including a CVSS 10.0 unauthenticated RCE path) all point at related trust-boundary failures. Different products, same underlying pattern: configuration or intermediate state gets treated as more trustworthy than it deserves.

If these tools are already in production, the highest-leverage next step is a short threat model that starts with the harness instead of the model. Map the trust boundaries. Find every place an external document or generated file can influence a privileged action. Close the ones that look most like the failures shown at Black Hat.

Teams building internal agents or evaluating third-party coding assistants should also keep an eye on the emerging public benchmarks. The recent AI Security Leaderboard work shows robustness against composed jailbreaks still varies widely. Claude Fable 5 and GPT-5.6 Sol held up better on that particular test set than some of their peers. Useful context when you’re deciding how much weight to put on the model layer versus the surrounding controls.

Models will keep improving. The open question is whether the systems we put around them improve at the same rate. Right now the evidence from Black Hat suggests they haven’t.