What "Offline-Verifiable" Actually Means, and How to Demo It in Five Minutes

The Word That Means Less Than You Think

Walk through the marketing pages of any agent identity, agent observability, or agent governance product shipping in 2026 and you will find the same word in the same place: tamper-evident.

It sits in the audit section, usually next to a chain icon, often with a sentence like "every action is recorded in a tamper-evident audit trail." The buyer reads it, nods, and moves on.

The word is doing more work than the product behind it.

In June 2026 we tested nine major agent identity platforms against thirteen capabilities, every claim against a primary source. The full results are in [the white paper](https://vorim.ai/whitepaper). One finding worth pulling out here: not one of the nine ships an audit bundle that a counterparty can verify without calling the vendor's API.

Most of them ship an audit log. Most of them sign that log on the way in. Many of them export the log on request. None of them lets the reader of the export prove its authenticity without the vendor's blessing.

That is not tamper-evident. That is "trust us about whether this has been tampered with."

What the Word Should Mean

"Offline-verifiable" is the term that does the work tamper-evident pretends to do.

Offline-verifiable means: a counterparty receives an audit bundle, runs a verification routine on their own hardware, and gets a deterministic yes-or-no answer about whether the bundle is authentic. The vendor is not in the trust path. The vendor's servers can be down, taken over, or sued out of existence, and the verification still works.

That is a much stronger property. It is also the property a security team, a regulator, and a counterparty all actually need. The reason it is not the default in this category yet is that getting it right requires three primitives lined up correctly:

1. The agent itself signs the audit event at source, before the bytes leave the process. Not the platform signing on behalf of the agent. The agent's own key, applied to a canonical form of the event, transparently inside the SDK call.

2. The exported bundle is self-contained. It carries the agent's public key, a canonical-form specification, and a manifest hash. The verifier never needs to phone home to fetch the key.

3. The verifier is open source, has no vendor dependency, and is small enough to audit. Closed source verifiers, or verifiers that wrap a vendor SDK, recreate the trust problem they were supposed to remove.

If all three are true, a buyer's security team can hand the bundle to their regulator and the regulator can verify it from a laptop with no internet connection. If any one of the three is missing, the chain has a vendor-shaped link in it.

Where the Three Primitives Currently Land in the Market

Here is the honest map as of June 2026, with the receipts.

Per-event signing at source. Absent from all nine major vendors we tested. Okta, Microsoft Entra Agent ID, Cisco ZTA, 1Password Unified Access, Salesforce Trusted Agent Identity, the Cloudflare and GoDaddy partnership, AWS Verified Permissions, Auth0 Auth for GenAI, and Opal Security. Each platform signs at the platform layer if it signs at all. Sources for each cell are footnoted in [Section 1.1 of the white paper](https://vorim.ai/whitepaper).

Self-contained export bundles. Most platforms export audit data. Few embed the public keys needed to verify per-event signatures in the same artefact, because the per-event signatures themselves do not exist. The Cloudflare and GoDaddy partnership, on Web Bot Auth, gets closest in spirit because it leans on offline-verifiable HTTP message signatures, but those signatures cover the request, not the full audit record.

Open-source verifier with no vendor dependency. Nothing in the major-vendor set ships one. Some open up parts of their SDK or schema. None of them publish a standalone verifier you can install and point at a bundle without their other infrastructure in the loop.

Three primitives, three gaps. The gap is uniform across vendors.

How to Test This in Five Minutes

Words on a page are still words on a page. The point of this post is to show you what offline verification looks like end-to-end, in a way you can replicate, with a stopwatch.

Open [vorim.ai/verify-demo](https://vorim.ai/verify-demo) in any modern browser. The page runs entirely client-side using Web Crypto, with no Vorim API call. You will:

1. Generate an Ed25519 keypair. The private key never leaves the tab.

2. Emit three audit events. Each one is signed at source with the canonical bytes event_type|action|resource|input_hash|output_hash|result before it leaves your process.

3. Build an export bundle. Events plus the agent's public key plus a SHA-256 manifest over both.

4. Verify the bundle. Same code path as the open-source verifier CLI, running in your browser.

5. Tamper with one byte and verify again. Change the resource field on event three from acct-9871 to acct-attacker. Watch the verifier reject. The whole point of the primitive is that step five fails the moment a byte changes.

When you are done, download the bundle the page produced. Then, in your own terminal:

npm install -g @vorim/verify
vorim-verify bundle.json

You should get a byte-identical verdict to the one the browser showed. If you do not, the page is wrong and we want to know about it. The [@vorim/verify](https://www.npmjs.com/package/@vorim/verify) package is MIT-licensed, has zero runtime dependencies, and the core signature-verification path is a few hundred lines of plain TypeScript. You can read it, audit it, and reimplement it in another language in an afternoon.

That is what offline-verifiable looks like.

What Verification Does, and Does Not, Prove

Honesty matters here, because most claims about cryptography are overstated. Verification proves three things and only three things:

1. The bundle has not been edited since the issuer produced it. Manifest hashes catch any byte change.

2. The agent identified in each event signed the canonical bytes recorded. Signatures fail if the event was modified, or if the wrong key signed it.

3. The bundle is self-contained. No call to Vorim, or anyone else, is required to verify it.

Verification does not prove:

- That the agent is who it claims to be. That is a separate question handled by a trust anchor, an identity directory, or out-of-band attestation. The verifier confirms the binding between a signature and a public key in the bundle. Whether that public key represents who it says it does is a level above.

- That the bundle is recent. Add a timestamp authority or a witnessed hash chain if freshness matters to your use case.

- That no events were dropped before export. A bundle with N signed events is a true record of those N events. Whether other events were silently omitted on the way out is a separate question, answered by comparing the bundle against the issuer's event counter.

These limits are not weaknesses of the primitive. They are the line where this primitive stops, and where the next layer of the stack (identity attestation, timestamp authority, counterparty replication) starts.

Why This Matters for the Three Buyers Who Actually Care

This is not abstract for everyone. Three buyer profiles run into the gap weekly, and the conversation is the same shape each time.

Financial services. A fintech compliance team needs to prove to a regulator that the AI agent processing customer transactions actually did what the platform says it did. "Trust our audit log" is not a sentence a bank examiner is going to accept. The bundle has to verify on the examiner's laptop. With per-event signing at source and a self-contained bundle, it does.

Agent platforms. A LangChain, CrewAI, or framework vendor selling into enterprises has a multi-tenant trust problem: customer A wants to prove their agents did X, but the audit records on the platform are signed by the platform's key, not the customer's agent. The customer's auditor cannot verify those records without putting the platform vendor in the trust chain. With per-agent signing at source, the customer's agent signs and the platform vendor is no longer load-bearing for the audit trail.

Internal IT and security. An incident response team reviewing an agent that took an action at 3am needs cryptographic certainty about what the agent did. "The platform's logs say X" gets you partway. "The agent's own signed record says X" is what closes the ticket. The same primitive that helps a regulator helps the on-call security engineer.

In every case, the part of the conversation that used to be "well, trust our log" gets replaced with "run this command against the bundle." That is a different sale.

Where This Sits in the Standards Path

The canonical bytes used here (event_type|action|resource|input_hash|output_hash|result) are deliberately the simplest stable form that lets an SDK sign and a verifier reproduce without a JSON canonicalisation library. We picked the simple form because every additional primitive a verifier needs to depend on is one more attack surface, one more reimplementation cost in other languages, and one more reason a security review pushes back.

The simple form will be replaced by an RFC 8785 JSON Canonicalization Scheme payload in a future revision of [VAIP](https://datatracker.ietf.org/doc/draft-nyantakyi-vaip-agent-identity/), the Vorim Agent Identity Protocol we have submitted to the IETF. The current revision (-01) covers identity, permissions, and the v0 canonical signing form. A revision (-02) is in progress that adds hash-chained ingest, schema fields for replayable decision evidence, and references the open-source verifier as the conformance test for the signing-and-verification subset of the protocol.

Standardizing this is the point. If the only verifier on earth is the one we ship, the trust problem has moved by one layer. The goal is multiple independent verifiers, written in multiple languages, all producing the same verdict against the same bundle. That is the same shape as TLS certificate verification: the protocol is the source of truth, not any single implementation.

The Smallest Thing That Changes the Conversation

If you are buying agent identity infrastructure in 2026, ask one question of every vendor on your shortlist:

"Can you give me an export I can verify offline, with a command I run locally, against an open-source verifier I have read?"

That is the smallest thing that changes the conversation. The answer separates the vendors who ship the primitive from the ones who say tamper-evident and hope no one reads the spec.

The demo at [vorim.ai/verify-demo](https://vorim.ai/verify-demo) is one answer to that question. The white paper at [vorim.ai/whitepaper](https://vorim.ai/whitepaper) is the receipts for the others.

Ready to build with agent identity?

Free plan: 3 agents, 10K auth events/month, full SDK access. No credit card.