5 Key Questions to Ask Any AI Agent Verification Vendor

When "Verifiable" Becomes a Marketing Buzzword

Just about every vendor is now selling "verifiable agents." The phrase shows up in press releases, pricing pages, and sales decks — it sounds rigorous and professional. But most of the time, it means whatever the vendor wants it to mean.

This is a real problem for buyers. Because "verification" has a precise technical meaning: either a third party can check the record without trusting any of the parties involved, or they can't. There's no middle ground — and marketing lives exactly in that middle ground.

The original author offers five questions that cut through the noise, and recommends asking them in order. Vendors with genuine verification capabilities will answer all five cleanly. Vendors with nothing more than a dashboard tend to get evasive by the second question.

Question 1: Can a Third Party Verify the Record Without Trusting You?

This is the heart of the whole exercise. Hand the execution record to a program written by someone who has never heard of the vendor — a program that has only the record, the claimed result bytes, and a hash function. No network access, no API keys, no login credentials.

Can it answer one question: has this record been modified since it was created?

A good answer sounds like: "Yes. Verification is pure recomputation — hash the exact input and output bytes, compare against the receipt, walk up the hash chain. Anyone can write a verifier from the spec in an afternoon."

A bad answer sounds like: "use our verification dashboard," "call our API to check," or "our verifier app will confirm it." Each of these sneaks trust back in through a side door. If verification requires the vendor's infrastructure, keys, or software, you're not verifying — you're asking the vendor to vouch for themselves.

The underlying technical foundation here is the cryptographic hash function. A hash function maps data of arbitrary length to a fixed-length digest (e.g., SHA-256 produces 256 bits). Its key properties are one-wayness and collision resistance: given an input, computing the hash is trivial; inverting the hash is computationally infeasible. A single changed byte produces a completely different output. A hash chain embeds each record's hash into the next record's input, creating an ordered cryptographic dependency chain — tamper with any record in the chain and every subsequent node's hash becomes invalid, detectable by anyone who reruns the math. This is why "pure recomputation" achieves zero-trust verification: the verifier doesn't need to believe anyone's account of the result. The math is the arbitrator.

Question 2: What Does Verification Actually Prove?

Precision here separates serious vendors from salespeople. Ask the vendor to state their claim in one sentence, with no adjectives.

A good answer: "A verified receipt proves that the preserved result has not been altered since it was saved." That's the entire claim. It's deliberately narrow — narrow claims are checkable, and checkable claims survive audits.

A bad answer is any version of "it proves the agent did the right thing." Verifying a record is not the same as verifying correctness. A receipt can't tell you whether the tool was called with reasonable inputs, whether the answer was correct, or whether anything actually happened in the real world. If an agent called a payment API, the receipt proves the call record is intact — it doesn't prove the money moved. That requires checking with the bank.

Watch for scope creep in the answer. "Proves execution integrity" sounds strong but means nothing. "Proves output is trustworthy" is a feeling, not a check. Vendors who exaggerate here are telling you they don't understand their own boundaries — which means you can't trust them to hold those boundaries.

Question 3: Is the Format Open or Proprietary?

A receipt format only works as infrastructure if anyone can implement it. Ask: "Could an engineer I've never met write a verifier from your documentation alone, without touching your systems?"

A good answer points to a publicly published, versioned specification — developed in the open, publicly reviewed, with a real revision history. The gold standard is a document that went through a standardization process, such as an IETF Internet-Draft — where strangers with no stake in the vendor's success read the text and file issues. Fifteen rounds of that kind of review surfaces edge cases the authors never noticed.

A bad answer is "our proprietary format," documentation behind a login wall, or a spec that says "contact sales for verification API." Proprietary receipts are vendor lock-in dressed up in cryptography: auditors need accounts on a dozen platforms, evidence dies when the startup dies. And every vendor using a proprietary format has a quiet incentive to keep verification just difficult enough that you can never leave.

