Start in the terminal

Verify an evidence bundle

The verifier is published on PyPI and installs in one line:

pip install witnessos-verifier
witnessos-verifier --version

Run it against a bundle with no trust supplied and it reports the grade the evidence can support, capped by the checks you have given it:

witnessos-verifier verify --alpha ./path/to/evidence-bundle/

Supply your own timestamp authority and trust policy and the same bundle is checked against them:

witnessos-verifier verify ./path/to/evidence-bundle/ \
  --trust-policy /path/to/operator-policy.json \
  --tsa-url https://freetsa.org/tsr

Expected behaviour. The tool prints the derived grade and exits 0 when the bundle verifies. It exits 1 when supplied evidence fails or cannot be verified, including when it grades lower than the record claims. A lower grade never overrides an invalid result.

The grades it derives are the public ladder, and each grade names the evidence it requires:

Read this before you quote a grade. E3 records the signer's claim about a provider response and does not authenticate the provider. E4 needs externally provisioned timestamp roots and an independently signed storage-custodian receipt. A matching checksum on your own disk is not immutability evidence, and no fixture shipped with the tool should be presented as real custody.

Check an MCP server against its own declarations

pip install mcp-evidence-validator

Compare what a server declares with what it did, and write the head of the resulting ledger somewhere the ledger's holder cannot reach:

mcp-ev-validate validate \
  --declared examples/fictional-server-declared.json \
  --observed examples/fictional-server-observed.json \
  --out evidence.json --head-out evidence.head

Then audit that ledger later, against the head you kept elsewhere:

mcp-ev-validate verify --ledger evidence.json \
  --expected-head "$(cat evidence.head)"

Expected output. The audit prints:

ledger intact: 3 blocks, chain verified against the expected head
block types: {"declaration": 1, "observation_batch": 1, "report": 1}

It exits 1 when the ledger does not reach the expected head and 2 when you invoke it without one. The head is required because a chain read on its own proves nothing to anyone but the person holding the file.

Issue a passport and present it

The passport is not on PyPI yet, so install it from source today. A packaged release is going through the same signed-release process the tools above already use.

git clone https://github.com/narko4u/witnessos-passport.git
cd witnessos-passport
pip install .

Create an issuer key, issue for an agent, and verify offline against the issuer's public key:

witnessos-passport keygen --key-out issuer.key
witnessos-passport issue  --subject agent-01 --issuer empire-labs \
                          --issuer-key issuer.key --key-out agent.key \
                          --scope "fs.write:workdir:/srv/notes"
witnessos-passport verify passport.json \
                          --trusted empire-labs=<issuer-public-key-hex>

Ask whether an action is inside the agent's authority:

witnessos-passport authorise passport.json --action fs.write \
                          --resource workdir:/srv/notes \
                          --trusted empire-labs=<issuer-public-key-hex>

Then prove the agent holds the key its passport carries, over a challenge you issued for that one action:

witnessos-passport challenge --action fs.write --resource workdir:/srv/notes \
                          --ttl 120 --out challenge.json
witnessos-passport prove   --passport passport.json --key agent.key \
                          --challenge challenge.json --out presentation.json
witnessos-passport check   --presentation presentation.json \
                          --challenge challenge.json \
                          --trusted empire-labs=<issuer-public-key-hex>

Expected behaviour. Authorisation is deny-by-default: an action outside scope is refused with a machine-readable refusal code rather than a warning. A challenge is single use and dies with its window. If the replay guard cannot be consulted, the presentation is refused rather than assumed safe.

What none of these tools do

• They do not make a record true. They measure what a record can support, and refuse to inflate it.
• They do not establish that an operator honoured its own policy. That is what enforcement, not evidence, is for.
• They do not supply trust. You supply the keys and timestamp authorities you accept, and the checks fail closed without them.
• They do not replace your auditor. They give your auditor something checkable.

If a claim on this site ever outruns what these tools can prove, that is our defect, not your ambiguity. Tell us and we will correct it.