A feature release following 6.4.0, with an offline Sigstore bundle verifier and stricter in-toto statement checks. It adds proofbundle verify-sigstore, which verifies GitHub Artifact Attestations and npm provenance offline against the trusted root, the artifact digest and the identity the relying party supplies. The verifiers for eval-result v0.1, test-result v0.1 and SVR v0.1 statements now refuse statements that lack the members their predicates require or that carry them in another form, and every rfc3339z time field must name a real calendar instant. Statements that a released version accepted with such members missing or malformed no longer verify. That includes statements that earlier exporters of this package emitted from caller-supplied time, claim timestamp or test-result url values in another form; the CHANGELOG names each case.

python -m pip install --upgrade proofbundle==6.5.0

Highlights

• proofbundle verify-sigstore verifies GitHub Artifact Attestations and npm provenance offline. It checks one Sigstore bundle under the profiles github-artifact-attestation, npm-provenance and npm-publish, from the Fulcio leaf and its embedded SCT to the inclusion proof and the checkpoint, and an in-toto Statement with a SLSA Provenance v1 predicate. It imports no Sigstore client. safeForAutomation is false in every verdict, since revocation and log consistency over time are not checked.
• Stricter checks for eval-result v0.1, test-result v0.1 and SVR v0.1 statements. An eval-result v0.1 statement must carry its eight required members, at least one claim, and the required forms of verifier, suite and subjectProfile. A test-result v0.1 statement must carry result and configuration with the required types. An SVR v0.1 statement must carry verifier, verifier.id, timeCreated and properties. The affected URI and timestamp fields are now validated as described in the entries below. proofbundle intoto --verify and proofbundle svr --verify report the verifier's failure reasons; the meanings of their exit codes are unchanged.
• Time fields name a real instant. Every rfc3339z time field checks month, day in month, hour, minute and second after its form, so decision verify --strict refuses a decidedAt of 2026-13-15T09:05:00Z. The Rust verifier applies the same rule to the one time field it checks.
• Stricter input and binding checks, and lower memory use in five JSON traversals. The Bitcoin header map in the trust policy, --bitcoin-header, --bundled-header, the agent-review policy file and the SD-JWT bundle-binding check now reject inputs or bindings they previously accepted. Five JSON traversals carry paths as links and render path text only when needed for a message, keeping memory use proportional to the input and any supplied path declarations.

Verify this release yourself

Use the checksums and build provenance to check the downloaded files. To check the signed pre-tag audit receipt, use a clone at the source commit identified by the build attestation. The commands, prerequisites and limits are in Verifying a published release.

What a receipt still does not prove

A valid signature binds the signed content to the signing key. It does not make a reported result true.

decision verify and outcome verify do not implement the complete offline verification procedure in draft-gruszka-audit-decision-receipts-05. They do not perform all the procedure's checks for approval records, action bytes, executor identity, separation of keys and identifiers, effects and the execution-time window. decision verify also exits 0 when the evaluation time is before decidedAt, although Section 3.2 step 9 of revision 05 requires decidedAt <= T.

A Statement with two subject entries, which Section 3.2 step 6 does not allow, exits 0 without --require-derived-subject and 2 with that switch. Both measurements use --strict, the gate-1 public key, --aud observer-1, --nonce dec-0002 and --verification-time 2026-10-15T09:06:00Z. The valid V2 control still exits 0 with the switch. These command results are not verdicts of full conformance to revision 05.

Without --policy, decision verify does not establish that decisionMaker.id is the identity trusted for the signing key. In vector F3 of Appendix A.5 of draft-gruszka-audit-decision-receipts-05, the receipt names gate-2 under the gate-1 key. With --strict, --aud observer-1, --nonce dec-0002 and --verification-time 2026-10-15T09:06:00Z, it exits 0 without a policy and reports POLICY: NOT_EVALUATED. The same invocation exits 3 when --policy supplies a trusted_decision_makers mapping from that key to gate-1. These results depend on the stated verification time; they do not mean that an expired receipt passes without a policy. The command does not read or hash the evidence bytes referenced by evidenceRefs, with or without that test policy.

