There is a number in a survey published on June 2 that I keep turning over, not because it's surprising, but because of the second number sitting right next to it. Salt Security's new research — AI Coding Assistants and the New Security Challenge, fielded by Censuswide across 100 IT security leaders in the UK and US between May 12 and 15 — reports that nearly half of enterprise code is now generated by AI assistants. Fine. We knew the share was climbing. The number I can't put down is the one a few lines later: 38% of those leaders say they rely primarily on manual review to catch problems in that AI-generated code.

Hold those two figures side by side. Machines are writing half the code. Humans, reading line by line, are the primary safety net for what the machines write. Calling that a governance strategy gives it too much credit; it's a category error, and I want to walk through why — and then through the specific flaw that makes the error concrete rather than theoretical.

The throughput mismatch nobody priced in

Start with the arithmetic, because the arithmetic is the whole argument.

Manual code review is a human activity with a human throughput ceiling. A careful reviewer reads code at roughly the speed of careful reading — and the research on review effectiveness has long suggested that defect-catching drops off sharply past a few hundred lines per session and an hour of attention. That ceiling didn't move when the authoring side got an engine bolted to it. The author got faster by an order of magnitude; the reviewer got a coffee.

Picture a single conveyor belt with two stations. The first station used to be staffed by a person placing items on the belt at a person's pace. Someone swapped in a machine that places items roughly ten times faster. The second station — inspection — is still a person, working at exactly the speed they worked before. You don't need a degree in operations to see what happens to the belt. Either the inspector waves things through to keep up, or the belt backs up until someone quietly turns inspection off. In software, "waves things through" and "quietly turns it off" look identical from the outside: a green checkmark.

So when 38% of teams say manual review is their primary control, what they're really describing is a control that was sized for a pre-AI authoring rate, now asked to cover a post-AI one. The Salt numbers around it tell the same story from other angles — 67% report widespread adoption across their dev teams, 29% name insecure coding patterns as the leading risk, 15% flag misalignment with internal security policy. Roey Eliyahu, Salt's CEO, put it about as plainly as a vendor ever does: "governance has not kept pace... many are still trying to manage AI-generated code using security processes designed for a pre-AI world."

I'd go one step further than "hasn't kept pace." The pre-AI process was never slow — it was correctly sized for a different machine. Review isn't merely behind the authoring rate. For this particular risk, review was never the layer where the risk lives at all.

Where manual review isn't even in the room

Here's the part that turns the throughput argument from "stretched thin" to "structurally absent." Some of the failure modes AI coding agents introduce don't pass through human review at all — not slowly, not partially, but never, by design.

Consider TrustFall, disclosed by Adversa AI in early May and affecting Claude Code, Cursor, Gemini CLI, and GitHub Copilot's CLI. I wrote a few days ago about SymJack, where the approval prompt described one operation while a symlink made the kernel perform another. TrustFall is its cousin, and the cousin is worse in a way that matters here.

The mechanism: a malicious repository ships its own MCP server and pre-approves it via the repo's own .claude/settings.json. Because the MCP-enabling settings — enableAllProjectMcpServers, enabledMcpjsonServers — aren't gated behind the red warning dialogs that block other dangerous settings, a single Enter keypress on the folder-trust prompt spawns that server as an unsandboxed OS process with the developer's full privileges. One keypress on a developer's laptop is bad enough. But the line that should stop a security leader mid-coffee is the next one: on a CI runner executing the agent headless — the default for the official claude-code-action — the trust dialog is never rendered. It doesn't get clicked through. It doesn't exist. The same attack runs against pull-request branches with zero human interaction.

Now re-read "we rely primarily on manual review." There is no human at a CI runner. There was never going to be one. The control a third of teams named as primary is, for this entire class of failure, not under-resourced — it's not present in the execution path. You cannot manually review an event that happens, by design, while no one is looking.

This is the distinction I think the survey's framing slightly blurs. There are two different governance gaps wearing one label:

  • The throughput gap — review exists in the path but can't keep up with the authoring rate. Stretched too thin.
  • The path gap — review isn't in the execution path at all, because the agent acts in places (headless CI, autonomous triggers) where human review was never a step.

Manual review can, in principle, be scaled against the first. Hire more reviewers, shrink the diffs, slow the belt. It can do nothing against the second, because the second isn't a staffing problem. It's an architecture problem.

What actually sits in the path

If the human isn't in the path, what is? The honest answer for most small teams right now is: a green checkmark and some hope. But the better answer — the one the better-resourced shops are converging on — is that the controls have to live where the agent lives, not where the human used to.

That means a few concrete moves, and the encouraging thing is that none of them require a FinOps team or a security org:

Pin the settings the agent reads. TrustFall is, at its root, a settings-scope inconsistency: project-scoped settings that should have required a warning didn't get one. Claude Code's own remediation path is endpoint-managed or server-managed settings — a baseline pushed from the admin console or via MDM that a cloned repo's .claude/settings.json cannot override. Disable project-scoped MCP auto-approval. Allowlist the MCP servers you actually use. Pin permissions.allow to a known baseline. This is the equivalent of bolting down the inspection station so a passing item can't reconfigure it.

Treat the CI runner as the most dangerous seat in the house, not the safest. The instinct is to trust CI because it's automated and reproducible. Invert that. The CI runner is precisely where human judgment is absent and credentials are abundant — every deploy key, every registry token, every secret your pipeline has ever needed. An agent running headless there has the worst combination of high authority and zero supervision. Scope its credentials to the job, not the project. Assume the runner is the blast radius.

Move the check to a layer that doesn't tire. Manual review's ceiling is human attention. The class of control that doesn't have that ceiling is the one that runs at machine speed against machine output: dependency and settings scanning in the pipeline, policy-as-code that fails the build on a disallowed MCP config, network-egress observation that flags a process phoning home. None of these are smarter than a good reviewer. They are simply present — at the runner, at 3 a.m., on the pull-request branch nobody opened.

The pattern under all three is the same one I keep arriving at from different directions: when the thing you're governing operates without you in the loop, your control has to operate without you in the loop too. A safety net only catches what falls through the part of the floor it's stretched under. AI agents have started walking on floor the net was never hung beneath.

The takeaway

The Salt survey will get summarized as "90% of security leaders are worried about AI code," and that headline is true and roughly useless — of course they're worried. The useful reading is the adjacency of the two operational numbers: half the code is machine-authored, and a third of teams are still pointing a human-shaped control at it as their primary defense. The worry is calibrated. The control is not.

If you run a small team and you read only one thing into this, make it the inversion: your CI runner is not your safest environment, it's your least-supervised one — and "we review everything before it merges" quietly stops being true the moment an agent can act before the merge, or without one. What's the first place in your pipeline an AI agent can take an action that no human will see before it happens? Find that line. That's where your governance actually needs to be, and it's almost certainly not where your reviewers are sitting.