Vitnify exists so no one has to take your word for what an agent did. We hold our own verifier to the same bar: every claim on this page is checkable in public code, not asserted here.
A vitnify-receipt verifies offline — no model, no network, no secret — and the verifier
fails closed: if it cannot prove something, it returns invalid, never "probably fine".
An unsigned receipt, an unknown algorithm, or a keyless HMAC never verifies. No checked signature, no pass.
Every executed tool call must be within the granted capabilities. The receipt proves an ungranted tool did not run — it does not merely assert a policy.
Each receipt carries a signed timestamp, nonce, and run id, so one run's receipt cannot be presented as another's.
A verified receipt carries no field its version did not sign — nothing readable that the signature did not cover.
Every event kind is validated, so no check can be sidestepped by relabelling an event to hide it.
Older receipt formats stay verifiable across verifier upgrades — "verify it years later" actually holds.
The verifier is the trust boundary — if it says a receipt is valid, you are meant to believe it. So we don't ask you to. A public adversarial suite tries to forge a receipt the verifier will accept — unsigned, out-of-policy, relabelled, backdated, re-signed — and asserts the shipped code rejects every one. It imports whatever version you have installed, so you can point it at any release.
$ pip install vitnify $ python adversarial/probe_suite.py 12 attacks attempted · 0 accepted · 12 blocked control: honest receipt verifies · yes
Point the suite at an old release and watch attacks land; point it at the current one and watch them bounce. The determinism core reproduced its published anchor bit-for-bit on the first pass and hasn't moved since. The claim isn't "trust our security" — it's here's the test, run it. Find one that gets through and that's the finding we care about most.
The same forgeries, plus the reference vectors, are frozen as a public conformance kit — language-agnostic JSON that any implementation, not just ours, is measured against. It's the executable definition of a valid receipt, and CI runs it against the shipped release on every change.
Take nothing here on faith:
The conformance anchor — 9c0754…f3b0f — is a model-computation digest
anyone can reproduce bit-for-bit on any CPU with the vitni-receipt binary. If your machine
reproduces it, the determinism claim held. If it doesn't, we're wrong, and you'll know.
An embedded key proves a receipt's integrity and signer continuity — not that the signer was an
authorised runtime. Anyone can sign their own fabricated run with their own key, and it will self-verify.
Binding execution to a trusted signer requires pinning a known key (pass pinned_pubkeys
to the verifier — it ships in the open-source build) or a countersignature from the Verification Authority.
That is the boundary, and we document it in the spec rather than paper over it.
Found a way to make a forged receipt verify? That's the finding we care about most. Email security@vitnify.com.