Measured on the reference machine

The budget cost axis was measured on the reference machine on 2026-11-06 using the code at 14fe339. The record identifies the run as a reference measurement (ist_referenzmessung=true). All 12 expected axes and all 7 expected combinations passed, and no axis was skipped. The recorded calibration factor maschinenfaktor_schnellstes_ende is 1.036, and the timing-limit setting is latte_aus_der_klammer=schnellstes_ende. These results apply to the listed axes and combinations, not to every reader or input. The measurement record lists every axis and combination.

Details

proofbundle plugin 0.4.0

This is the first plugin-specific tag and GitHub release of proofbundle for Claude Code and Codex. It is separate from the Python package and its existing v0.4.0 tag.

The public marketplace of this repository lists one plugin, proofbundle, the verifier. It registers no hook. The Guard is the separate plugin proofbundle-guard, the owner's house profile. No public catalog lists it; the owner's machines add its own marketplace from a checkout of this repository at plugins/proofbundle-guard and install it beside the verifier. Installing proofbundle does not install or enable proofbundle-guard. The source of both plugins is public, and the release archive holds both.

Earlier 0.4.0 installations

Version 0.4.0 was already available from the public marketplace on main before this release, including an earlier form in which the plugin proofbundle carried the Guard's hooks. If you installed before this release, follow the tested Claude Code reinstall procedure and supported-host notes in the plugin README.

The version remains 0.4.0. A version display or routine marketplace refresh alone does not establish that the installed files changed. In the measured Claude Code reinstall, source identity, retained data and the absence of the old Guard hooks were checked. Users of other installations should check their own installed files and hook listing rather than infer a change from the version display. Publishing this release does not revoke earlier installed copies. The number of outside installations is not known.

Codex has not reached M1 for this release. Its unmeasured runtime and lifecycle cases are not covered by the measured Claude Code procedure, and the migration under Codex is NOT MEASURED.

Acceptance and limits

Claude Code has not reached M1 for this release, and the release is published without it. M1 is the acceptance defined in the test plan; it includes real-host operation and lifecycle checks, not just a passing test harness. The acceptance ran at commit 6d29ead on 2026-11-04, and the implementation-gap record carries it row by row. In the record's own words, "At this measurement V-CC-7 (TV-8) is FAILED, G-CC-13 (the pilot of TG-11) is NOT MEASURED, the record of used releases on the operator's machine (G-CC-16) is not measurable with V6 at 6d29ead, TG-6 was not run in a host (G-CC-7), and the gate directory of TL-3 and TL-4 and a stale hook entry of TL-4 were not checked (L-2, L-3). G-CC-3 (TG-1) has 14 different answers against the comparison head, all additional D129 blocks with none lost. The owner accepted these differences as an intended policy change on 2026-11-05; the unchanged TG-1 requirement of zero different answers is still not met. The delivery-profile TG-9 run showed a push proceeding without Guard protection, but did not emit the literal INACTIVE status required by TEST_PLAN.md. At least acceptance points 1, 2, 4 and 8 remain unmet; Claude Code has not reached M1 at this measurement." M1 is the target of 0.4.1.

At candidate commit 43544e2, the archived-file inventory differs from 6d29ead only in plugins/proofbundle/m0/IMPLEMENTATION_GAP.md; the plugin code and the marketplace files are unchanged. The final release commit receives its own archive and signature checks. The record's V-CC-2 entry retains the earlier real-host failure and the interactive run at 6d29ead in which /mcp listed the server with seven tools; the cause of the earlier failure is not known. These release notes are not themselves evidence of a host measurement.

Verification reports the pinned core verifier's result. A valid signature proves authorship under a trusted key and integrity of the signed bytes; it does not establish that recorded claims are true. An absent, disabled or untrusted Guard provides no protection.

The verifier pin is proofbundle==6.4.0 in the verifier and in the Guard. Initial startup can require the runtime and package download described in the README.

