Skip to content

Seal v0.2.0-rc.2 release notes

What Seal is

Section titled “What Seal is”

Seal puts an approval gate in front of one selected tool of one MCP server. An approval is for one exact call: it prevents a second run of that approved call, but it does not promise that the first run will happen. (README.md; boundary-list test; merged abf6f5a)

The release carries the approval contract and retry continuation through the same proxy for the demo and protected paths. (approval-contract test; retry-continuation test; merged 00176cd and 4228744)

The state machine is TESTED. The Node product now calls the pinned vendored WASM for the exact-call authorization sub-question and refuses its BLOCK, failure, integrity mismatch, or disagreement with Node. Handle lifetime, retry protocol state, and durable one-use consumption remain tested Node logic. The config accepted by seal_init is signed using an Ed25519 key generated inside the same worker; that is demo-grade self-authorization, not an externally trusted production config key. (adapter implementation; architecture split)

What Seal does not cover

Section titled “What Seal does not cover”

Seal is a gate, not a sandbox. It controls the path through it, and only that path; a direct local write, Bash, network access, subprocesses, other tools, and other servers are outside Seal. (README boundary list; scope-witness test; merged 09967fc and e4d5ba1)

Protect mediates a stdio MCP server entry. Other transport shapes are outside the protected path, and Protect relies on Claude Code for its local override. (README boundary list; Protect test; merged 37fefe4)

Seal v0.2.0-rc.2 supports Linux x86-64 only. macOS, Windows, Linux ARM, and other platforms are not supported in this release. (README.md at the release tag; platform implementation at the release tag; distribution test at the release tag)

Both paths write signed receipt files. The demo’s key is generated fresh for that run; the protected path creates or reuses a machine-local Ed25519 key under the Seal data directory. The checker accepts a receipt only against the public key you supply and only when the recorded decision, tool, arguments and signature match the sealed commitments. (README.md; distribution notes; truth gate; checker implementation at the release commit)

The published release payload includes the checker; it is not a separate release asset, so it cannot independently authenticate that payload. At check time it imports no Seal module: it independently implements the same receipt canonicalisation rule while omitting the sealer’s input-refusal branches. The release’s check-receipt-canonicalization.mjs (historical target moved) shows the compared statements and deliberate omissions. (artifact payload; release workflow; checker limits at the release commit; checker test; merged 18bba8e)

These notes make no stranger-verification claim. They also do not use the Lean or family-assurance material as evidence for this Node artifact. (artifact inheritance boundary; distribution test)

The current source tree has replaced this release’s receipt format and checker; see the v2 receipt specification and its producer test. Those successor links do not alter the historical release behavior described above.

What changed

Section titled “What changed”

  • The guarded retry path uses the TESTED pinned WASM authorization kernel through a named fail-closed adapter. There is no JavaScript authorization fallback. (adapter implementation; test/kernel-bridge.test.cjs)

  • The approval contract now binds the displayed call to a retry and records a consumed approval across a restart; altered, expired, malformed, declined, and replayed continuations have named refusals. (approval-contract test; retry-continuation test; merged 00176cd and 4228744)

  • The demo now exposes the scope witness: its guarded call crosses the proxy, while a direct write is shown outside it. (demo-witness test; merged 09967fc)

  • Protect adds a Claude Code local MCP override, reports the live activation state, and removes only that override. (Protect test; merged 37fefe4)

  • The release includes the receipt checker and a pinned Linux x86-64 install artifact; the artifact tests exercise installation, the demo, Protect, and removal. (receipt-checker test; distribution test; four-beats test; merged 18bba8e and b57ed0a)