Verifiable Decision Provenance

Executive summary

Enterprises do not just 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?

This is where many AI governance stories collapse into ordinary logging. Logging is useful. It is not enough. 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 an HSM-backed 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 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. Chain checkpoints are additionally 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. A silent rewrite of history is detectable even by the operator. The audit trail does not ask you to trust the party that runs it.

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

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. The correct claim throughout is tamper-evident, not "immutable" — and a signed event does not automatically establish every property a reviewer cares about. It pays to separate five:

Property What the chain provides

Integrity Alteration of a recorded decision is detectable — the hash and signature no longer verify Authenticity The record was produced under the signing key; verification is against the carried, published key

• material

Ordering The checkpoint chain makes reordering and deletion detectable; timestamps bind records to third-party-

• asserted time

Completeness Provided for the recorded set: backfilling and removal are detectable. Not provided for events that never

• entered the system — a receipt attests to decisions made, not to actions taken outside the instrumented
• path

Retention WORM-published checkpoints survive operator-side deletion for the retention period; retention policy

• itself remains an organizational control

Equally plainly, the chain 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 eventually hits a trust ceiling. Verifiable decision provenance raises that ceiling by turning runtime decisions — including the human approvals on the most sensitive paths — into independently checkable evidence. And it disciplines everything upstream of it: when every decision will be signed and kept, the controls that make those decisions get designed like they will be read aloud someday. They might be. Learn more at visiqlabs.com · Technical documentation at docs.visiqlabs.com