Warrant MCP server

Warrant

When a machine says something was allowed, can you check why — without trusting the machine that allowed it?

Warrant is a small, signed, content-addressed decision record. It names what was decided, the exact policy bytes in force, the reasons and evidence, the actor, and the decisions that came before it. An executable reason can be re-run by the reader instead of trusted as a log entry.

{
  "decision": "reject",
  "subject": {"hash": "d5cf37…", "note": "PR-42"},
  "under": ["cb3a0a…"],
  "because": [
    {"kind": "check", "check": "05d234…", "runtime": "cmd@v1",
     "verdict": "fail", "transcript": "9dc0c3…"},
    {"kind": "prose", "text": "policy clause 1: coverage drops"}
  ],
  "evidence": ["9dc0c3…"],
  "actor": {"id": "agent-b@vendor2"},
  "prior": ["00f79f…"],
  "ts": 1751677200
}

The canonical body hash is the record's identity. Changing the decision, policy reference, reason, evidence or prior edge changes that identity. The signature says which key signed the body; whether that key belongs to the named actor is a separate trust-configuration question. A rejection is a durable record, not an absence.

Warrant is not an agent framework, blockchain or observability system. It is one file format and five filing verbs, designed to be boring.

The format is written up in The Reason Runs Again (10.5281/zenodo.22172098, paper v1.0.0, 2026-08-30 — deposited, not peer reviewed; see papers/).

Try it

pipx install warrant-verify   # or: pip install warrant-verify

warrant init
warrant keygen --out me.key
printf 'demo diff\n' > diff.patch
printf 'clause 1: no coverage drop\n' > policy.txt
printf '#!/bin/sh\nexit 1\n' > check.sh && chmod +x check.sh

POL=$(warrant policy add policy.txt)
P=$(warrant propose --subject diff.patch --under "$POL" \
      --reason "utility functions needed" --actor me@host --key me.key)
R=$(warrant reject "$P" --check check.sh --verdict fail \
      --reason "clause 1: coverage drop" --actor me@host --key me.key)
printf '#!/bin/sh\nexit 0\n' > check.sh
A=$(warrant accept "$R" --check check.sh --verdict pass \
      --actor me@host --key me.key)

warrant why "$A"
warrant verify

Every file used above is created above. The final warnings say that the key-to- actor binding is unverified until a trust configuration supplies that authority; a valid signature is not silently promoted into a valid identity claim.

The warrant-verify distribution installs four commands:

• warrant — file, inspect and verify decisions;
• warrant-mcp-server — let an MCP client file its own decisions;
• warrant-mcp — seal calls passing through another MCP server;
• warrant-anchor — batch WarrantIDs into a Merkle anchor.

ski@v1 reasons replay offline through one bundled Σ-GLYPH Book I v0.5 evaluator, pinned by digest and checked before import. Reserved ski@v2 is not admitted by any body version and ships no executable candidate bytes.

The longer walkthrough, including negative controls, is docs/try-this-in-fifteen-minutes.md.

Machine boundary

For CI, MCP or an agent framework, verify an initialized store with --store-mode --json:

warrant --store ./evidence-pack/.warrants verify --store-mode --json | jq -e '.ok'
warrant-go verify --store-mode --json ./evidence-pack/.warrants | jq -e '.ok'

{"report":"warrant.verify-report@v0","grade":"base","ok":true,
 "records":3,"errors":0,"warnings":1,
 "findings":[{"level":"WARN","subject":"<WarrantID>","message":"..."}]}

--store-mode is part of the safe predicate: a missing or uninitialized store fails closed instead of looking like an empty successful verification. Python takes the store through the global --store; Go takes it positionally.

Consumers may rely on these boundaries:

Shortened. The full README is on GitHub.