BoundaryAttest provenance-addon v0.1 → next technical decisions

[markusvankempen]

Context

Follow-up to Cullen Meyers' review of the public provenance-addon/ PoC (BoundaryAttest collaboration context).

The v0.1 PoC addressed the main review concerns:

• artifact_hash — binds the signed claim to exact produced file/patch/scaffold content without storing raw bytes in the receipt
• previous_receipt_hash — clearly reserved/future; v0.1 does not imply active receipt chaining
• createLocalSigner() — clearly marked ephemeral/dev-only; cross-run verification requires persisted keys or KMS/HSM-backed signing
• Failure model — distinguishes tool failure (valid signed receipt with status: failed) from sink failure (fail-open, tool path unchanged)
• Visualizer — timeline replay, session/task drilldown, tamper detection demo with Web Crypto Ed25519 verification

This issue tracks concrete next decisions before moving beyond PoC.

---

Decision areas

1. Persisted key / external verifier from disk

• Define dev/PoC persisted key file format (PEM path, permissions, rotation notes)
• Document cross-run verification workflow (verifySignedReceipt against saved public key)
• Clarify when to move from local PEM → KMS/HSM (IBM Key Protect, etc.)
• Add example: sign in one run, verify in another using persisted public key

Open questions:

• Should the public repo include a verify-receipt.mjs CLI, or is README + example sufficient?
• Where should trusted public keys live for verifiers (config file, env, org registry)?

2. Schema validation in CI