A Guard installed from its house marketplace is read from that checkout in place. It follows the checkout, not a version number, so a house machine compares its checkout with this release's commit when that correspondence matters.

House Guard PR-count behaviour

In Claude Code, the house Guard counts pull requests opened through recognised Bash gh commands per session (D110). With a valid count below eight, house rule H3 adds no ask of its own; at eight or more it does. If a session ID and plugin data directory exist but open-prs.json is absent, the current gate treats the count as zero and also drops that H3 ask. If the session ID or plugin data directory is unavailable, or the counter file is present but unreadable or invalid, H3 retains its ask. Losing or removing a counter file can therefore reset this advisory count; it is not a guarantee that a session has fewer than eight open pull requests. Other gate rules can still ask or deny. The counter does not cover every GitHub or MCP operation, and it is not a live count across sessions.

The Guard's decision receipts

Two corrections of the Guard's decision receipts are in this release, decision D135 of the plugin.

• Trace context. A Level 1 receipt records the Guard's decision on a tool call, including a Bash call or a supported MCP write. When the hook event supplies session_id or tool_use_id in the accepted form, the receipt copies them into traceContext.traceId or traceContext.parentId, respectively; missing or unusable IDs are identified in notChecked. The separate Level 2 git pre-push hook has no Claude session or tool-call IDs and its own receipt carries no trace. A git push invoked through Bash can have a Level 1 receipt with trace context even though the pre-push receipt has none.
• Merge digest. For a GitHub merge call with a specified head commit and merge method, parametersDigest is the SHA-256 of the RFC 8785 form of the requested github.merge operation, including the lowercased repository, pull request number, head commit and merge method, plus the commit title and message where supplied. The digest records what the call requested, not what the host actually merged. A GitHub MCP server that ignores expectedHeadSha can merge a different head. Without a specified head commit or merge method the receipt carries no such digest.

The key signer accepts receipts carrying traceContext only from this version on. Its program is plugins/proofbundle/pilot/key_signer.py, not part of the proofbundle-guard plugin. Updating the Guard alone does not update the copy running under the key account. An operator using that pilot must separately replace the key account's copy with the matching version, as described in plugins/proofbundle/pilot/RUNBOOK.md (step 2). Until then an owner's release that requires the signed ALLOW stays unused. Receipts written before this release verify as before.

What the release signature covers

The assets are:

• proofbundle-plugin-0.4.0.tar
• proofbundle-plugin-0.4.0.release.json
• SHA256SUMS
• proofbundle-plugin-0.4.0.release.json.sig

The archive holds LICENSE, the public marketplace file, the verifier's folder plugins/proofbundle and the Guard's folder plugins/proofbundle-guard with its house marketplace file. Every marketplace source in it resolves inside the archive.

The signature authenticates the exact release-statement bytes. The statement binds the archive's filename, size and SHA-256. SHA256SUMS is a deterministic two-line index reconstructed from the authenticated statement and its file hash; it is not independently signed.

The intended release public key, as standard base64 of 32 raw Ed25519 bytes, is:

iJipntJA8N//h+ln9CgLzeC9n/M5OdCZNeBhbfagom8=

Its raw-key SHA-256 is:

e53405faeb960e17c653fbc5eb6a862a115550efdf064f64b958a0d9bdca921b

Confirm the owner-key binding through a previously trusted copy or another authenticated channel. The key printed next to these assets is not by itself a new trust anchor. Follow the exact verification procedure in the linked README; checking SHA256SUMS alone does not verify a signature.

The release statement identifies the fixed commit and archive. The default installation commands continue to follow main, which can change. The signature does not establish which source revision or cached files a host loaded, even if they also report 0.4.0. Compare installed source identity and content with the archive when that correspondence matters.

The statement does not authenticate separately downloaded verifier distributions, host software, local configuration or GitHub's automatically generated source archives. The annotated plugin tag itself is unsigned; the detached signature is over the release statement.

If you try the verifier plugin with Claude Code, I'd be glad to hear what works and what doesn't.

proofbundle.dev

Assisted by little helpers.