Open formats also let you compare vendors on equal terms. When every receipt follows the same spec, you're comparing who mints the best receipts — not whose dashboard looks the most polished.

The IETF Internet-Draft process is a key reference for understanding what "open review" actually means. An Internet-Draft is the precursor to an RFC (Request for Comments — the final form of an internet standard). Anyone can read and comment on it for free, and every revision and review comment is publicly archived. IETF working groups are made up of engineers from different organizations around the world with no shared financial interest — their job is to find problems: ambiguities, security vulnerabilities, and implementation traps. This is fundamentally different from a spec a vendor publishes themselves, where the author and the implementer are the same party and there's no external pressure to expose unfavorable edge cases. A spec that has survived multiple rounds of public review, with a visible revision history, derives its credibility from process transparency — not the publisher's authority.

Question 4: Does Verification Survive the Vendor's Disappearance?

Ask: if the vendor shuts down next Tuesday, what happens to five years of receipts?

A good answer: "Nothing. Verification is hash recomputation against the receipt and the saved bytes. No network, no vendor API, no license server required. Your evidence is a file and a hash function — both will continue to exist."

A bad answer involves any live dependency: an API endpoint, a certificate service, a hosted verifier, a chain the vendor operates. Evidence with an expiration date isn't evidence — it's a subscription.

This question also flushes out variants of "anchoring." An anchored hash proves only that a hash existed at a point in time; it says nothing about whether the hashed content is true. And if the anchoring scheme relies on a vendor-operated relayer or indexer, you're back to trusting the vendor. Ask explicitly: when they're gone, what exactly are you holding? If the answer is "our API," walk away.

Timestamp anchoring is a common technical approach in this space that deserves its own clarification. Anchoring schemes typically submit a hash value to a trusted third-party ledger (such as a public blockchain or trusted timestamp service) to prove "this hash existed at this moment." This addresses temporal trustworthiness but not content integrity: anchoring proves only that the hash existed at a point in time, not that the corresponding content is genuine or correct. More critically, if the anchoring scheme depends on a vendor-operated relayer to submit hashes to the ledger, or a vendor-operated indexer to look up anchoring records, then even if the underlying ledger is decentralized, the verification path still runs through the vendor. When the vendor disappears, you lose the ability to independently trace from receipt to anchoring record. A scheme that truly survives offline requires that all information needed for verification be contained within the receipt file itself.

Question 5: Who Captures the Record — the Agent or the Execution Layer?

This is the question vendors most hope you never ask, because it exposes the most common failure mode in the field.

A good answer: "The execution layer captures the record at the moment the tool runs, before the result is returned to the agent. The agent never touches the receipt — it cannot forge, edit, or suppress a receipt without breaking the hash chain."

A bad answer is any form of self-reporting: logs written by the application, conversation transcripts, "the agent confirmed completion," summaries generated after the fact. An agent is the least trustworthy witness to its own behavior — it has every incentive to report success. A verification story built on self-reporting is a story, not a check.

Press on timing. "Captured at execution" means the record is written by the layer running the tool, with exact input and output bytes, at the moment of execution. "Logged after the run" means someone reconstructed it afterward — and reconstruction is where fabrication breeds.

The One Thing to Remember

If there's only one thing to take away: verification means a stranger who trusts no one can rerun the math and confirm the record is intact. Everything else is marketing.

The original article mentions an open Internet-Draft that defines exactly this: AER-1 (Verifiable Execution Receipt format), currently at draft-zambo-aer1-15 on the IETF datatracker. It specifies what to capture, how to hash inputs and outputs, how to chain receipts, and how a third party can verify using only the record and a hash function. It's still a draft rather than a final standard, and implementations exist in multiple languages. Zambo is the reference implementation, minting independently verifiable receipts for each tool call.

For buyers, these five questions provide a practical due-diligence framework: don't listen to what the vendor claims — look at whether the evidence can prove itself without the vendor in the room.