Verifiable Decision Provenance

Executive summary

Enterprises do not only want AI controls. They want evidence that the controls actually operated. If an agent was denied, approved, masked, or allowed to proceed, serious buyers will eventually ask:

• where is the record?
• can we verify it independently?
• how do we know it was not altered later?
• does it help with audit, incident review, and compliance oversight?

Many AI governance stories stop at ordinary logging, which answers some of these questions and not all of them. The stronger model is verifiable decision provenance: every material governance decision, a tool call permitted or denied, a document redacted, a human approval granted, emits a cryptographically attested record that a skeptical third party can verify without trusting the operator's word, or the operator's dashboard. This paper explains why ordinary telemetry is weak evidence for production AI governance, how the evidence chain is constructed layer by layer, and, just as important, what such a chain proves and what it deliberately does not.

The problem: most governance evidence is too soft

When a buyer asks whether an AI control worked, many vendors effectively answer:

• we logged it
• we traced it
• we can show it in a dashboard

That is better than nothing, but it is still soft evidence. Serious enterprises care about:

• tamper-evidence posture
• independent verification
• chain of custody
• whether approvals and denials are preserved cleanly, tied to the events they governed
• whether the evidence survives dispute, audit, and incident pressure

If the answer reduces to "trust the vendor UI," the story is thin.

Why ordinary logs are not enough

Traditional logs answer useful operational questions:

• what happened
• when it happened
• which component emitted the event

They are weaker on the harder governance questions:

• can the record be independently verified?
• was the event altered, deleted, or backfilled later?
• is the approval cryptographically tied to the actual execution event?
• can reviewers distinguish permit, deny, redact, approval, and timeout states cleanly?

For agentic systems those questions matter, because the runtime is being trusted with business actions and knowledge access. On the day it matters, a regulator's inquiry, a customer dispute, an incident post-mortem "our database says the action was approved" is an assertion. A signed receipt whose integrity anyone can recompute is proof.

The evidence chain, layer by layer

Every governance decision emits a record envelope attested by a decision receipt, and the receipts are bound together so the whole history vouches for every entry:

• Signature. The decision's canonical payload is signed with Ed25519; the receipt carries the signature, the signing public key, and the payload's SHA-256 hash. Canonicalization is deterministic, so any verifier reproduces the exact signed bytes.
• Batching. Receipts are batched into an RFC 6962-style Merkle tree with domain-separated hashing; each receipt carries its inclusion proof.
• Root signing and independent time. Each batch root is signed by a dedicated signing key and countersigned by an independent RFC 3161 timestamp authority, binding the batch to a time asserted by a third party, not by the operator's clocks. The timestamp leg runs on every batch. The signing key is held in an HSM (AWS KMS) where a deployment enables that mode; the default is an in-process key, which is a weaker custody claim and is stated here rather than glossed.
• The chain. Batches form an append-only hash chain, each committing to its predecessor through a running accumulator. Deleting a batch leaves a gap; reordering breaks the accumulator; editing any root breaks recomputation.
• The external copy. The design carries a fifth leg: chain checkpoints published to write-once (WORM) object storage under compliance-mode locking, an externally held copy the platform operator cannot alter or delete before retention expires. This leg is implemented and configurable, and it is OFF by default — it is not enabled on the hosted service today, so no checkpoint has yet been WORM-published. Until an operator turns it on, the four legs above are what carries the guarantee, and the paragraph on the trust base below says plainly what that leaves outstanding.

Signing is asynchronous and off the decision hot path, so evidence adds no latency to the agent.

Why the external anchor is not optional

