Hand your logs to an auditor — they can check them without us

In the last piece we made a claim: the thing that should change how you evaluate compliance tooling is whether you have to trust the vendor. CloakLLM produces artifacts that verify on their own — hash chains anyone can recompute, RFC 3161 timestamps that check out with OpenSSL, signatures anyone can verify with standard crypto.

That was a promise. This release makes it operational.

There is now a separate, tiny package — cloakllm-verifier — that an auditor, a regulator, or a CI pipeline installs to check your CloakLLM artifacts themselves. Not our dashboard telling you it's fine. A command they run, that either exits 0 or tells them exactly what failed.

pip install cloakllm-verifier      # Python
npm install cloakllm-verifier      # JavaScript

cloakllm-verify all    ./cloakllm_audit                 # hash chain + RFC 3161 timestamps, one exit code
cloakllm-verify report report.json ./cloakllm_audit     # does this compliance report actually match the log?

Exit 0 means verified. Exit 1 means it doesn't check out — and it says why. Add --json and it drops straight into a CI gate.

The scenario this is built for

A regulator, or your customer's DPO, asks the question every high-risk AI deployer eventually hears:

"Prove these logs weren't edited after the fact, contain no personal data, and weren't backdated."

With most compliance tooling the honest answer is "our vendor says so." You're handing over a screenshot of someone else's dashboard.

With CloakLLM the answer is a package the auditor installs on their own machine. They point it at your audit directory. It recomputes every SHA-256 link in the chain, offline-verifies the RFC 3161 timestamp tokens, checks the signing-key provenance against the published KeyManifest, and re-validates the compliance report against the actual log. You are not in the trust path. You don't even have to be in the room.

Four things it checks

They're listed in the order an auditor builds confidence — but it's the fourth that matters most, and it's the one no closed tool can offer.

• Hash-chain integrity — recomputes every link from the canonical JSON. A tampered, reordered, or relinked entry fails.
• RFC 3161 trusted timestamps — offline-verifies each checkpoint token, proving the chain existed no later than an independent authority's clock. These are standard tokens; they verify with openssl ts -verify too, so you're never locked into our implementation.
• KeyManifest provenance + revocation — verifies a signed certificate against its published key manifest and a root-signed revocation list, so an auditor can establish who signed and whether that key was still valid.
• Compliance-report re-validation — independently re-verifies the audit chain a report describes and rejects any report that claims a verified chain, or a COMPLIANT verdict, over a log that doesn't actually verify. A report can't claim more than the log can back. It doesn't trust the report's own words — it recomputes.

And it says what it means. A passing run doesn't just print "OK" — it tells the auditor, in the same breath, exactly what the result covers and what it doesn't:

$ cloakllm-verify audit ./cloakllm_audit
CloakLLM verify -- hash chain (./cloakllm_audit)
  entries:   50000
  final seq: 49999
  [OK] chain intact: the present entries are internally consistent.
  note: proves integrity of the entries present, NOT completeness (a hash chain cannot detect removal of the LAST entries) or authenticity (run `keys` for signatures; `timestamp` for an existence anchor).
$ echo $?
0

When something doesn't check out, it fails loudly and says why — a report that claims more than its log can back is rejected, not rubber-stamped:

$ cloakllm-verify report q3-report.json ./cloakllm_audit
CloakLLM verify -- compliance report (q3-report.json)
  report verdict:    COMPLIANT
  actual chain valid: False
  [FAIL] report does NOT match the audit log:
    report claims chain_integrity=verified but the audit log does NOT verify
    report verdict is COMPLIANT but the audit chain is broken
$ echo $?
1

The detail that makes it trustworthy: no second implementation

There's a subtle trap in "we also built a verifier." If the verifier is a reimplementation of the checking logic, it can drift from the code that produced the artifacts — and then a passing verify means nothing, because the two disagree about what "correct" is.

cloakllm-verifier doesn't reimplement anything. It calls CloakLLM's own verification code — the same hash-chain walk, the same RFC 3161 verifier, the same provenance check the SDK uses. Single source of truth, no drift. What it drops is everything else: the verifier installs with only the cryptography dependencies and no PII-detection stack — no spaCy, no models. An auditor's install is lean and its purpose is unambiguous. It's a verifier, not the middleware.

(That split is the other half of this release: PII detection moved to an optional cloakllm[detection] extra, so the verification layer can be installed on its own. If you use CloakLLM for detection, pip install cloakllm[detection] keeps the full behavior.)

What a passing result does not prove — and why we say so

The last piece argued that stating your limits plainly is what makes a compliance product credible. So here they are, in the tool's own output and its README, not buried:

• A verified chain is not a complete chain. A hash chain is anchored at its start, not its end — so removing entries from the tail leaves a shorter chain that still links perfectly. Detecting truncation needs an external anchor over the latest entry, which is exactly what an RFC 3161 checkpoint provides. The verifier will only credit a timestamp that is bound to a real entry in your chain — a token stamping some unrelated hash proves nothing and is reported as such.
• A verified chain is not an authenticated one. The chain is keyless SHA-256: it proves the present entries are internally consistent, not who wrote them. Authenticity comes from the Ed25519 attestation — the keys check — which is why the CLI marks a signature-only result UNVERIFIED, not "verified," until you supply the key manifest.

So cloakllm-verify audit reports, precisely, that the entries present are internally consistent — and then tells you, in the same output, that this is not proof of completeness or authenticity, and which command establishes each. (The full list of edges, including a cross-language canonicalization corner, lives in the verifier's README. We'd rather you read the limitations than discover them.)

That honesty isn't a hedge. It's the difference between a tool an auditor can rely on and one that quietly overclaims.

Why this is a position no closed competitor can copy

There is no equivalent of cloakllm-verify report q3-report.json ./cloakllm_audit in a closed compliance product. There can't be — the checking logic is the vendor's secret, running inside the black box you were asked to trust. The moment the check leaves the vendor's servers and runs on the auditor's laptop — reusing open code, over standard formats, with results that reproduce — the vendor's word stops being load-bearing. That's not a feature a competitor bolts on; it's a property of being open and self-hosted from the start.

The honest boundary (unchanged, and still the point)

CloakLLM is the infrastructure layer that makes compliance provable. It is not a legal guarantee or a compliance certificate — no software is. And the newest cryptographic pieces, including this verifier and the timestamping it checks, have had internal adversarial review and are differentially tested against OpenSSL, but not yet a formal independent third-party cryptographic audit. Before you lean an entire regulatory defense on them, commission that audit and use an eIDAS-qualified Time-Stamp Authority. CloakLLM being open, self-hosted, and verifiable is exactly what makes that audit cheap and possible — you can't audit a black box; you can audit this.

The bottom line

The last piece said compliance you can verify beats compliance you're asked to believe. This release is the verb in that sentence. Your auditor installs one small package, runs one command, and the evidence checks out — or doesn't — without our SDK, without our servers, and without taking our word for any of it.

That's the whole idea, made real: not trust us. Check for yourself.