A feature release following 6.3.1, with an experimental SCITT reader, a TRACE verifier and a stricter JSON reader. It adds proofbundle.scitt_ccf, an experimental reader for SCITT Transparent Statements with CCF receipts under the narrow profile scitt-ccf/v1, and proofbundle verify-trace for TRACE v0.2 Trust Records. The strict JSON reader now refuses non-finite numbers, integer literals outside the inclusive range -(2^53 - 1) to 2^53 - 1, and JSON bytes with a UTF-8 byte order mark or encoded as UTF-16 or UTF-32. Review the inputs your code hands a verifier when upgrading.

python -m pip install --upgrade proofbundle==6.4.0

Highlights

• An experimental reader for SCITT Transparent Statements with CCF receipts. proofbundle.scitt_ccf reads statements under the narrow profile scitt-ccf/v1, which follows draft -06 of the CCF profile, and needs the [scitt] extra. It is reached only by calling it; no verify path of the package reaches it. The Rust cross verifier pb_verify_rs, which is not part of the Python package, gives the same results for statement signatures, Transparent Statements and consistency receipts over shared vectors.
• proofbundle verify-trace verifies TRACE v0.2 Trust Records. It checks a record against keys, a time window and expectations that the relying party supplies, in the compact JWS form and in the embedded Ed25519 form. A pass is evidence for the relying party's policy, and safeForAutomation is false in every verdict.
• The strict JSON reader rejects non-finite numbers and applies explicit integer and encoding limits. loads_strict refuses NaN, Infinity, -Infinity and every number that becomes infinite, integer literals outside the inclusive range -(2^53 - 1) to 2^53 - 1, and JSON bytes with a UTF-8 byte order mark or in UTF-16 or UTF-32, with BundleFormatError. With an sd_jwt_vc whose issuer signature verifies, a signed JSON payload refused for a duplicate member or one of these limits now demands and fails sd-jwt-bundle-binding. A payload that is not JSON at all remains outside the scope of that binding. Review code that hands a verifier such input.
• The release run compares its files with the signed candidate. Before any upload, the tag run compares its sdist and wheel with the pair signed in the candidate block of the short soak and of the Rust differential, and stops when the bytes differ. The build tools are selected at fixed versions through .github/build-constraints.txt; the constraints name versions, not archive hashes.

Verify this release yourself

Use the checksums and build provenance to check the downloaded files. To check the signed pre-tag audit receipt, use a clone at the source commit identified by the build attestation. The commands, prerequisites and limits are in Verifying a published release.

What a receipt still does not prove

A valid signature binds the signed content to the signing key. It does not make a reported result true.

Measured on the reference machine

The budget cost axis was measured on the reference machine on 2026-10-27 using the code at e29a268. The record identifies the run as a reference measurement (ist_referenzmessung=true). All 12 expected axes and all 7 expected combinations passed, and no axis was skipped. The recorded calibration factor maschinenfaktor_schnellstes_ende is 1.0, and the timing-limit setting is latte_aus_der_klammer=schnellstes_ende. These results apply to the listed axes and combinations, not to every reader or input. The measurement record lists every axis and combination.

Details

A patch release following 6.3.0, with stricter verification and changed result reporting. Statement validation is reported separately from DSSE signature checks, and reference-check results and executed-outcome evidence levels change as described below. The release also improves handling of specific invalid inputs, extends the inspect_ai adapter and updates repository tools. Review the changed fields and remaining exception paths when upgrading.

python -m pip install --upgrade proofbundle==6.3.1

Highlights

