Securing AI-Speed Development: Governing Output You Cannot Review

The argument for securing AI-speed development usually opens with a multiplier. Teams using AI assistance ship 10 to 50 times more code, the claim goes, so vulnerability management has to be reinvented. The strain that framing points at is real and worth taking seriously. The number is not a measurement, and it is worth saying so before building a program on it. What follows is an attempt to separate the two: which part of the AI-speed problem is a genuine change in kind, which part is a familiar queueing problem wearing new clothes, and which of the two the standard recommendations actually address.

Where the multiplier comes from, and what it is worth

The 10-to-50-times figure circulates in vendor material, conference abstracts, and webinar promotion, generally without a published methodology, sample size, or definition of what is being multiplied. That last omission matters most. Lines of code, commits, pull requests, and shipped features behave very differently under AI assistance, and a fivefold spread between the low and high end of a range is a reliable sign that no single quantity is being described. A claim that permits any value across that band is not constraining anything.

None of which makes it useless. As a description of felt strain it lands, because the asymmetry it points at is straightforwardly true: output capacity became elastic and review capacity did not. A team can double the code it produces in a quarter. It cannot double the number of engineers who can competently review a security-sensitive diff. Treat the multiplier as a statement about that asymmetry, and do not treat it as a baseline. Our own read of what practitioners are actually hitting is in the state of enterprise AI security 2026, and the runtime-side version of the same tension shows up across the agentic runtime governance survey data.

Four numbers worth more than the multiplier

Every one of these is obtainable from systems you already run, and each one degrades in a way you can act on.

The fourth is the one most organizations cannot answer, and it is the most important of the four. Every AI CLI, MCP server, skill, and editor extension with a token attached is an actor that can take an action. Counting them is the exercise in how to build an AI agent inventory and, for the connector layer specifically, how to build an MCP server registry. Teams that run the count for the first time are usually surprised by the total, which is itself the finding - the population grew without anyone deciding it should, the dynamic described in AI agents are the new shadow IT.

Two risks arrive together, and only one is about code

This is the distinction the volume framing obscures, and getting it wrong sends teams to the wrong controls.

Category one: vulnerabilities in generated code. An agent writes a query that concatenates a string, omits an authorization check, or deserializes untrusted input. This is a code-quality problem. It is genuinely worse at higher volume, but it is not a new kind of problem, and your existing pipeline is the right place for it. Scanning, review, and dependency policy all apply, and the honest adjustment needed is one of throughput rather than mechanism.

Category two: actions the agent takes. The agent installs a package, reads an environment variable, calls a cloud API, edits its own configuration, connects a new MCP server, or runs a shell command. None of this appears in a diff. It happens on a developer laptop, in the agent's own session, often hours before a pull request exists and sometimes with no pull request at all. Your pipeline has no visibility into it, not because the pipeline is weak but because the pipeline is downstream of it. The recent record is unambiguous about this being where real losses occur: the Solidity Pro extension credential theft took SSH keys and cloud tokens off developer machines, the Zenity agent skill registry campaign instructed agents to harvest and exfiltrate the same set, and GhostJacking rewrote production DNS using nothing but actions an agent was already permitted to take. Not one of those is a code-quality finding.

Category two is what is actually new. A code generator that produces flawed code faster is a scaling problem. An autonomous process with credentials, network access, and shell access, running on a laptop outside every pipeline control, is a different category of thing. The lifecycle implications are worked through in the agentic development lifecycle guide.

Why CVE-driven remediation degrades rather than scales

The critique of CVE-driven remediation under AI-speed development is correct, and the reason is queueing rather than anything specific to AI. Scanning produces findings; engineers service findings; when the arrival rate exceeds the service rate the queue grows without bound. More scanning at that point makes the backlog worse while feeling like progress. Aging findings crowd out new ones, and prioritization collapses into whatever is loudest rather than whatever matters.

The interventions that help are the ones that reduce arrivals, not the ones that process the queue faster. That is the substance behind "secure by default" once the phrase is unpacked, and it is worth being concrete about what it means when the author is an agent rather than a person. Agents follow the shortest path to a working result with more consistency than humans do, which is a liability when the shortest path is unsafe and an asset when it is not.

• A curated internal registry. A hallucinated dependency name should fail to resolve rather than pull whatever an attacker registered under it. This is the direct control for slopsquatting and hallucinated package installs, and it removes an entire finding class at the source.
• Safe scaffolding. Templates and project generators that already contain the parameterized query, the authorization check, and the safe deserializer. An agent extending a safe pattern produces safe code; an agent extending an unsafe one produces more of the unsafe pattern.
• Feedback the agent itself consumes. Linters, type checks, and security rules wired into the agent's own loop so unsafe output is rejected and rewritten before a human sees it. Findings surfaced to the agent are cheaper than findings surfaced to a reviewer.
• Constrained tool permissions. Which commands an agent may run without asking, defined explicitly rather than accumulated by convenience. The mechanics are in the Claude Code permissions and hooks hardening guide and compared across tools in Claude Code vs Codex vs Cursor permission models.
• Dependency provenance as a gate rather than a report. Given the frequency of campaigns in the AI supply-chain defender's guide, a new transitive dependency arriving via an agent-authored commit deserves a decision, not a line in a dashboard.

Why slowing developers down does not work

The common counsel is that slowing developers down is not the answer, and the reasoning usually offered - companies adopted AI to move faster - is the weaker of the two available arguments. The stronger one is that friction does not get absorbed, it gets routed around, and the workaround is worse than the thing it replaced.

