The harness-security question landing on your board memo before the June 1 meter

The headline your board saw

On May 28, Anthropic shipped Claude Opus 4.8 with a headline number I have not been able to get out of my head: the new model is around four times less likely than its predecessor to allow flaws in code it has written to pass unremarked. Same day, Anthropic shipped Claude Code v2.1.153 and v2.1.154, two back-to-back patch releases that quietly closed five distinct security bug classes. Same week, GitHub Copilot CLI shipped four pre-releases across thirty-six hours. Same week, OpenAI added an admin Skills page to ChatGPT Enterprise. Five vendor moves in three days. The Cloud Security Alliance picked the same week to republish Darktrace’s State of AI Cybersecurity 2026 survey of more than 1,500 security leaders. That is what landed on the board’s reading list.

What it actually means

Read the Claude Code v2.1.153 and v2.1.154 changelogs side by side and a single mechanism becomes hard to miss. I sat down with both lists Wednesday morning and started counting.

Five distinct security bug classes. Every one of them a written policy that was failing to enforce.

The v2.1.153 release fixed a regression where a custom API gateway could receive a user’s Anthropic OAuth credential instead of the gateway’s own token. The OAuth credential blast radius an admin believed was scoped to the gateway was leaking the user’s credential into it. v2.1.153 also fixed subagent frontmatter MCP servers ignoring strict-mcp-config, the bare flag, remote mode, the enterprise managed MCP config, and the managed-settings MCP server allow/deny policies. Six separate enforcement levers, silently overridden by a subagent frontmatter block.

v2.1.154 fixed four more. The auto-mode classifier was missing data exfiltration on bulk repository transfers. The dangerous-path guard was not blocking rm -rf $HOME when HOME had a trailing slash. Background-session subagents were bypassing the worktree-isolation guard and writing to the shared checkout. A single invalid entry in allowedMcpServers or deniedMcpServers in managed settings was discarding the entire managed-settings policy. The policy did not fail loud. It failed quiet, with no error, with the admin tab green.

That is the bug class the board needs to understand. Not a new exploit. A previously-quiet failure of policy enforcement, named out loud by the vendor in its own changelog.

Three questions your board will ask

Three questions are going to come back at the memo. I have seen each one before, slightly differently shaped, in boardrooms over the last six months. Now they come with a fixed date.

First, which of the five silent-policy-failure bug classes was live in production before May 28, and how does the engineering team prove it was. Each class is named in the changelog. Each has a version number where it stopped happening. The board will want the version the team was on Tuesday, the version it is on now, and the evidence trail in between. If the memo cannot answer “when did our managed MCP allow/deny policy actually start enforcing,” the honest answer is “May 28, today, or whenever we ship the patch.”

Second, how does a developer learn from the CLI when an admin policy is in force. GitHub answered this verbatim on May 27, 21:37 UTC, with Copilot CLI v1.0.55-6: “Show a warning when remote controlled sessions are disabled by organization policy.” Thirteen words, a primitive that did not exist the Tuesday before. The board will ask what the equivalent is in Claude Code, Cursor, and Codex. If it does not exist yet, the team needs a bridge before June 1, because the developer’s experience and the admin’s policy are currently free to disagree silently.

Third, who owns the cross-vendor inventory. Right now there are at least three governance planes in play: managed-settings MCP allow/deny in Claude Code, the extensions_manage tool surfacing per-extension log files in Copilot CLI v1.0.55-6, and the admin Skills page in ChatGPT Enterprise. Each lists a different surface of agent assets. The board memo names one human, not a Slack channel, not a JIRA queue, accountable for keeping the cross-vendor list current and for running the policy-load verification routine before the metered meter starts.

The 60-second brief

If sixty seconds is all the agenda allows, the memo says this. The week of May 27 is when the harness-security register shifted from “vendor risk” to “silent enforcement risk.” Five Claude Code bug classes patched on May 28 prove the admin policy and the harness enforcement were not the same surface. One Copilot CLI primitive (v1.0.55-6) now builds the developer-facing observable. One ChatGPT Enterprise Skills admin page rounds out the cross-vendor admin tenant. And one third-party survey, the Cloud Security Alliance republication of the Darktrace report, lands the rubric: ninety-two percent of more than fifteen hundred security leaders are concerned about the security impact of AI agents. The action item is one named owner and one policy-load verification routine before the June 1 meter activates.

What to watch

Three things to watch this week. Whether the team can verify a managed-settings policy actually loaded after the v2.1.154 patch, not just that the file exists on disk. Whether the equivalent of the Copilot CLI org-policy warning shows up in the Claude Code or Cursor CLI in the next two release cycles. And whether the harness-security line on the June board pack survives a question from a board member who reads the changelog before the meeting.

That last one is the one I keep coming back to. The boards that ask the changelog question are the ones whose engineering leaders are about to be very glad they wrote the memo.