• Statement validation is separate from DSSE signature verification. The eval-result, in-toto and SVR verifiers require the in-toto Statement v1 layer and report statement_ok separately from signature_ok. These and the decision, outcome, relation statement, verification summary, run ledger and trust pack verifiers require subjects that identify artifacts by digest. A successful DSSE signature check alone does not establish that the Statement passes validation.
• Reference reporting changes for callers upgrading from 6.3.0. automation.referencesResolved is None when no reference was checked; safeForAutomation and automationBlockers are unchanged. Executed-outcome evidence levels use REFERENCE_WELL_FORMED for a well-formed digest reference, or CONTENT_RESOLVED when the evidence resolver confirms it, instead of always reporting CLAIMED. action_outcome_proven and ok are unchanged. Review code that depends on these fields.
• Stricter validation and more specific errors for the corrected cases. The decision validator rejects JSON null in required fields that do not allow it. The validators named below enforce the corrected digit restrictions and closed sha256Digest objects. The corrected error paths return reason codes, blocking verdicts or module-specific errors. Eight public functions remain open for the formatting cases described below, and the two canonical primitives still propagate canonicalization errors.
• The inspect extra admits inspect_ai up to 0.3.281. Version 0.3.281 is the latest version measured in a fresh environment. The adapter includes sample counts and early-stopping metadata when supplied by the log, allowing a reported early stop to be distinguished from a completed run. The reported n is unchanged.

Verify this release yourself

Use the checksums and build provenance to check the downloaded files. To check the signed pre-tag audit receipt, use a clone at the source commit identified by the build attestation. The commands, prerequisites and limits are in Verifying a published release.

What a receipt still does not prove

A valid signature binds the signed content to the signing key. It does not make a reported result true.

Measured on the reference machine

The budget cost axis was measured on the reference machine on 2026-10-21. All 12 axes and all 7 combinations passed, and none was skipped. The calibration factor maschinenfaktor_schnellstes_ende is 1.0, the ratio of the fastest recorded calibration time in this run to the median of the earlier reference recording. The timing limits used the fastest-sample setting, recorded as latte_aus_der_klammer=schnellstes_ende. The measurement record lists every axis and combination.

Details

A feature release following 6.2.1. The installed package adds opt-in eval-result v0.2 export and verification, changes the default DSSE key ID handling, and fixes two pytest receipt behaviours. The repository also adds SCITT statement identification material, a pilot profile and contract, and an incremental Merkle accumulator.

python -m pip install --upgrade proofbundle==6.3.0

Highlights

• DSSE key IDs are included by default when available. Envelopes created by dsse.sign_envelope, including in-toto exports, carry the signer's OpenSSH SHA256 fingerprint as an unsigned keyid by default when the signer exposes its Ed25519 public key. Use keyid="" to omit it; signers without an exposed Ed25519 public key omit it unless supplied explicitly.
• eval-result v0.2 for the revised in-toto draft. An opt-in export and verification under its own predicate type; exports still default to v0.1, and --verify accepts both.
• Statement identification material for SCITT. The repository includes requirements and a verification package in docs/scitt/statement_identification/.
• Repository pilot material and an incremental accumulator. A profile and vectors for the shipped decision and outcome predicates, the first pilot contract, and an incremental Merkle accumulator with a restart rule are provided under docs/ and tools/.

Verify this release yourself

Use the checksums and build provenance to check the downloaded files. To check the signed pre-tag audit receipt, use a clone at the source commit identified by the build attestation. The commands, prerequisites and limits are in Verifying a published release.

What a receipt still does not prove

A valid signature binds the signed content to the signing key. It does not make a reported result true.

Measured on the reference machine

The budget cost axis was measured on the reference machine on 2026-10-13. All 12 axes and all 7 combinations passed, and none was skipped. The calibration factor maschinenfaktor_schnellstes_ende is 1.0581, the ratio of the fastest recorded calibration time in this run to the median of the earlier reference recording. The timing limits used the fastest-sample setting, recorded as latte_aus_der_klammer=schnellstes_ende. The measurement record lists every axis and combination.

Details

Full changelog · Known limitations for 6.3.0 · Earlier risk record · Release scope · proofbundle.dev

Created with AI assistance. Reviewed and published by me.

A security update for everyone on 6.2.0. It tightens checks on policy validity, timestamps, key algorithms and log inclusion proofs, and rejects ambiguous input on additional paths.

python -m pip install --upgrade proofbundle==6.2.1

Highlights

