proofbundle: independent audit of the trusted core behind AI evaluation receipts

Likely AI-generated. Pangram flags 100% of this text as AI-written.

proofbundle: independent audit of the trusted core behind AI evaluation receipts

Technical AI safety AI governance Global catastrophic risks

Konrad Gruszka

ProposalGrant

Closes August 13th, 2026

$0raised

$5,000minimum funding

$12,000funding goal

Offer to donate

21 daysleft to contribute

You're pledging to donate if the project hits its minimum goal and gets approved. If not, your funds will be returned.

Project summary

Upfront: this text was AI-drafted under my direction. I prepared, reviewed and corrected every line; the AI is my instrument, and the claims and the evidence behind them are mine. Verifiable AI work is exactly what this project exists for.

AI safety evaluations increasingly produce numbers that later influence reports, deployment decisions and governance discussions. Today those numbers are often just claims. proofbundle turns an AI evaluation result into a portable, signed, offline-verifiable evidence receipt: anyone can later check who claimed what, whether the artifact changed, and which samples or commitments the claim covers.

It does not prove that the evaluation was correct. That boundary is intentional. proofbundle provides authorship, integrity and auditability for the evidence layer underneath AI safety claims.

This grant funds an independent security review of the trusted core: verification logic, canonicalization, signature and disclosure checks, bundle parsing. The project is at audit-candidate maturity, with 2017 tests behind a mutation gate and adversarial release gates that already caught two false-accept bugs, both fixed and disclosed in the changelog. Three independent implementations agree on all verdicts across the public conformance vectors, and independent reviewers keep finding real seams, which is exactly the point of working in the open. A paid, professional audit is the missing piece before third-party evaluators, researchers and governance teams can rely on the receipt format without trusting me or a server.

What are this project's goals? How will you achieve them?

Goal: publish an independent security audit of proofbundle's trusted core and turn the findings into remediated, regression-tested open-source infrastructure.

Milestones:

1. Freeze the audit scope

verification logic, bundle parsing, canonicalization, SD-JWT selective disclosure checks, anchor verification, CI and release provenance.

2. Run the independent review

commissioned directly from an independent security reviewer with applied-cryptography experience, selected transparently. OSTIF reviewed an inquiry and declined at this stage (they focus on widely-used infrastructure), with an explicit invitation to return as adoption grows; their published audit-preparation best practices, written with Least Authority, are the baseline this project already follows. The reviewer does not start from zero: the public conformance corpus with digest-pinned cross-implementation vectors, verified by three independent implementations, is a ready-made adversarial test bed.

3. Remediate every confirmed finding

each fix gets a regression test, mutation or fuzz coverage where appropriate, and a public changelog entry. This is established practice here, not a promise: the two false-accept bugs our own adversarial gates caught were fixed and disclosed exactly this way.

4. Publish the result

audit report, fixed release, updated threat model, and a 30-minute reviewer path for funders, auditors and AI safety researchers.

Success means a third party can inspect the code, reproduce the verification path, and decide whether proofbundle is safe enough to use as an evidence layer for AI safety evaluation claims.

How will this funding be used?

Entirely toward the audit.

At the $5,000 minimum:

- scoping the review and selecting the auditor, following OSTIF's published audit-preparation best practices

- first focused review pass of the trusted core

- initial remediation of confirmed findings

- public progress update and scoped audit plan

At the $12,000 goal:

- broader review coverage across parsing, canonicalization, SD-JWT checks, anchors, CI and build provenance

- complete remediation pass with regression tests

- public audit report

- hardened release and updated reviewer documentation

The grant is for the audit and maintainer remediation work only. No marketing, no unrelated development, no private product work. Applications to other funders (GitHub Secure Open Source Fund, LTFF) cover strictly disjoint scopes, maintainer time for hardening and standardisation, not this audit; no cost is requested twice.

Who is on your team? What's your track record on similar projects?

I am the sole maintainer. Everyone named below is independent, not part of a team I direct.

Since submitting this proposal, proofbundle went through three release cycles: 3.3.0 added the relation layer, 3.6.0 became the audit candidate with 1848 passing tests, and the 3.6.1/3.6.2 security patches brought the suite to 2017 tests. The two patched issues were false-accept verdict bugs that our own adversarial release gates caught; both are named in the public changelog.

The part I am most confident about is that the project is built to be checked rather than believed. There is a public threat model, a formal spec, a security policy, a reviewer path, maintainer governance, mutation-gated tests, and offline verification against external RFC 6962 vectors and real Sigstore Rekor artifacts. There are no custom cryptographic primitives.

The external signals have grown. An independent developer reproduced proofbundle's canonicalization and content-root binding byte-for-byte in his own Go implementation and graduated our shared vectors into his suite; by now three independent implementations agree on all verdicts across the six public conformance vectors, with OpenTimestamps proofs confirmed on Bitcoin (most recently block 958761) that verify fully offline. Separately, an independent reviewer replayed our review instruments and found a real seam in our conformance measurement; I conceded it publicly in the same thread, and the fix is in progress. The in-toto maintainers are actively engaging with the eval-result attestation predicate that proofbundle reference-implements. That is the working culture this grant would fund an audit of.

What are the most likely causes and outcomes if this project fails?

The project can fail commercially and still produce useful public goods: a published security review, hardened open-source verifier code, reusable conformance vectors, and a clearer threat model for AI evaluation receipts.

