Docs

VeriCID guarantees the tool an agent executes is byte-identical to the tool that was registered — dependencies included. It does not claim the tool is safe: that's why every tool runs sandboxed, and why attestations (auditors endorsing immutable CIDs) are a separate layer.

QUICKSTART

Install & lock a tool

Resolution fetches the artifact, hash-verifies it against the registered CID, shows you the sandbox permissions sealed inside that CID, and pins the exact version in vericid.lock. Execution never trusts the registry's mutable latest pointer.

$ vericid install @demo/weather
@demo/weather@1.0.0 verified ✓
  network → api.open-meteo.com
Approve and pin to vericid.lock? [y/N] y

Run it from your agent

vericid run re-verifies the pinned CID on every start, then spawns the tool as a stdio MCP server inside a Deno default-deny sandbox with only its approved permissions. Point Claude Code (or any MCP client) at it directly.

{ "mcpServers": { "weather": { "command": "vericid", "args": ["run", "@demo/weather"] } } }

Publish your own

The packer seals your entrypoint and its entire dependency tree into one self-contained bundle — the CID covers every byte that will execute. Pure-JS in v1; native addons are rejected at publish time.

$ vericid publish ./my-tool
packing @you/my-tool@1.0.0 (sealing full dependency closure)...
published — artifact bafkrei… (733,970 bytes, sealed closure)

What a mismatch looks like

Any byte out of place — a rug pull, a swapped description, a compromised mirror — and the local hash check refuses before anything runs. This is the whole product in one error message.

🛑 INTEGRITY FAILURE for @demo/weather:
  expected bafkreiecu2cn…tamq
  actual   bafkreie7ux4a…jngq
Refusing to run.