• Policy checks use one time for both validity limits. Decision-policy lifetime checks keep fractions of a second, and claim-age checks no longer truncate the calculated age to whole seconds.
• One signature method cannot stand in for another. An old root key cannot approve a rotation using an unsupported algorithm, and an Ed25519 outcome signature alone cannot meet a hybrid-key requirement. Empty log-key or origin lists reject the respective trust check.
• A proof counts only where it was checked. Trust in a transparency log inclusion applies only to the inclusion context the verifier checked, including its position, tree size, proof path and root.
• Duplicate fields and unsupported requirements are rejected. Agent-review policy files and Chia node replies with duplicate JSON keys are rejected. The credential profile check also rejects unsupported or malformed critical-extension fields.

Verify this release yourself

Use the checksums and build provenance to check the downloaded files, and check the signed pre-tag audit receipt from a clone. The commands and their limits are in Verifying a published release.

What a receipt still does not prove

A valid signature binds the signed content to the signing key. It does not make a reported result true.

Details

Full changelog · Known limitations · Release scope · proofbundle.dev

Created with AI assistance. Reviewed and published by me.

Stricter input checks at verification boundaries, hardened Ed25519 trust-anchor handling, and offline AGT receipt verification. Beta. Locations of the closing records are listed under Audit status.

Changelog · Known limitations · Release scope

Highlights

• Agent Governance Toolkit receipts verify offline, without AGT installed and without network access.
• Low-order and non-canonical Ed25519 keys are refused wherever the verifier relies on a key.
• The Rust and Python verifiers refuse the same inputs in more places than in 6.1.0.

If you use 6.0.0 or 6.1.0, please upgrade. 6.2.0 also contains security fixes for those releases.

pip install proofbundle==6.2.0

Findings addressed in 6.2.0

6.2.0 fixes the issues described below, including findings in the released 6.0.0 and 6.1.0 and a pre-release regression in pull request 313. The rows summarize affected surfaces, effects, fixes and measurement baselines. Fixes are linked to their public pull requests, including 311, 312 and 313. The last five rows describe additional classes addressed in pull request 311 and state where each was measured.

Verifier build identity, CAP-1 coverage rules and stricter claim validation. Beta. Closing audit not run.

Changelog · Known limitations · Release scope

What changed

Before upgrading

• Receipt versions. The default emitted format is unchanged from 6.0.0. Use a compatible reader for agent-review/v0.3. A 6.0.0 reader refuses a v0.2 receipt carrying the new verifier field. Details.
• Stricter input handling. Previously accepted malformed claims can now be refused. Check callers that relied on implicit type coercion. Details.
• Separate Action release. The Action input fix is in this source tree. That does not update the documented [email protected] tag. Its version and extras inputs retain the documented restriction on untrusted values. Details.

All changes

48 pull requests, grouped by area. Shortened descriptions link to the original discussions.

Contributors

Thanks to @b7n0de and @dependabot.

Full comparison v6.0.0...v6.1.0

proofbundle 6.0.0 is the verifier release whose emitter produces bundle format v0.2.

The full release notes are the section [6.0.0] of CHANGELOG.md at this tag, including "Known issues at the tag" with the register rows S102 to S120 and the Rust cross-verifier marked experimental and advisory.

Tag v6.0.0 points at 4e32e83, the documentation head c82a5a3 plus the commit carrying the signed pre-tag audit receipt audit_artifacts/600/pre_tag_receipt_v6.0.0.json.

The assets of this release are the wheel and the sdist built once in this workflow, SHA256SUMS over exactly these files, and the SLSA build provenance next to them.

A local rebuild of the tagged commit with the same source date epoch produced byte-identical files, wheel sha256 3c206fcff592833a75d712ed421e4b9f6aaf7d1fa857b2fc0ba50839d3dfe14d and sdist sha256 c24f91e5f137783de500f1e1269b66e77f64dcbae9c125ef3b07d94e850b7ecb.

Prepared with AI agent involvement, reviewed and submitted under human oversight.

Full Changelog: v5.1.0...v5.1.0.post1