# What seventeen production checks proved for AgentProof By ayobamih Canonical: https://aiworkaccountability.com/writing/what-seventeen-production-checks-proved-for-agentproof/ Published: 2026-10-31 Updated: 2026-11-01 *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](https://github.com/AyobamiH/agentproof/actions/runs/39007128303) and [39007674293](https://github.com/AyobamiH/agentproof/actions/runs/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](https://github.com/AyobamiH/agentproof/pull/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](https://github.com/AyobamiH/agentproof/actions/runs/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](https://github.com/AyobamiH/agentproof-release-canary/actions/runs/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](https://github.com/AyobamiH/agentproof/pull/23) and [PR #24](https://github.com/AyobamiH/agentproof/pull/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 - [AgentProof repository and published RC6 instructions](https://github.com/AyobamiH/agentproof). - [Real OIDC refusal and exact-identity fix — PR #12](https://github.com/AyobamiH/agentproof/pull/12). - [17/17 protected-main run #39008214371](https://github.com/AyobamiH/agentproof/actions/runs/39008214371). - [Production canary acceptance record and trust boundaries](https://github.com/AyobamiH/agentproof/blob/main/docs/evidence/hosted-production-canary-acceptance-20261017.md). - [Receipt-evidence archival and scoped closeout — PR #13](https://github.com/AyobamiH/agentproof/pull/13). - [The separate unfinished release-recovery PR #24](https://github.com/AyobamiH/agentproof/pull/24). - [Independent installation/adoption tracker — issue #14](https://github.com/AyobamiH/agentproof/issues/14). - Related site reading: [A parked agent is not a finished job](https://aiworkaccountability.com/writing/a-parked-agent-is-not-a-finished-job/). *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](https://github.com/AyobamiH/proof-and-state/discussions/44). No product integration has been agreed; counterexamples, simpler alternatives and reproducible failures are welcome. Original author-published engineering case study by Ayobami John Haastrup (ayobamih). Drafting and evidence organisation used AI assistance. Historical findings are scoped to the cited tests and provider observations; not independently peer-reviewed. No new execution or provider effect was performed for this article.