Apohara · provenance

SEALCHAIN

Prove your AI artifact wasn't tampered with — and exactly how much that proof is worth.

A single Rust binary — a CLI and an MCP server — that seals any file into a tamper-evident <artifact>.seal.json receipt anyone can verify offline. Real cryptographic layers, no account, no SaaS, and no verified=true hardcoded anywhere: every layer re-checks its own crypto, or the seal aborts.

$cargo install apohara-sealchain
View source →

The sequence

Seal a file, verify it, then flip a single byte and watch verify refuse to pass.

apohara-sealchain · live recording
sealchain seals model.bin into a tamper-evident receipt (layers hmac, ed25519, c2pa), verifies it offline returning PASS on every layer, then after appending a single byte the same verify returns FAIL on the content hash and the process exits with code 1

An unedited recording of the binary — seal, verify, then a one-byte tamper. A seal is evidence, not a verdict: verify reports each layer with a reason and exits non-zero the instant a byte moves.

The five layers

All five are implemented and live-exercised — no placeholders, no unexercised crypto. A seal proves the properties of the layers it actually carries, nothing more.

HMAC-SHA256
Local integrity (symmetric) — the secret is never in the receipt.
Ed25519
Authorship by the key holder — public key embedded for offline, self-contained verify.
C2PA
A provenance manifest is bound to the payload — real JUMBF manifest, self-signed in v0.1.
RFC-3161 TSA
Existence-before-a-point-in-time, per the authority — real token; default TSA is not eIDAS-qualified.
Sigstore Rekor v2
Public, append-only transparency-log inclusion — real DSSE entry, offline-verifiable inclusion proof.

What it does

Three properties that hold whether a human or an agent drives the binary.

Offline verification

Anyone can verify a .seal.json with no account and no network. The Ed25519 public key is embedded in the receipt, so verify needs no key server — just the file and its sidecar.

No hardcoded verdict

Every layer re-derives and re-checks its own crypto at verify time, or the seal aborts. One flipped byte fails verify and exits non-zero — there is no faked pass anywhere in the tree.

CLI + MCP server

Seal and verify from the shell, or run apohara-sealchain mcp and let an agent call seal_artifact / verify_receipt as native MCP tools — stdio by default, streamable-HTTP for CI.

Honest by design

A seal proves the properties of the layers it carries — and the tool says, plainly, where that stops.

What a seal proves

  • ✓ The bytes match the receipt — content hash binds the artifact to the sidecar.
  • ✓ The listed crypto layers each verified — present and re-checked, never asserted.
  • ✓ Offline, reproducible verification — math you can re-run yourself from the receipt alone.
  • ✓ Verify exits non-zero the instant a byte moves.

What a seal does NOT prove

  • — That the content is correct, true, or safe — only that it is unchanged since sealing.
  • — Trust in a signature is only as good as the key's custody.
  • — The default timestamp is not a legally qualified eIDAS token, and the C2PA manifest is self-signed in v0.1.
  • — A seal is evidence for a human or a policy to weigh — not an authority's verdict.

Quick start

Three commands from install to an offline PASS / FAIL.

1
$ cargo install apohara-sealchain

Builds from source — the lowest-trust path.

2
$ apohara-sealchain seal <file>

Writes <file>.seal.json — offline default: HMAC + Ed25519 + C2PA.

3
$ apohara-sealchain verify <file> <file>.seal.json

PASS / FAIL, offline — exits 0 on pass, non-zero on tamper.

Dual MIT / Apache-2.0 Rust single binary CLI + MCP Ed25519 C2PA offline verify