witseal — execution witness
[witseal] initializing witnessed execution runtime
[policy] loading quickstart policy pack
[policy] default mode: deny-by-default
[action] shell.exec "echo hello"
[classify] risk: C0
[decide] allow
[exec] mediated execution → exit 0
[receipt] receipt show 1
[action] shell.exec "rm -rf /"
[decide] deny by policy
[verify] evidence chain VALID
Execution Evidence Infrastructure

WitSeal

Prove what actually happened.

Records witness events and execution receipts in an evidence chain so agent actions can be inspected and verified within the documented claim boundary.

GitHub npm Demo Security
Install
npm install -g @witseal/cli@0.2.0
Execution primitives
evidence chain
Append-only witness events with hash links between recorded actions.
execution receipts
Structured records that let a reviewer inspect what was witnessed.
receipt replay
Reconstruct recorded evidence relationships without re-running the command.
deny-by-default policy
No active policy pack means the action is refused and recorded.
tamper-evident log
Hash-chained integrity. Silent modification of execution history is detectable.
evidence export
Portable evidence packages that can be verified offline for continuity.
risk classification
Each action is classified by risk before the policy decision. The risk level is recorded as part of the evidence.
independent verification
Anyone can check a receipt with witseal verify — VALID or INVALID — with no WitSeal account or server.
Architecture
agent action
↓
risk classification
↓
policy evaluation
↓
policy decision
↓
mediated execution
↓
witness event + receipt
↓
hash chain update
Integrations
WitSeal is infrastructure for execution evidence. Each integration is shown by the highest evidence level it reaches — one level per integration, not a capability checklist. Where WitSeal runs the action itself, it produces a full execution receipt (Witnessed Execution). Where the host runs the action and lets WitSeal observe the result, it records that as evidence (Witness). Witnessed Execution spans two execution boundaries — Full Execution Coverage, where WitSeal owns the action end to end, and Tool-Scoped Coverage via MCP, where WitSeal witnesses the calls routed through its own MCP tool.
Witnessed Execution product category Same receipts. Different execution boundaries.
Full Execution Coverage Who executes: WitSeal-mediated executor.
WitSeal MCP
Witnessed Execution
available
OpenCode
Witnessed Execution
available
LangGraph
Witnessed Execution
available
OpenAI Agents SDK
Witnessed Execution
available
Temporal
Witnessed Execution
available
Tool-Scoped Coverage via MCP Who executes: the host agent/runtime. Witnessed execution via the WitSeal MCP tool. Receipts are generated for operations executed through the WitSeal MCP tool; host-native execution remains outside the witness boundary.
OpenHands
Witnessed Execution
available
OpenClaw
Witnessed Execution
available
Hermes
Witnessed Execution
available
Witness product feature WitSeal records the host's execution as evidence.
Claude Code
Witness
available
Cursor
Witness
available
Codex
Witness
planned
Witness vs Witnessed Execution — the difference is the source of trust. Witness records the result the host reports: the evidence is only as trustworthy as the host. Witnessed Execution means WitSeal ran the action itself, so the receipt is independently verifiable — anyone can check it with witseal verify, with no trust in the host required. In a sealed host like Claude Code you get Witness today; you integrate OpenCode, a framework, or WitSeal MCP to reach Witnessed Execution — the next, independently verifiable level of evidence.

Full capability matrix, including Gate →
CLI execution modes
How the WitSeal CLI enforces a policy decision at runtime — a safety setting of the runtime, not a product tier. The product categories are the evidence levels above; these two modes are a --mode flag on the own-execute path. Deny-by-default is the safe default.
--mode gate — deny-by-default (the safe default)
The runtime's default safety posture: WitSeal sits in the action's critical path and a deny decision blocks execution, recorded as evidence. A technical default, not a sold option.
--mode witness — explicit
Does not block. The policy decision — including a deny — is recorded as evidence, but the action executes, under a distinct outcome (witnessed_executed). The constraint is by policy decision, not authorship.
Adoption path
1 · Witness
Recommended first step. Run real actions in Witness Mode (--mode witness): nothing is blocked, and every policy decision — including a deny — is recorded as evidence. See what your agent actually does.
2 · Understand
Inspect the receipts and verify the chain. Learn which actions a policy would deny, and refine the pack until it matches what you observed.
3 · Enforce
Drop --mode witness. Gate Mode is the default (deny-by-default): the same deny now blocks execution, recorded as evidence.
Related work
WitSeal operationalizes execution-layer trust. The constitutional layer above it — authorial sovereignty for AI systems operating on behalf of individual Authors — is specified in PAI-Kernel, an open protocol infrastructure project for deployment-layer governance.

The two are independent and usable separately. Together they define operational and constitutional trust for the deployment layer.