Skip to content
Stylised from a recorded Claude Code dialog, not a live capture.

MCP server “notes” requests your input

Approval required

Tool: append_note
Arguments:
… (+3 more lines)

❯ * Approve one run: append_note: ☐

Arguments: note: seal-accepted-note. Scope: at most one run.

AcceptDecline
signed decision receipt

Approve the exact tool call.

For developers using Claude Code, Seal holds selected tool calls for your approval and gives you a signed record of the decision.

Seal is a gate, not a sandbox. Calls and effects outside the configured Seal route remain outside its control.

Decision receiptRecorded example

demo.mutate

Recorded decision: BLOCK

Document structure
Valid
Signature & bindings
Valid
Verifier-local replay
Reproduced
Operator authority
Not established
Event occurrence
Not established
Recorded result for the bundled public specimen, not a live check — open thebrowser checker guide to run this yourself against the example receiptand its demo public key.

How Seal fits into a tool call

Seal is a local approval gate for selected Claude Code MCP tool calls. Review the exact request, allow at most one execution per approval, and inspect a signed decision receipt.

Seal approval flowAgent request flows to the Seal approval gate, then, if permitted, to the selected MCP tool. A separate branch from Seal leads to a signed decision receipt, then to the browser checker and assurance CLI.Agent requestSeal approval gateSelected MCPtoolSigned decision receiptBrowser checker /assurance CLIif permittedcheck recorded evidence
Agent request → Seal approval gate → selected MCP tool (if permitted). Seal also writes a signed decision receipt; check that recorded evidence with the browser checker or the assurance CLI. Checking a receipt establishes what the check reports — it is not itself a claim that a tool effect occurred.

Start with the demo

The install and demo guide walks through a harmless approve-once demo and a refusal replay, so you can observe an approval and a refusal before protecting a real tool.

What the checks establish

The companion tools let you check recorded evidence separately from the running Seal deployment. The browser checker and CLI share kernel and receipt-format dependencies, so their agreement can also reflect a shared defect. A passing receipt check establishes only the properties it reports; it does not by itself establish operator identity or prove that a tool effect occurred.

Lean proofs cover specified decision-model properties. Seal currently documents that correspondence between its proved authorization model and shipped authorization path is neither tested nor proved. Read thecurrent assurance scope for the evidence and remaining assumptions.

Explore the documentation