What your board will ask about coding-agent security after the GitHub breach

The headline the board saw

On May 20, GitHub confirmed that a threat actor exfiltrated thousands of its own internal repositories. Not a customer’s repositories. GitHub’s own. The Register and Help Net Security both reported it the same day, and the entry point was almost comically small: one GitHub employee installed a poisoned version of the Nx Console extension on one machine, and a group tracked as TeamPCP walked out with internal source code. The attacker claimed roughly 3,800 repositories. GitHub called that figure “directionally consistent with our investigation so far.”

That is the story a board member forwarded with a one-line subject: “Are we exposed to this?”

In the same 48 hours, two quieter announcements landed that answer the question better than the breach coverage does. 1Password and OpenAI shipped credential isolation for the Codex coding agent. Microsoft open-sourced a security-testing framework called RAMPART. Read together, the three events are one story.

What it actually means

Here is the part worth slowing down for. The thing that breached GitHub was not a coding agent. It was a VS Code extension. But coding agents live in exactly the same place. Cursor, GitHub Copilot agent mode, Cline, and Claude Code all run inside the editor process, with the same reach into the file system, the shell, and whatever credentials the developer has loaded. A security researcher quoted in the Help Net Security report put it plainly: VS Code extensions “have full access to everything on the developer’s machine, including credentials, cloud keys, and SSH keys.” A coding agent has that same access, plus the autonomy to act on it.

I have watched a lot of teams treat the harness as a smaller, safer thing than the editor it runs in. It is not. The harness does not have a narrower blast radius than the breach we just watched. It has the same one.

The two product launches are the industry quietly telling everyone where the controls are moving. The 1Password and OpenAI integration keeps secrets out of the agent’s context window entirely: credentials get issued just-in-time, scoped to a single task, and injected into the running process, never sitting in the prompt or the terminal. Microsoft’s RAMPART does the other half. It lets engineers write adversarial tests, cross-prompt injection chief among them, that run inside CI/CD as the system is built rather than in a pentest months later.

Neither is a product anyone has to buy. Both are evidence of the same shift. Harness security stopped being a point-in-time review and became a continuous-controls discipline. That reframe is what the board is reacting to, even if nobody has said it out loud yet.

Three questions the board will ask

What is our blast radius? If a coding agent’s process were compromised the way GitHub’s editor process was, what would the attacker actually reach? The honest answer for most teams is “every credential on that machine.” The fix is not a better antivirus. It is credential isolation: production secrets kept out of the agent’s context window, issued only when a task needs them. As 1Password’s CTO Nancy Wang framed it this week, “a credential that persists is already compromised.” That sentence belongs in the memo.

Do we test before we ship, or only review after? Cross-prompt injection, where untrusted text in an issue or a comment becomes an instruction the agent obeys, is a known and testable failure mode. Most orgs still catch it, if at all, in code review after the agent has already run. RAMPART-style testing moves that check into the pipeline. The board question underneath is simple: is adversarial testing a gate, or a hope?

Who owns re-testing it? This is the question most teams have not assigned to anyone. Attackers are automating their own testing now.

That study tested a language model, not a coding harness, so read it as a cadence signal rather than a coding-agent finding. The cadence is the point. When one operator can run hundreds of adversarial probes in an afternoon, an annual pentest of the agent workflow is structurally behind. Someone needs to own continuous re-testing, with a named trigger: a model swap, a new harness version, a new MCP server added to the stack.

The 60-second brief

If you have one minute with your board, say this. We do not have a coding-agent breach. We have a coding-agent attack surface, and this week it was demonstrated on the company that builds the tools. The controls that contain it are known and, as of this week, increasingly off-the-shelf: keep credentials out of the agent’s context, test agent workflows adversarially in the pipeline, and name a person who re-tests when something changes. We can report where we stand on each of those three by the next meeting.

That answer does something the breach headline does not. It converts an anxious question into a short list with an owner.

We do not have a coding-agent breach. We have a coding-agent attack surface, and this week it was demonstrated on the company that builds the tools.

What to watch

Watch whether your harness vendor ships these controls or quietly leaves them to you. Credential isolation and in-pipeline adversarial testing are becoming table stakes, and the vendors moving first this week are showing what the 2026 baseline looks like. The teams that handle this well will not be the ones with the strictest policy document. They will be the ones who turned three questions into three named owners, and then went back to shipping.