What seventeen production checks proved for AgentProof

Engineering case study · Primary production acceptance 17 October 2026 · Author-published, not independently peer-reviewed

A green AI-agent demonstration is easy to narrate: an agent changed something, a tool returned success and the terminal printed a receipt. The more interesting question is what survived an actual refusal, a lost response and an independent attempt to falsify that receipt.

AgentProof's October 2026 production canary is a narrow example. The end result was 17 of 17 passing live checks, but only after a real identity mismatch stopped earlier attempts before mutation. That failure is integral to the evidence; removing it would make the success much less informative.

What AgentProof actually supports#

The published prerelease @oneclicksystems/agentproof@0.1.0-rc.6 supports one consequential action: agentproof.repository_patch.v1. An agent prepares an exact, allowlisted change against a clean local Git repository; a separate authority signs the prepared transaction; a bounded executor performs the mutation; subsequent repository state is checked; a signer issues an immutable Receipt V2 under explicit trust policy.

The action cannot silently expand itself to commit, push, merge, tag, publish npm packages or deploy. Development authority does not satisfy production policy. The local SQLite ledger and retry protections cover a specific transaction and filesystem scope; they are not a claim of global exactly-once execution across arbitrary external services.

A signed receipt has a narrower meaning than 'the world has changed as intended'. It authenticates the bound statements under a trusted signer. For a consequential outcome, we also need actual postcondition evidence and a clear account of what can remain uncertain.

The first live failure was an identity boundary#

Two authenticated attempts—GitHub Actions runs 39007128303 and 39007674293—passed preliminary checks but failed before the test mutation. The useful diagnostic was HTTP 403 workload_rejected.

The real GitHub repository used an immutable OIDC subject, including numeric owner and repository IDs. The Cloudflare approval service still expected the older name-only subject. Accepting the wrong value to make the test pass would have weakened the workload identity boundary. The repair instead pinned the exact immutable form and added a negative regression for the legacy identity. Other issuer, audience, actor, workflow, protected ref, hosted runner, environment and source-SHA constraints stayed intact.

The correction is visible in AgentProof PR #12, merged as source 47587087565ac312b56909cf7a5d32a4d371d7c4. Both failed attempts and rollback evidence were retained rather than rewritten as part of the later success.

The accepted production subject#

The fresh protected-main run 39008214371 passed 17/17 on that exact source. The experiment used separate Cloudflare approval and receipt-signing Workers with different pre-provisioned Ed25519 secrets. They enforced distinct service roles, pinned source/identity checks and unauthenticated refusal. These were encrypted software-custodied keys, not hardware-backed/non-exportable HSM custody.

The archived production artifact contained the signed approval and two Receipt V2 documents. Its archived JSON SHA-256 was:

f60d0efab65a2c30591e125227e23bd719cb26a7d42449cd0d787cb03971b90a

A separate, read-only verification of that downloaded artifact checked three consequential properties: the first receipt was trusted under a pinned public fingerprint; a compensation successor was correctly linked to its authenticated predecessor; and an orphan successor was rejected. The tested set also included development-policy refusal, approval replay protection, lost-signing-response recovery without re-execution, idempotent effect retry and restoration of the disposable test repository.

In other words, the test did not merely ask whether the happy path could produce a signature. It checked whether an invalid caller and a structurally invalid history would be refused.

The later release experiment is a separate story#

The successful repository-patch canary did not authorise a general release-publishing service. A later, separate agentproof.release.v1 candidate targeted one disposable GitHub draft prerelease with an exact release identity and permanent target fence.

That workflow, 39124373253, recorded one real publication. But the independent receipt signer could not complete its public GitHub readback: attempts failed with public_readback_unavailable. Later attempts recorded zero new publication requests. No release-specific trusted Receipt V2, independent OpsTruth release verdict or DoneState VERIFIED decision followed from those attempts.

The repairs in AgentProof PR #23 and PR #24 remained separate unmerged candidates when inspected on 31 October. Their value is an honest recovery design around the original publication, not permission to publish that target again, reset the permanent fence or extend an expired authorisation.

What I can and cannot claim#

Established for one disposable, pinned repository-patch canary: real approval/signing services refused invalid access; the corrected OIDC subject passed; all seventeen checks succeeded; signed receipts and successor relationships passed separate offline verification; and the test repository was restored.

Not established: generic enterprise approval; HSM custody; a public hosted AgentProof coordinator; merge/deploy/release authority in RC6; broad customer adoption; global provider exactly-once effects; or the separate live GitHub-release-to-OpsTruth-to-DoneState verification path. AgentProof's independent adoption tracker still counted zero observed qualifying external installations, not proof that nobody had installed it.

The practical lesson is a distinction between a cryptographically valid execution record and an independently verified external outcome. Both matter. One does not magically become the other because the service prints success.

Inspect the original evidence#

The recorded evidence refers to the exact tested revisions and dates. Later repository commits must earn their own production-source acceptance; an old successful canary is not a certificate for every future change.

Technical discussion#

I am inviting criticism of this specific evidence boundary: What observation beyond a signed receipt would you require to claim an external effect truly happened? The cross-project conversation is open in Proof & State Discussion #44. No product integration has been agreed; counterexamples, simpler alternatives and reproducible failures are welcome.