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 intact

[verify] claim WL3 · boundary WL2 → downgrade to WL2

Execution Evidence Infrastructure

WitSeal

Graded evidence for what your agents did.

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 PyPI NuGet Demo Verify live Security

Install

npm install -g @witseal/cli@0.4.2

pip install witseal

pipx install witseal

dotnet add package WitSeal.AgentFramework

Connect

witseal connect

Why WitSeal

Governance says what should happen. WitSeal proves what did happen. As teams put AI agents on real tasks, the question for security and compliance is simple: what did the agent actually do, and can you prove it later? WitSeal turns each significant agent action into a portable, hash-chained execution receipt.

From build-time attestation to runtime evidence. WitSeal bridges build-time attestation to runtime evidence — and every receipt can be checked offline, with no WitSeal service and no account, for evidence-chain integrity and whether its claimed level holds for the declared boundary.

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 evidence chain

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.

offline receipt check

Anyone can check a receipt offline with witseal verify — no WitSeal account or server. It confirms the evidence chain's integrity and whether the claimed level holds for the declared boundary: accept, downgrade, or reject.

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. Each integration below carries its current status. Except where marked live or demo, these are planned targets — not yet shipped; we mark an integration live only after its receipts verify end to end.

Witnessed Execution product category Same receipts. Different execution boundaries.

Full Execution Coverage Who executes: WitSeal-mediated executor. For the framework adapters below, coverage is scoped to the WitSeal-authored tool the host routes execution through — not execution the framework runs outside it.

MCP Tool-Call Receipts (powered by WitSeal)

Witnessed Execution

planned

OpenCode

Witnessed Execution

planned

LangGraph

Witnessed Execution

planned

OpenAI Agents SDK

Witnessed Execution

planned

Temporal

Witnessed Execution

planned

OpenHands

Witnessed Execution

planned

CrewAI

Witnessed Execution

planned

PydanticAI

Witnessed Execution

planned

Google ADK

Witnessed Execution

planned

AWS Strands

Witnessed Execution

planned

AutoGen

Witnessed Execution

planned

GitHub Copilot SDK

Witnessed Execution

planned

Microsoft Agent Framework

Witnessed Execution

planned

Cloudflare Workers

Witnessed Execution

demo

Mastra

Witnessed Execution

planned

Kilo Code

Witnessed Execution

planned

Cline

Witnessed Execution

planned

Witnessed Execution

planned

SWE-agent

Witnessed Execution

planned

Open Interpreter

Witnessed Execution

planned

Tool-Scoped Coverage via MCP Who executes: the host agent/runtime. Witnessed execution via the WitSeal MCP Receipts tool. Receipts are generated for operations executed through the WitSeal MCP Receipts tool; host-native execution remains outside the witness boundary.

OpenClaw

Witnessed Execution

planned

Hermes

Witnessed Execution

planned

Codex CLI

Witnessed Execution

planned

Windsurf

Witnessed Execution

planned

Antigravity

Witnessed Execution

planned

Replit

Witnessed Execution

planned

Witness product feature WitSeal records the host's execution as evidence.

Claude Code

Witness

planned

Cursor

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 carries first-hand execution evidence — checkable offline with witseal verify, no account or server. Verify tests the receipt against the boundary it declares; it does not independently confirm that boundary. In a sealed host like Claude Code you get Witness today; you integrate OpenCode, a framework, or WitSeal MCP Receipts to reach Witnessed Execution — the next, stronger 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.

The Witnessed Execution Protocol (WEXP)

WEXP is an open specification for classifying the strength of execution-related evidence about actions performed by software and AI systems. WitSeal is a reference implementation; the specification is vendor-neutral and prevails over any implementation, including ours.

Read the Internet-Draft on the IETF Datatracker →