Verification, Not Prevention: Posing the Tractable Problem

Conventional security promises prevention. The discipline tries to stop bad things from happening: block the input, patch the bug, eliminate the vulnerability, harden the surface. Success is measured in absences — no breach, no incident, no exploit landed. The implicit aspiration is a system that should not fail.

A Zero Trust framework for agentic systems refuses this aspiration. It does not promise prevention. It promises something narrower and stranger: that when failures occur, they will be bounded, attested, recoverable, and defensible.

A reader will reasonably ask: why give up on prevention? And then a sharper version: isn’t this just an admission that the discipline can’t deliver what security has always promised?

The answer is no — and the reason is structural, not aspirational. Prevention is not declined out of modesty. Prevention is declined because the prevention problem, in agentic systems, is not solvable in the form it is posed. Verification is. The discipline optimises for the tractable problem.

The Inversion

Two questions look similar on the surface. They are not.

Prevention asks: can we stop every bad outcome before it happens?

Verification asks: can we know, in time, whether any specific outcome was bad?

These are not two ways of approaching the same problem. They are two different problems with two different complexity classes.

Prevention is computationally intractable. To prevent every bad outcome, the discipline would need to enumerate the space of possible inputs (combinatorially infinite in agentic systems — every prompt, every tool call, every agent-to-agent message, every multi-turn unfolding), determine for each whether it produces a bad outcome (which itself depends on context, anchors, and downstream interactions that are not knowable in advance), and block precisely the bad ones without blocking the good ones. The search space does not stop expanding. Each new tool, model upgrade, integration, or anchor change reopens the enumeration.

Verification is tractable. Given a specific outcome, asking whether it was bad is a polynomial-time check. Did the agent produce the disallowed output? Did the action match the stated intent? Did the cryptographic signature validate? Did the decision trail show drift? Each question is bounded — bounded inputs, bounded computation, bounded answer. The verification problem is finite per evaluation, even though the prevention problem is infinite.

This is the inversion. The discipline does not refuse prevention because it is unimportant. It refuses prevention as the primary engineering frame because the primary engineering frame must be solvable.

The Problem Does Not Shrink

A skeptic will press: surely the prevention problem is just hard, not unsolvable. Better models, better filters, better guardrails — incremental progress narrows the gap.

The claim is stronger: the gap does not narrow asymptotically. It expands.

The input space is open. Conventional software has a defined input contract: a typed function signature, a schema, a port. Agentic systems take natural language, tool outputs, peer messages, environmental signals — none of which have a closed grammar. Every new word combination is a potentially novel input. Coverage is asymptotic in a space that itself grows.

The harm function is contextual. Whether a given output is harmful depends on who is consuming it, what action will follow, what state the system was in before, what state it will be in after. The same output can be harmful in one context and beneficial in another. Static enumeration of “bad outputs” is not a stable target.

The adversary adapts. Even if you closed the static enumeration, an adversary watching your filter develops the next-step prompt that produces the same harm by a path your filter does not see. The filter is always a snapshot; the adversary is always present-tense.

These are structural reasons. They will not yield to better models. They are properties of the problem-as-posed, not the engineering-as-attempted.

What Verification Actually Buys

The verification frame does not promise that bad outcomes will not happen. It promises something more useful:

Per-evaluation, you have a bounded answer. This action — was it within mandate? This output — does it carry valid attestation? This decision — does its trail match the verdict structure? Each question takes finite time to answer with finite resources. You can compute it. You can audit it. You can repeat it.

Bounded answers compose. A single verification is one bounded answer. A pipeline of verifications is a sequence of bounded answers, each independent, each auditable. You can build a defence as a chain of bounded checks, where the failure of any check stops the action and surfaces evidence.

Failure leaves a trace. When a verification rejects an action, you have evidence: the input, the verdict, the rule that fired, the path the agent took. The trace is forensic. The next iteration of defence is built from the trace, not from speculation about what might happen.

The discipline approaches the prevention horizon asymptotically. As verifications accumulate — across surfaces, across agent classes, across contexts — the bounded-rejection space grows. The unbounded prevention horizon never closes, but the bounded coverage of it gets monotonically better. Prevention is not abandoned; it is the asymptotic limit that bounded verification approaches as the discipline’s bounded answers accumulate.

What Engineering Catches the Difference

Three patterns hold the verification frame honestly:

1. Pose the bounded problem first. Before designing a control, ask: what bounded check does this perform? What polynomial-time answer does it produce? If the proposed control’s natural form is “stop X” rather than “verify Y in time T”, repose it. Prevention claims that have not been reposed as verification claims will not deliver.

2. Compose bounded answers, do not assert universal guarantees. A defence is a chain of verifications, each independent, each auditable, each bounded. Universal guarantees collapse the moment any one input falls outside the enumerated space. Bounded answers, accumulated, are robust to that collapse.

3. Engineer for the trace, not just the verdict. Every verification produces evidence — the inputs, the rule, the verdict. The trace is the artefact that survives the agent run. Recovery, defence improvement, and forensic analysis all depend on the trace. A verification that rejects without leaving a trace is half a verification.

The Disposition

Conventional security promises absence of failure. The verification frame promises bounded knowledge of failure when it occurs.

This is not a weaker promise. It is a more honest one. The conventional promise cannot be kept in agentic systems — the input space is open, the harm function is contextual, the adversary adapts. A discipline that ships a promise it cannot keep will fail in the field, and the failure will be surprising because the promise hid the structure.

A discipline that ships verification — bounded checks, accumulated coverage, asymptotic approach to the prevention horizon — fails in expected ways. When a bounded verification fails, the trace is there. The next bounded verification can be built from it. The architecture continues working under failure rather than collapsing under it.

This is the inheritance from older traditions of inquiry: pose the question your discipline can actually answer; build the answer rigorously; let the answers accumulate. The bounded warrant is the engineered surface. The unbounded aspiration is the horizon you walk towards, never reaching, never abandoning.