Agent Proof Runtime

• 

• 

  APR

• 

• 

• 

  APR

• 

• 

Agent Proof Runtime

Autonomous AI agents can generate impressive software, files, and decisions—but a polished result and a convincing activity log do not prove what actually happened, whether the recorded evidence still matches the output, or whether anything was modified afterward.

Agent Proof Runtime (APR) turns autonomous work into independently verifiable execution evidence.

The agent performs the work. The runtime records the evidence. The verifier checks the proof. The human makes the decision.

What it does

APR Mission Studio accepts a constrained website brief and runs a fixed seven-stage GPT-5.6 pipeline:

Mission Planner Research Agent Content Architect HTML Builder CSS Designer Data Builder QA Agent

The agents produce a genuinely new static website. There is no deterministic template fallback in live mode: the model-authored artifact either satisfies the contract or the mission fails closed.

The exact generated files are then handed to the existing APR trust boundary. APR:

validates a strict checked-in mission manifest; enforces exact artifact paths, media types, file counts, and size limits; materializes only controlled text artifacts; runs 16 deterministic acceptance checks; records a SHA-256 event hash chain; computes an RFC 6962-style Merkle root; writes a self-contained Proof Bundle; invokes an independent deterministic verifier; exposes a disposable Tamper Lab that proves mutations are detected without changing the original run.

A successful live mission reports:

PASSED — the declared mission acceptance criteria succeeded; LOCAL_VERIFIED — the independent verifier recomputed the recorded evidence and found it internally consistent; UNANCHORED — APR honestly does not claim an external signature, HSM, or append-only authority that does not yet exist.

Why it matters

Agent platforms usually optimize for autonomy and output quality. APR focuses on the missing layer: evidence that can be recomputed after the agent finishes.

This matters for developers, security teams, regulated workflows, CI/CD systems, agent marketplaces, and any organization that must answer:

What exactly ran? Which artifacts were produced? Which checks passed or failed? Does the current output still match the recorded execution? Was the event history or critical metadata modified? Is the verdict produced by an independent verifier rather than by the agent itself?

How GPT-5.6 is used

GPT-5.6 is the optional live artifact-proposal provider. The seven sequential stages use the Responses API with strict Structured Outputs, store=False, and bounded retries of up to three attempts per stage.

The browser never receives or displays the API key. The persisted trace records safe identifiers, timing, token counts, summaries, output hashes, handoffs, and artifact metadata—but not API keys, hidden reasoning, raw SDK objects, raw model responses, environment dumps, or chain-of-thought.

GPT-5.6 creates the work. It never decides whether its own proof is valid.

How Codex accelerated the build

Codex was used as the implementation partner across the complete Build Week extension:

repository and architecture inspection; strict mission/provider contracts; the seven-stage Mission Studio orchestration path; structured-output parsing and bounded retries; fail-closed artifact policy enforcement; mocked OpenAI and no-secret-persistence tests; Mission Control UI and animated evidence flow; Tamper Lab integration; adversarial and regression testing; Docker and Railway deployment preparation; documentation, demo script, validation records, and PR-based delivery.

Human architectural decisions remained explicit: APR is not an agent, QA is not the verifier, fixture judging must work without an API key, UNANCHORED must remain honest, and the UI is only a view of evidence—not the source of truth.

Live validation

The complete seven-stage GPT-5.6 path was live-validated on July 18, 2026. It reached QA and APR, materialized all 4 declared artifacts, passed all 16 deterministic acceptance checks, produced a Proof Bundle, and returned PASSED / LOCAL_VERIFIED / UNANCHORED.

Disposable artifact and trace mutations were detected by the independent verifier while the original run remained preserved and locally verified. Persisted files were scanned for secrets and unsafe provider data.

Product experience

Mission Control presents the runtime as one connected PCB-style execution system:

OsaTechGPT → OpenAI / ChatGPT → GPT-5.6 → Codex → seven agents → APR Trust Gate → Proof Bundle → independent verifier

Judges can run the deterministic fixture path without an API key, inspect the hosted Mission Control instance, open generated artifacts, review acceptance evidence and hashes, and trigger Tamper Lab cases.

Supported platforms

CLI, fixture runtime, verifier, and Tamper Lab: Python 3.11 or 3.12 on Windows, Linux, and macOS Hosted Mission Control: Railway Linux container Docker image: non-root runtime with /health probe Optional gVisor backend: Linux Docker host with registered runsc; fails closed when unavailable

Honest trust boundary

APR currently proves local internal consistency. It does not claim semantic truth, hostile-code isolation in the controlled-artifact path, external anchoring, non-repudiation, or hardware-backed trust.

External append-only anchoring, out-of-host signing/HSM support, and stronger hostile-code isolation remain explicit next trust layers.

What's next

external append-only proof anchoring; out-of-host signing and HSM integration; inclusion proofs and supply-chain attestations; hardened multi-tenant execution boundaries; reusable adapters for additional agent runtimes and CI/CD systems.

Proof before trust.

Built With

• codex
• css
• docker
• gpt-5.6
• html
• javascript
• openai-responses-api
• python
• railway