We see the evidence for this in real configurations. Approval prompts that fire too often produce a bare shell tool on the permit list, which converts the most powerful capability an agent has into a no-prompt path. They produce a skip-permissions flag pinned in a shell profile, documented in what Claude Code's dangerously-skip-permissions flag actually does. They produce auto-run enabled with an allow list that does not constrain what people think it constrains, covered in Cursor auto-run and the limits of allow and deny lists. The aggregate pattern across configurations we have examined is in what we found scanning AI configs, and it is consistent: a control that demands a decision in the moment gets disabled, and then reads as present in policy while being absent in practice.

Constraints that survive are the ones requiring no in-the-moment decision. A dependency that cannot resolve. A template that is already safe. A hook that denies a category of call outright rather than asking. Reserve interactive approval for the small set of actions where a human genuinely adds judgment - destructive operations, production credentials, infrastructure state changes - which is the boundary drawn in preventing destructive agent operations and least privilege for AI agents.

The attacker-parity argument, narrowed

The claim that attackers also have powerful models, compressing defensive response windows, is true and usually stated too broadly to act on. The specific version worth planning against is that AI lowers the cost of the labor-intensive parts of an attack: producing many plausible typosquatted package names, generating convincing documentation for a malicious skill, iterating on a payload until a model accepts it. The GhostJacking research included exactly that last technique, refining an attack against refusals until another instance complied. Volume-based attacker economics is what the reserved-name staging in the Zenity campaign reflects, and it is why treating a takedown as closure is a mistake.

What it does not mean is that defenders need an AI-versus-AI arms race in their detection stack. The controls that blunt cheap-attack-volume are unglamorous: allowlists rather than blocklists, curated registries rather than open resolution, and enforcement at a boundary the attacker's content cannot argue past. A model-generated attack still has to make a tool call, and a tool call is where a decision can be made.

Who owns this

The governance recommendation attached to this argument - clarify risk ownership, escalate to board-level accountability - is sound and easy to implement badly. The characteristic failure is making a security team accountable for an outcome it has no lever over, while the platform team holds the levers and is measured on velocity. Every effective intervention above is a platform decision: the registry, the scaffolding, the agent permission policy, the hook configuration. If security owns the outcome and platform owns the mechanism, nothing moves.

The practical test is narrow. Which single named role can change a default and make it stick across every team? That is the owner. Everything else is a reporting line. Board attention is reasonable given the exposure, and framework mappings for it are in the AI governance framework for enterprises and ISO 42001 for AI agent governance, with the written-policy layer covered by the AI acceptable use policy template for agents and MCP. A policy nobody can enforce a default from is documentation, though, not governance.

How Anomity governs the half your pipeline cannot see

Anomity does not review code and does not compete with your SAST, your dependency scanner, or your pull request gate. Those own category one and should keep it. Anomity covers category two: what the agent does on the endpoint, before and outside the pipeline. A lightweight, unprivileged Endpoint Sensor inventories eight AI artifact types per machine - agents, MCP servers, skills, extensions, plugins, hooks, CLIs, and secrets - which produces the fourth measure from the table above, the count of autonomous actors holding credentials. It transmits metadata only over HTTPS, never source code and never prompts, with secrets redacted on the endpoint before anything leaves.

On agents that expose a hook such as Claude Code's PreToolUse, runtime governance returns allow, deny, or log on each tool call before it runs. That is the enforcement point the pipeline cannot reach, and it is where a dependency install, a credential read, or an outbound request gets a decision rather than a retrospective finding. Every added, changed, and removed artifact lands in a queryable 90-day audit trail, which is what lets you answer what an agent did during an incident window instead of inferring it from commit history. Violations route to your SIEM, Slack, email, and Jira through continuous policy evaluation, and the fleet-wide rollout patterns are in governing AI coding assistants across your fleet and securing AI coding agents and CLIs.

Volume is a throughput problem your pipeline can be scaled for. An autonomous process with credentials, running outside that pipeline, is not.Anomity Research

What to do this quarter

• Stop quoting the multiplier and measure your own four numbers: PRs per reviewer, mean diff size, review latency, and the count of agent identities holding credentials.
• Separate your backlog into generated-code findings and agent-action risks, and route them to different owners. Conflating them is why neither gets fixed.
• Point a curated internal registry at your agents so an unresolvable dependency name fails closed rather than resolving to whatever was registered.
• Audit agent permission configuration for accumulated convenience: bare shell tools on permit lists, skip-permissions flags, and auto-run allow lists that do not constrain what they appear to.
• Establish the tool-call boundary as an enforcement point on any agent that exposes a hook, and reserve interactive approval for destructive actions, production credentials, and infrastructure state changes.
• Name one role with authority over both platform defaults and security controls, and test the choice by asking whether that role can change a default across every team.
• Confirm you could answer what a given agent did during a two-week window last month. If the answer requires inference from commit history, close that gap before adding scanning capacity.

The honest version of the AI-speed argument is narrower than the multiplier suggests and more actionable for it. Your pipeline can be scaled to handle more code, imperfectly but genuinely. What it cannot do is see an agent read a credential on a laptop at 2pm and use it at 2:01, because that never becomes a diff. Governing AI-speed development means covering both halves and knowing which half each control belongs to. To see how many agent identities hold credentials across your fleet today, and what runtime governance would have denied, book a 30-minute demo.