Skip to content

LOCAL MCP APPROVAL · Claude Code

Review risky tool calls before they run.

Seal sits between Claude Code and a local MCP server. Choose the tools that need approval, inspect each request, and allow at most one execution per approval.

Only selected calls routed through Seal are gated. Bash, direct access and other routes remain outside its control. Read the limits.

Linux x86-64 · macOS x64/arm64 · Node 20+. Windows and Linux ARM are unsupported.

A recorded run of v0.4.0 · seal demo
Recorded CLI transcript01 / 03

INPUT REQUIRED

Tool
demo.mutate · guarded
Child
seal __demo-server
{
  "line": "seal demo wrote this line"
}

This parsed call; at most one run; 2 min.

Child calls observed: 0.

child calls observed: still 0 (read from <demo>/child/data.txt.count) — approval shown, nothing executed
View this recorded run

Viewing controls only; nothing here runs Seal.

Excerpts from the v0.4.0 transcript; <demo> abbreviates its directory. This run recorded a BLOCK receipt; the demo does not always print that line.

Choose the calls

Select the tools that need a human decision. Other tools on that route pass through without approval.

Bind each approval

Review the tool and its arguments. An approval cannot authorize a second execution.

Inspect the decision

Keep a signed decision receipt. Check its signature and replay separately; it does not prove an effect occurred.

Start with the harmless demo. Run it locally to inspect your own approval and replay outcome.

Approve the exact tool call.

seal demo

Recorded CLI transcript, not a captured client session. Run the demo after installing Seal.

Guarantees & limits

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 is a gate, not a sandbox. Calls and effects outside the configured Seal route remain outside its control.

The decision leaves a signed receipt. Open it in the browser checker or use the assurance CLI to see what the recorded evidence establishes.

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 the current assurance scope for the evidence and remaining assumptions.

Take it to your own tools

After the demo, choose what to protect, check a receipt, or explore the assurance tools.

Decision receipt Recorded 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 the browser checker guide to run this yourself against the example receipt and its demo public key.