This is the layer most often skipped, and the reasoning is worth stating plainly, because a signature alone is frequently mistaken for a completeness guarantee. A signature proves the integrity and authenticity of a record you are already holding. It says nothing about a record that was deleted, a sequence that was truncated, or a history that was re-signed wholesale. Whoever controls the signing key can produce a perfectly valid alternate history, and every individual receipt in it will verify. The hash chain and the Merkle checkpoints close most of that gap, because deletion, reordering and truncation become detectable within the chain. They close it only for a verifier holding an independently anchored copy of an earlier checkpoint to compare against. A party that both signs the chain and stores it can rewrite the records and re-anchor them consistently, and self-published checkpoints alone cannot distinguish that from an honest history. The WORM anchor is what would remove the operator from the trust base, and it is the one leg not yet running. Because a published tree head cannot be altered or deleted before its retention expires, it is the independently anchored copy the rest of the chain depends on. That is the specific job the external leg does, and it is not a job that signing or chaining can do on their own. So we state the consequence rather than let the reader infer the stronger claim: with that leg off by default, the guarantee we make today is tamper-EVIDENCE against outside parties and against accident, not tamper-PROOFNESS against ourselves. A verifier who wants the stronger property should require the WORM leg enabled, or anchor a checkpoint they hold themselves. The RFC 3161 timestamp, which does run on every batch, does the equivalent job for time, replacing our assertion about when a batch was sealed with an assertion from a third party.

Independent verification, defined

"Verifiable" only means something if the verification workflow is specified. There are two paths, and the second requires nothing from the vendor: One call. A single API request re-derives and re-checks the entire attestation chain for any record, payload integrity, leaf signature, Merkle inclusion, root signature, timestamp, and reports each check's result explicitly. Checks fail closed: a check that cannot complete reports failure with a reason, never a silent pass. Fully offline. A receipt verifies with standard cryptographic libraries and the receipt fields alone, recompute the canonical payload hash, verify the Ed25519 signature against the carried public key, and check Merkle inclusion against the published checkpoint feed. Your auditor does not need the vendor's cooperation to check the vendor's records. Independence is the point.

What this proves, and what it deliberately does not

Strong evidence systems earn trust by stating their limits, and one word deserves care here because this market uses it loosely. Object Lock in compliance mode is a genuine storage-level immutability guarantee for the objects it covers, for the length of its retention — and on the hosted service that leg is off by default, so nothing is covered by it today. What protects the receipts, which live in an operational database, was never storage immutability anyway but the chain: any divergence between the records and the anchored checkpoints is detectable. Those are two different statements, only one of them is running by default, and this paper makes them separately rather than collapsing both into one word — which is exactly the loose usage it just warned about, and the reason an earlier version of this page overstated the guarantee. A signed event also does not automatically establish every property a reviewer cares about. It pays to separate five:

The chain also does not prove that the attributes inside an event were truthful when captured, signing seals a record; it does not fact-check it. And it does not, by itself, establish legal non-repudiation: that is a legal conclusion involving key custody, process, and jurisdiction, for which this evidence is an input. Nor does cryptographic evidence replace the surrounding program, control-plane access security, key custody, and independent monitoring all still matter.

Why approvals belong in the evidence story

Human approval is not only an operational control. It is an evidence event. The most sensitive agent actions are often exactly the ones routed to humans:

• payment changes
• privileged communications
• production operations
• customer-impacting writes

If approval decisions are detached from the underlying runtime event, the governance story weakens. Here, every human response emits a signed record envelope of its own, so the approval, the governed action, and the outcome belong to the same verifiable trail. The approval that released a wire transfer is itself evidence.

Practical enterprise scenarios

Scenario 1: Compliance review

A reviewer asks whether a sensitive agent action was blocked by policy or simply never attempted. A concrete decision record exists; the matched control and outcome are visible; the review is anchored in verifiable evidence, not operator memory, and mapped to the frameworks the organization answers to (SOC 2, NIST AI RMF, the EU AI Act, ISO 42001, DORA).

Scenario 2: Incident investigation

A security team reviews a suspicious interaction: sensitive retrieval followed by a downstream action attempt. Retrieval and action decisions reconstruct together; approval and denial states are explicit; "did the agent do this?" stops being a forensic project and becomes a query with a verifiable answer.

Scenario 3: Executive and customer assurance

A buyer wants to know whether governance is real or decorative. Independently verifiable records, checkable offline, anchored to third-party time, with an operator-tamper-evident external copy, are a categorically stronger answer than "we keep logs."

Conclusion

AI governance without proof runs into a limit that no amount of dashboard polish will move. Verifiable decision provenance moves that limit by turning runtime decisions, including the human approvals on the most sensitive paths, into independently checkable evidence. It also disciplines everything upstream of it: when every decision will be signed, anchored and kept, the controls that make those decisions get designed to be read by someone else later. Learn more at visiqlabs.com · Technical documentation at docs.visiqlabs.com