Framework · AI Security

The Verification Ceiling

You can safely delegate exactly as much as you can check

The Verification Ceiling describes the binding constraint on agentic work. Agents made production nearly free — drafts, specs, code, research, analysis — while verification got no cheaper at all. That asymmetry, not model quality, is what caps the leverage a team can actually take. The ceiling is set by the checks you can run, so it is independent of how good the agent is: a better model produces more output to verify, not less. This leaves exactly two moves. Raise the ceiling by building real checks — evals, harnesses, sourcing rules, acceptance criteria. Or lower the delegation until you can check what you hand over. Most organisations do neither, ship past the line anyway, and call the gap velocity. In a security context the same limit governs autonomy: an agent should hold only the authority whose use you can verify, which makes verification capacity, not model capability, the real ceiling on safe automation.

The asymmetry that creates the ceiling

Agents did not remove the work. They relocated it. The cost of producing a draft, a spec, a prototype, a research summary, or a refactor fell to something close to zero. The cost of establishing that any of it is correct did not move.

Everything else follows from that asymmetry. When production is free and verification is not, verification becomes the scarce resource, and scarce resources set limits. The amount of agent output an organisation can safely absorb is capped by the amount it can check.

Why a better model does not raise it

The ceiling is a property of your checking capacity, not of the agent's competence. This is the part teams consistently get wrong. A stronger model does not lift the limit, because it does not make the output easier to verify; it makes more output arrive, and it makes wrong output more fluent and therefore harder to catch.

Waiting for the next model release is not a strategy for raising the ceiling. It is a strategy for raising the delegation.

The only two moves

Raise the ceiling. Build the checks — evals, test harnesses, sourcing rules, acceptance criteria specific enough to actually run. This is now core product and security work rather than an engineering chore to be delegated downward.

Or lower the delegation. Hand over less until you can check more. Unglamorous, unpopular, and correct.

Success is not "we used AI more." It is that you raised the ceiling faster than you raised the delegation. The gap between the two is the honest measure of how much of your output is unverified.

The same limit governs agent autonomy

The security form of this law is a question about authority: an agent should be granted only the authority whose exercise you can verify. Autonomy beyond that point is not automation, it is unmonitored action taken in your name.

This connects directly to blast radius. If likelihood is no longer controllable — see The Likelihood Collapse — then what remains is bounding what an agent can reach, and bounding it to what you can inspect. Verification capacity, not model capability, is the real constraint on how much autonomy a system can responsibly be given.

It also reframes evaluation. The question for an agentic feature is not "how often is it right?" but "when it is wrong, does anything catch it before the consequence lands?" A system with a lower success rate and a working check is safer than a stronger one running unchecked.

How to apply it

Before expanding an agent's scope, name the check. If nobody can state what would catch a bad result, the scope is already above the ceiling, whatever the demo showed.

Measure verification capacity as a first-class metric alongside throughput. Teams instrument how much agents produce and almost never instrument how much of it was actually checked.

Treat fluency as a risk signal rather than a quality signal. When ten plausible options become free, judgment stops being a soft skill: the failure mode of agentic work is confident, well-written, wrong.

The Verification Ceiling was introduced by Asaf Nakash, Principal Product Manager for AI Security at Microsoft Defender and host of the Context Window podcast, in The Agentic PM (July 31, 2026).

Common questions

What is the Verification Ceiling?

The Verification Ceiling is a term coined by Asaf Nakash, Principal Product Manager for AI Security at Microsoft Defender, for the hard limit on safe delegation to AI agents: you can safely delegate exactly as much as you can check. Past that line you are not managing the work, you are hoping. Because the limit is set by your ability to verify rather than by the agent's ability to perform, it does not move when the model improves.

Why doesn't a better model raise the Verification Ceiling?

Because the ceiling is a property of the checking side, not the producing side. A stronger model generates more output per unit of time and makes incorrect output more fluent, so it increases both the volume and the difficulty of verification. It raises how much you are tempted to delegate without raising how much you can confirm. Waiting for a better model raises delegation, not the ceiling.

How does the Verification Ceiling apply to AI security?

It sets the ceiling on agent autonomy. An agent should hold only the authority whose exercise can be verified, so verification capacity — not model capability — determines how much autonomy a system can safely be given. It reframes evaluation away from "how often is the agent right?" toward "when it is wrong, does anything catch it before the consequence lands?" An agent with a lower success rate and a functioning check is safer than a stronger one operating unchecked.

What are the two responses to the Verification Ceiling?

Raise the ceiling or lower the delegation. Raising it means building checks you can actually run: evals, harnesses, sourcing rules, and concrete acceptance criteria. Lowering delegation means handing over less work until your checks catch up. Most organisations do neither, delegate past the line, and describe the resulting unverified output as velocity.

Where was the Verification Ceiling introduced?

Asaf Nakash introduced it in The Agentic PM, a talk and published presentation on what product management looks like when agents do the producing. The presentation states the law, derives the Frame, Delegate, Verify, Own loop from it, and ships the working files needed to apply it. It is published in both a human edition and a machine-readable edition intended to be read directly by agents.

Where this comes from

#23 · You Can't Lower the Odds Anymore. Lower the Blast Radius.#25 · The Guard, Not the Wall