• Define JSON Schema (or TypeBox/Zod export) for receipt v0.1 wire format
• Validate demo receipt fixtures in CI (receipts/*/ sample files)
• Fail CI if claim shape drifts without version bump

Open questions:

• Strict schema for optional fields (session_id, task_id, artifact_hash) — required vs omitted?
• Separate schema for _public_key.json manifest?

3. Artifact hash verification flow

• Document end-to-end: produce artifact → compute hash → sign receipt with artifact_hash → later verify artifact bytes match claim
• Add verifier helper: given receipt + artifact file on disk, confirm hashRaw(artifact) === claim.artifact_hash
• Clarify relationship between artifact_hash (raw content) and input_hash (redacted structure)

Open questions:

• Should artifact verification be a separate CLI step or part of unified receipt verifier?
• Patch/diff artifacts: same artifact_hash field or future patch_hash?

4. Trust model wording

• Align README FAQ with BoundaryAttest trust language (what signature proves vs does not prove)
• Document client_observed vs future server_attested for Code Engine MCP boundary
• Add short "verifier checklist" for auditors reviewing receipts out-of-band

Open questions:

• Any wording Cullen wants mirrored in BoundaryAttest repo vs Code Engine-specific phrasing here?

5. Receipt chaining (previous_receipt_hash)

• Confirm v0.1 stays null always until explicitly implemented
• If implemented: single-writer sequential chain vs per-session/task chains vs DAG/lineage
• Document retention/pruning impact on chain verification (retained-chain semantics)

Open questions:

• Is chaining needed for Code Engine MCP deploy flows, or is session_id + task_id + trace_ref sufficient for v0.2?
• Should BoundaryAttestProvenanceSink maintain previousReceiptHash when enabled?

---

References

• Public addon: https://github.com/markusvankempen/code-engine-mcp-server/tree/main/provenance-addon
• BoundaryAttest: https://github.com/cullenmeyers/BoundaryAttest
• Demo scripts: example.mjs, demo-ce-deployment.mjs, demo-multi-session.mjs, demo-tamper-scenarios.mjs
• Visualizer: provenance-addon/visualizer.html

Collaborators

• @markusvankempen — Code Engine MCP / provenance-addon
• Cullen Meyers — BoundaryAttest review context (decisions that become BoundaryAttest-general may be mirrored upstream)

---

Opened per review feedback, Jun 2026.

[cullenmeyers]

Thanks Markus — this looks good to me.

I agree with tracking the concrete Code Engine MCP decisions here first, since the current PoC and addon live in this repo.

The five decision areas look like the right next set:

• persisted key / external verifier from disk;
• schema validation in CI;
• artifact hash verification flow;
• trust model wording;
• whether/when receipt chaining is actually implemented.

My main preference is to keep the split clear:

• Code Engine MCP can define the local event/adapter shape for file, patch, scaffold, deployment, and trace contexts.
• BoundaryAttest should stay focused on the portable signed-claim model, verifier expectations, and trust limits.
• Anything that becomes generally useful beyond Code Engine MCP can be mirrored or summarized upstream in BoundaryAttest later.

For v0.1, I’d personally prioritize:

1. persisted key + external verifier from disk;
2. artifact hash verification against an actual file/patch;
3. trust model wording.

I would keep chaining as explicitly future unless there is a concrete verifier need for it. session_id, task_id, trace_ref, git_ref, and artifact hashes may be enough for the next version without introducing chain complexity too early.

Thanks again for pushing this forward. This is a clean public place to continue the technical discussion.

[markusvankempen]

Thanks Cullen — aligned on the split and priorities.

I'll work the next slice in this order on the Code Engine MCP side:

1. Persisted key + external verifier from disk — so receipts verify across runs outside the signing process
2. Artifact hash verification — given a receipt + file/patch bytes, confirm hashRaw(content) === claim.artifact_hash
3. Trust model wording — tighten README/FAQ alignment with BoundaryAttest trust limits

I'll keep previous_receipt_hash null and chaining explicitly future unless a verifier need appears. Correlation via session_id, task_id, trace_ref, git_ref, and artifact_hash stays the v0.1/v0.2 path.

I'll note anything BoundaryAttest-general in this issue for upstream mirroring.

[markusvankempen]

Update: P1 shipped — requesting upstream deliverables from BoundaryAttest

P1 is done on our side: loadOrCreateSigner(keyDir), verifyFromPublicKey(receipt, pem), standalone CLI verifier, cross-run demo. Commit: c5aa074.

Receipts now survive process boundaries. An auditor with just public.pem + receipt JSON can independently verify.

---

Asking for your side

I've been building the implementation and you've been reviewing — which is fine for bootstrapping. But for the next steps to be interoperable (not just Code Engine-specific), I think BoundaryAttest needs to publish some concrete artifacts. Specifically:

1. Claim schema (JSON Schema or at minimum a normative field list)

Our claim object currently has: event_version, event_id, timestamp, tool_name, action_type, status, target_ref, content_hash, artifact_hash, session_id, task_id, trace_ref, git_ref, lineage_ref, input, output, error.

Which of these does BoundaryAttest consider required for a portable signed receipt? Which are optional extensions? Is there a minimal subset you'd accept as "BoundaryAttest-compatible"?

2. Verifier expectations spec

verifyFromPublicKey currently checks: (a) public_key_id matches, (b) signature over canonicalJson(claim) verifies.

Does BoundaryAttest define additional verifier checks? For example:

• Timestamp freshness (reject if > N hours old)?
• Required fields present?
• Key rotation / key-not-revoked check?
• Claim version compatibility?

A short doc or even a code snippet from your side would help us target the right interface.

3. Test vectors

Can you publish 3–5 reference receipts (receipt JSON + public key PEM + expected pass/fail) in BoundaryAttest? This gives us an interop test: if our verifier and yours agree on the same inputs, we know we're compatible.

4. Key file convention

We're using SPKI PEM for public keys and PKCS8 PEM for private. Is that what BoundaryAttest recommends, or do you have a different convention? Should there be a key metadata file (algorithm, created_at, rotation policy)?

---

None of these need to be large — even a single markdown file or a test-vectors/ folder in BoundaryAttest would unblock the next round of work on our end and make this a two-way collaboration.

Let me know what's realistic for your timeline.

[cullenmeyers]

Thanks Markus — I added and pushed the first BoundaryAttest Interop Profile v0.1.

It includes:

• an experimental compatibility profile for external adapters;
• required receipt envelope fields: claim, signature, public_key_id;
• required claim fields: receipt_version, receipt_role, event_id, timestamp, action_type, status;
• verifier expectations for structure, version, canonical claim signing, signature verification, and expected key fingerprint;
• key convention documentation;
• five test vectors covering valid, tampered, wrong key, unsupported version, and missing required field.

A few notes:

• This is intentionally an interop profile, not a final standard.
• Existing BoundaryAttest/proof-kit receipts remain valid in their current flat shape; the v0.1 profile is a separate adapter compatibility target.
• Policy checks like timestamp freshness, revocation, authorization/grant validity, artifact availability, and replay sufficiency are documented as out of scope for mandatory v0.1 cryptographic verification.
• The profile currently uses BoundaryAttest’s existing canonicalization/key-ID behavior, including the PEM-text key fingerprint convention.

The most useful next check from your side would be whether Code Engine MCP can run its receipts or adapter output against these vectors / expectations without changing the core addon shape too much.

If anything feels too BoundaryAttest-specific or too weak for real adapter use, we can tighten it in the issue before calling it stable.

[markusvankempen]

Thanks Cullen — this is exactly what we needed. We pulled your vectors from BoundaryAttest/examples/interop-v0.1/test-vectors/ and ran them against our addon verifier.

Results

Vector	BA expected	Our verifier	BA reference verifier
valid receipt + public key	pass	public_key_id mismatch	pass
tampered claim	invalid_signature	public_key_id mismatch	invalid_signature
wrong public key	public_key_id_mismatch	public_key_id mismatch	public_key_id_mismatch
unsupported version	unsupported_version	public_key_id mismatch	unsupported_version
missing required field	missing_claim_field:status	public_key_id mismatch	missing_claim_field:status

Good news: for the valid receipt, stableJson(claim) and our canonicalJson(claim) produce identical bytes. Signature verification would pass once key fingerprinting aligns.

Blocker: public_key_id computation differs.

Same public-key.pem:

BA v0.1 : sha256:d795438daa66a97f5deb0886
Ours    : sha256:4145925191b02ff60e26109854f74a558e941539a72e1f3bd086eadad1eb1995

	BoundaryAttest v0.1	Code Engine MCP (current)
Input	UTF-8 PEM text (incl. trailing newline)	SPKI DER bytes
Digest	SHA-256, first 24 hex chars	SHA-256, full 64 hex chars

Our verifier fails every vector at step 7 before structural checks (version, required fields). Your reference verifier passes all 5 cases as documented.

Smaller claim-shape gaps (easy on our side once fingerprint is settled)

Field	BA v0.1	Ours	Notes
Version	receipt_version	event_version	rename
Role	receipt_role (required)	not present	we can default client_observed
Envelope	{ claim, signature, public_key_id }	same	already aligned

Ask before we change our signer

Before we adapt our core signer, can we align on public_key_id for v0.1?

Options as we see them:

1. Adopt BA convention upstream as normative — we change loadOrCreateSigner / verifyFromPublicKey to PEM-text + 24-char prefix.
2. Document both, pick one for interop — e.g. interop profile mandates PEM fingerprint; native CE receipts keep DER until exported.
3. Switch BA to DER/full hash — closer to typical SPKI fingerprinting; we'd align quickly.

Our preference: (2) or (3) — PEM-text truncation feels demo-specific and easy to get wrong (newline handling, re-export formatting). DER/full SHA-256 is what we already ship and what most crypto tooling expects. But we're happy to follow v0.1 if you want PEM to stay for proof-kit continuity — we just want it locked before we code.

Once fingerprinting is settled we'll:

• run your 5 vectors in CI (interop-v0.1/run-vectors.mjs locally now)
• add receipt_role + rename to receipt_version
• report back with pass/fail on all vectors

Does PEM+truncate stay intentional for v0.1, or should we converge on DER/full hash?

[cullenmeyers]

Thanks Markus — good catch on the key fingerprinting issue.

I agreed with your concern and updated the BoundaryAttest Interop Profile v0.1 before treating it as stable.

The interop public_key_id convention is now:

sha256:<64 lowercase hex chars of SHA-256(SPKI DER public key bytes)>

So the profile no longer uses the older PEM-text + truncated fingerprint convention. That older behavior remains separate from the interop profile / proof-kit context, but the v0.1 adapter compatibility target now uses DER/full SHA-256.

I also regenerated the interop vectors. Current status on the BoundaryAttest side:

• valid receipt + public key: pass
• tampered claim: invalid_signature
• wrong public key: public_key_id_mismatch
• unsupported version: unsupported_version
• missing required field: missing_claim_field:status

Validation passed for:

• build
• interop vector runner
• proof kit
• chain check
• diff check

The only test issue remains the known sandbox-localhost Intergrax listen EPERM 127.0.0.1 failure, unrelated to the interop changes.

Once this is pushed, Code Engine MCP should be able to re-run against the updated vectors with the DER/full-hash key ID convention.

[markusvankempen]

Thanks Cullen — DER/full SHA-256 aligns perfectly. Re-pulled your updated vectors and re-ran.

Test results (updated vectors)

Vector	BA verifier	Our verifier	Status
Valid receipt	pass	pass	✅ Interop works
Tampered claim	invalid_signature	signature does not verify	✅ Both detect
Wrong public key	public_key_id_mismatch	public_key_id mismatch	✅ Both detect
Unsupported version	unsupported_version	pass	⚠️ We don't check yet
Missing required field	missing_claim_field:status	pass	⚠️ We don't check yet

Crypto layer: fully aligned. Valid receipts pass both ways; tampered/wrong-key are caught by both.

Structural checks: Our verifyFromPublicKey doesn't enforce receipt_version or required claim fields yet — that's on us to add.

---

CE side (our next PR)

1. Add receipt_version === '0.1' check to verifier
2. Add required claim field validation (receipt_role, event_id, timestamp, action_type, status)
3. Update test harness + commit

---

BoundaryAttest side (requesting before marking interop stable)

Now that fingerprinting is locked, these remain on the BA upstream side per our agreed split:

#	Deliverable	Why
1	JSON Schema for interop v0.1 envelope + claim	Portable claim model = BA
2	Reverse interop test — run our receipts through BA verifier	Fair exchange: we ran your vectors; you run ours. Sample: provenance-addon/receipts/persisted-key-demo/*.json + .keys/public.pem
3	Trust/limitations doc (P3)	One-page "what verification proves and doesn't prove" we can cite in README
4	Link to regenerated vectors commit	So we can pin to a known-good revision

Once (2) shows both directions pass, and (1) + (3) are published, we can mark interop v0.1 stable.

[cullenmeyers]

Thanks Markus — I re-checked this before committing the BoundaryAttest P2 interop work.

There are two separate fixture sets:

1. provenance-addon/interop-v0.1/test-vectors/*

   • These are the BoundaryAttest vectors imported into Code Engine MCP.
   • They use public key ID sha256:414592...b1995.
   • These now pass both verifiers, which confirms the crypto/key-ID/canonicalization layer is aligned.

2. provenance-addon/receipts/persisted-key-demo/*

   • These are Code Engine-produced receipts.
   • The sample I copied for reverse interop uses public key ID sha256:6e7a...75a4cc.
   • The matching .keys/public.pem appears to be gitignored / absent from public history.

So the remaining blocker for the BoundaryAttest reverse interop check is the public key for the persisted-key-demo receipts.

Could you publish or attach the SPKI public key PEM matching:

sha256:6e7a...75a4cc

Ideally either:

• commit a test-only public.pem beside the persisted-key-demo receipt fixtures; or
• add a dedicated interop fixture folder with receipt JSON + matching public key + expected result.

Once that is available, I’ll rerun the BoundaryAttest reverse verifier and then push the P2 commit with:

• JSON Schema for the v0.1 envelope + claim;
• trust / verification limits doc;
• shared interop verifier helper;
• Code Engine reverse fixture;
• README/profile links.

I’m intentionally holding the commit until the reverse check can pass honestly rather than substituting the BoundaryAttest imported vectors as a proxy.

[markusvankempen]

Thanks Cullen — good catch on the missing public key for reverse interop.

We added a dedicated fixture folder (public key only — no private key):

Reverse interop fixtures

• Public key: provenance-addon/interop-v0.1/ce-reverse-fixtures/public.pem
• Expected results: provenance-addon/interop-v0.1/ce-reverse-fixtures/expected.json
• Receipts: provenance-addon/receipts/persisted-key-demo/*.json (4 files)

Public key ID

sha256:6e7a3d1d6208531b1595bbcf6a13bc5c08da3966196d5758b71a449aee75a4cc

Local verify (CE side)

cd provenance-addon
node interop-v0.1/run-ce-reverse.mjs
# or
node verify-receipt.mjs --key interop-v0.1/ce-reverse-fixtures/public.pem receipts/persisted-key-demo/*.json

All four receipts pass on our verifier with this key. Ready for your BoundaryAttest reverse check — looking forward to the P2 commit (schema, trust doc, shared verifier helper).

Pushed in latest commit on main.

[cullenmeyers]

Thanks Markus — reverse interop is now complete on the BoundaryAttest side.

I pulled the Code Engine MCP reverse fixtures from commit 79174e97, including:

• the public key at provenance-addon/interop-v0.1/ce-reverse-fixtures/public.pem;
• the expected manifest;
• the four persisted-key-demo receipts.

BoundaryAttest now verifies all four Code Engine-produced receipts successfully using the published public key:

• 01-write_or_modify_file-executed.json — pass
• 02-write_or_modify_file-executed.json — pass
• 03-update-executed.json — pass
• 04-update-failed.json — pass

The P2 BoundaryAttest interop update includes:

• JSON Schema for the v0.1 receipt envelope + claim;
• trust / verification limits doc;
• shared interop verifier helper;
• BoundaryAttest test vectors;
• Code Engine reverse interop fixtures;
• README/profile links.

Validation on the BoundaryAttest side:

• build — pass
• BoundaryAttest interop vectors — pass
• Code Engine reverse interop — 4/4 pass
• proof kit — pass
• chain — pass
• tests — 39/39 pass
• diff check — pass

This gives us two-way interop now:

• Code Engine MCP verifies BoundaryAttest vectors.
• BoundaryAttest verifies Code Engine MCP receipts.

I’ll keep calling this experimental v0.1, but this feels like a good point to treat the core interop target as working.

[markusvankempen]

Thanks Cullen — this is a solid milestone. Two-way interop confirmed:

• CE → BA: your vectors pass our verifier
• BA → CE: our four persisted-key-demo receipts pass your reverse check (commit 79174e9)

Really appreciate you holding the P2 commit until reverse interop could pass honestly — that made the result trustworthy on both sides.

---

Code Engine MCP side (our next slice)

We'll take these on our repo:

1. Structural checks in verifyFromPublicKey (receipt_version, required claim fields) so we match BA failure modes, not just signature validity
2. P2 artifact hash verification — receipt + file/patch bytes → confirm artifact_hash
3. README links to your upstream schema + trust/limits docs (once pinned below)
4. CI gate for both harnesses: interop-v0.1/run-vectors.mjs + run-ce-reverse.mjs

---

BoundaryAttest upstream (requesting before we drop the "experimental" label on our README)

Per our agreed split — CE MCP owns the local adapter; BA owns portable claim model, verifier expectations, and trust limits — a few items would help us and the next adapter after us:

#	Deliverable	Why upstream
1	Pin the P2 commit on BA main (schema, trust doc, verifier helper)	We want stable links in README, not moving targets
2	Integration guide for dependency-free adapters	Should CE copy the verifier spec, or import verify-receipt.ts? A short doc for "no npm deps" integrators would help
3	Normative v0.1 failure reason strings	e.g. invalid_signature vs free-text — so both verifiers report the same codes in CI/logs
4	Minimal vs extended claim	Document interop-required fields vs adapter extensions (session_id, input_hash, etc.) — our CE receipts use extras; verifiers should ignore, but a normative note in BA would help
5	v0.1 stable criteria checklist	What must pass before you drop "experimental"? Happy to align our README wording to yours

No rush on all five at once — but (1) and (3) would unblock our doc/CI work; (2) and (5) help anyone integrating after CE MCP.

---

Happy to review BA PRs on any of the above. Once (1) is linked, we'll wire our README to:

• interop-profile-v0.1.md
• interop-verification-limits-v0.1.md
• interop-receipt-v0.1.schema.json

Good work getting this to a honest two-way pass.

[cullenmeyers]

Thanks Markus — agreed, this is a solid milestone.

I also agree with the split:

• Code Engine MCP owns the local adapter, artifact flow, and Code Engine-specific verifier/CI.
• BoundaryAttest owns the portable claim profile, verifier expectations, test vectors, schema, and trust limits.

I’ll keep BoundaryAttest generic and avoid making the upstream profile Code Engine-specific. The Code Engine reverse fixture is useful as an interop example, but the core profile should stay adapter-neutral.

For the next BoundaryAttest-side slice, I think the right order is:

1. pin/link the P2 commit on BoundaryAttest main;
2. define normative v0.1 verifier failure codes so external verifiers can match failure modes consistently;
3. clarify minimal vs extended claim fields where needed;
4. then add a short dependency-free adapter guide.

I agree that (1) and (3) are the most immediately useful for your README/CI work, and I’ll keep the v0.1 stable criteria lightweight rather than turning this into a large standard too early.

The stable criteria I’m thinking of for v0.1 are roughly:

• BoundaryAttest vectors pass in an external verifier;
• at least one external producer’s receipts pass in BoundaryAttest;
• schema is published;
• trust/limits doc is published;
• required fields and failure codes are documented;
• unknown adapter-specific claim fields are ignored by default;
• no claims are made about truth, authorization, safety, compliance, or runtime integrity.

Thanks again — Code Engine MCP has been a very useful first external interop test.

[cullenmeyers]

I added the v0.1 verifier failure codes on the BoundaryAttest side.

The documented normative codes are:

• invalid_json
• missing_top_level_field:<field>
• claim_not_object
• missing_claim_field:<field>
• unsupported_version
• unsupported_receipt_role
• public_key_id_mismatch
• invalid_signature

I also added an unsupported-role vector so the interop runner now covers six cases.

Validation on the BoundaryAttest side:

• BoundaryAttest interop vectors — 6/6 pass
• Code Engine reverse interop — 4/4 pass
• proof kit — pass
• chain check — pass
• full tests — 39/39 pass
• build + diff check — pass

No receipt-shape changes were made, and no policy-layer checks were added. Timestamp freshness, revocation, signer trust, authorization/grant validity, compliance, artifact availability, and replay sufficiency remain outside mandatory v0.1 cryptographic verification.

This should give Code Engine MCP stable failure codes to match against for the structural verifier work.