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.
seal demoINPUT 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
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.
- Install the gate Seal Install Seal, run the demo, then choose the tool calls that need approval.
- Check a receipt seal-check Open the browser checker to inspect the checks supported for your decision receipt.
- Review the evidence seal-assurance-kit Run receipt, policy-coverage and conformance checks from the command line.
demo.mutate
Recorded decision: BLOCK
- Document structure
- Valid
- Signature & bindings
- Valid
- Verifier-local replay
- Reproduced
- Operator authority
- Not established
- Event occurrence
- Not established