The main conceptual risk is not that proofbundle proves too little. It is deliberately narrow. The risk is that users overread a valid receipt as proof that an evaluation was correct. This is why the threat model, CLI output and docs separate CRYPTO OK from policy, assurance level and limitations, and why the project maintains explicit non-claims.

Two practical risks are worth naming. First, this is currently a single-maintainer project. The mitigations have grown since the original proposal: a small trusted core, public governance, and by now a digest-pinned public conformance corpus verified by three independent implementations, which means the format can be reviewed, reproduced or continued without me. Second, OSTIF declined at this stage (they focus on widely-used infrastructure) with an explicit invitation to return as adoption grows, so sourcing the right reviewer at this budget is my responsibility; the scope is deliberately small to keep a focused review affordable. And if the audit surfaces serious findings, that is the grant working as intended: every confirmed finding gets a public fix and a regression test.

How much money have you raised in the last 12 months, and from where?

$0 raised externally so far. The project has been entirely self-funded out of pocket, covering running costs (rented GPU compute, GitHub, AI tooling, and my own hardware for local development) plus all maintainer time.

The funding picture has widened since the original text, so here is the full disclosure. Pending, nothing committed yet: a grantmaking.ai launch-round submission (7 July 2026), an application to the GitHub Secure Open Source Fund (20 July 2026, trusted-core hardening and a documented threat model), and an application to the Long-Term Future Fund (20 July 2026, maintainer time for standardisation, the conformance corpus and eval-harness integrations). All of these scopes are strictly disjoint from this audit grant; no cost is requested twice, and any award will be disclosed here. A prepared NLnet application was never submitted: the fund's final call closed without a successor, and its content moved into the applications above. A Foresight Institute Berlin Node application is planned (deadline 30 September 2026). OSTIF was contacted about facilitating the audit and declined at this stage (they focus on widely-used infrastructure) with an explicit invitation to return as adoption grows; their published audit-preparation best practices remain the baseline, and the reviewer will be commissioned directly. GitHub Sponsors is set up but has produced no recurring income.

Konrad Gruszka

3 days ago

Second update, and the external side is now the main story.

Since the last note, proofbundle moved from the v2.1.0 era to a hardened 3.6.2. Two release lines did the work: 3.6.0 became the audit-candidate, consolidated behind an independent Rust second verifier and a fuzz-clean surface (1848 tests), then two security patches followed. I want to be plain about why they existed: our own adversarial passes found two false-accept verdict bugs in 3.6.0, a subject-pinning fail-open that could reach VERIFIED and a canonicalization path that could accept a non-canonical but validly signed statement. 3.6.1 closed both, 3.6.2 followed mutation-gated with the release chain digest-verified end to end (2017 tests). All of it is in the changelog.

The Colin interop I flagged last time has landed. The decision-receipt vector that still needed regeneration now conforms to the strict v0.1 schema, its OpenTimestamps proof is Bitcoin-confirmed at block 958761, and it has graduated into the conformance corpus as the cross-implementation case. Three independently built verifiers, proofbundle's Python and Rust plus Colin's, now agree byte-for-byte on the same cases, including the deliberately broken ones. He also contributed a set of transparency-log anchor vectors, cross-run against our fixtures with his Go and Python verifiers and ours, with no divergence.

The part that matters most for an audit grant is the second reviewer. An independent reviewer (No Silent Landing) reviewed the shared conformance candidate from the bytes upward and found a real seam: our report claimed a six-of-six conformance result that does not actually reproduce from the committed measuring instrument, which produces five of six, even though the underlying security behaviour was correct. I reproduced the finding from our own source, conceded it publicly, and a successor iteration is fixing the measurement layer so the delivered result provably derives from the committed code, before anything is adopted. The security fix held; the measure itself asked for another pass. That is not a setback. It is the exact function of independent review, and it happened in the open.

Upstream, the eval-result attestation predicate this work is built on is now in active discussion with the in-toto maintainers, with a real worked example verified in the thread.

The grant stays scoped to the same thing: an independent security review and remediation of the trusted core, verification logic, bundle parsing, canonicalization, SD-JWT checks, anchor verification, CI and build provenance, and threat-model alignment. What has changed is that the trusted core is firmer, and independent eyes are already on it and already finding things. That is the case for funding it properly.

Konrad Gruszka

12 days ago

Project update:

When I submitted this grant request, proofbundle was already a small offline verifier for AI evaluation receipts. Since then, it has reached v2.1.0 with decision receipts, universal content roots, and the anchors[] verification layer. That release was verified with 683 passing tests, clean lint, and a reproducible build.

The more important change is external: an independent developer, Colin from MarkovianProtocol, started building decision-receipt and OpenTimestamps interop vectors against proofbundle’s canonical path. I did not want to claim this as progress until there was something concrete to check.

That work is now being moved into the conformance path. One vector carries an upgraded OpenTimestamps proof confirmed at Bitcoin block 957504 and can be checked offline. Another reproduces proofbundle’s canonical bytes byte-for-byte, but still needs regeneration before it satisfies the strict v0.1 predicate schema.

I see that mixed result as useful, not as a problem. It shows exactly why the audit matters: proofbundle must clearly separate what verifies, what does not yet verify, and where the trusted core must fail closed.

This strengthens the case for the grant. The project is past the toy stage, but still early enough that an independent security review can shape the trusted core before wider adoption.

The grant remains scoped to the same thing: an independent review and remediation of the trusted core — verification logic, bundle parsing, canonicalization, SD-JWT checks, anchor verification, CI/build provenance, and threat-model alignment.