Beyond Code Generation: Building a Deterministic Control Plane for Autonomous Agents
Autonomous agents can propose code, commands and infrastructure changes faster than a human can review them. The missing layer is not another critic model. It is a deterministic gate that binds the exact proposal to explicit policy, bounded execution and a reproducible decision receipt.
A capable model is not an execution control
Prompt instructions can guide an agent, but they do not create an enforceable runtime boundary. A model may misunderstand a rule, choose a semantically different branch, emit an unsafe import, exceed a resource budget or produce an explanation that sounds compliant while the generated code is not.
Self-critique has the same structural weakness: the system asking whether an action is safe is still probabilistic. Confidence scores, chain-of-thought summaries and a second model can improve review, but none of them prove that the exact candidate satisfied an exact execution contract.
- The proposal must be identified byte-for-byte.
- Policy must be executable rather than implied by prose.
- Runtime limits must fail closed.
- The decision must remain reproducible after the session ends.
The verifier sits between proposal and execution
EvidenceBound treats the agent as a proposal generator and the deterministic verifier as the authority for execution eligibility. The model may generate a candidate, explain it and revise it after a rejection. It cannot manufacture the final verdict or authorize promotion.
The public testbed uses committed, sanitized analytical candidates to demonstrate the same receipt classes that apply to agent-generated actions: accepted bounded execution, branch drift, resource exhaustion and artifact tampering.
AI agent proposal
↓
canonical source + AST
↓
versioned policy contract
↓
bounded deterministic execution
↓
VERIFIED / REFUTED / BLOCKED
↓
content-addressed receipt
↓
human reviewWhy canonical AST matters
Source text is not a sufficient policy boundary. Formatting, aliases and equivalent syntax can obscure what a candidate actually does. EvidenceBound normalizes the candidate into a canonical AST representation and binds that representation to the request and execution intermediate representation.
A policy can then reject structures that are outside the allowed language subset: dynamic imports, subprocess execution, reflective access, unbounded loops, unexpected branches or any node class not permitted by the contract.
- Static policy rejects forbidden structure before runtime.
- Canonicalization reduces ambiguity between equivalent source forms.
- AST identity is retained in the receipt through SHA-256.
- Execution evidence must remain bound to the same candidate and AST.
Bounded execution closes the second gap
Static analysis cannot prove every runtime property. A candidate that passes AST policy may still consume too much time, memory, output or recursion depth. EvidenceBound therefore executes inside a deliberately constrained environment and maps boundary violations to an explicit BLOCKED result.
A timeout is not treated as an unknown success. Fuel exhaustion is not hidden behind a generic exception. Missing evidence remains missing, and a partial run cannot produce a full VERIFIED receipt.
- Execution timeout and startup timeout
- Memory, output and open-file ceilings
- Networkless operation in the isolated deployment profile
- Path containment and tenant-scoped evidence roots
- No automatic promotion after VERIFIED
A receipt is more useful than a screenshot
A screenshot captures what a UI displayed at one moment. A Bounded Decision Receipt preserves the exact request, source identity, canonical AST, execution IR, result, manifest and verdict relationships that produced the decision.
That makes the decision inspectable by a reviewer and reproducible by a CLI. If an artifact changes later, the hash chain exposes the mismatch instead of silently rendering the old conclusion against new data.
evidencebound reproduce ./proof-pack
What the system proves—and what it does not
A VERIFIED result means the exact candidate satisfied the exact declared contract under the retained execution policy and evidence set. It does not mean the model was generally trustworthy, that every future input is safe, or that a deployment is authorized.
This distinction is essential for defensive use. The control plane should make narrow claims that can be reproduced, not broad claims that depend on model confidence or marketing language.
- Proves contract conformance for an exact candidate and request.
- Does not prove universal safety or correctness.
- Does not replace access control, incident response or human accountability.
- Does not grant the agent permission to promote its own output.
The benchmark opportunity
A useful public cybersecurity benchmark can ask models to produce or repair candidates under explicit defensive constraints, then score them with deterministic receipts rather than subjective review alone.
The benchmark can measure policy-violation detection, successful repair after rejection, reproducibility, evidence completeness and the rate at which apparently reasonable proposals cross a forbidden AST or runtime boundary.
The public testbeds replay committed, content-addressed evidence and expose the receipt, hashes, block reason and reproduction command. They do not accept arbitrary uploads or issue production authorization.