Skip to main content
Every tool-call authorization and every human adjudication emits a record envelope; retrieval verdicts emit envelopes when artifact signing is enabled for your organization. There is no additional code; the audit trail activates automatically from the same visiq() call. Envelopes are persisted server-side, off the request path, and then cryptographically attested: each one receives an asynchronous Ed25519 receipt, is committed to a Merkle batch whose root is signed and countersigned by an independent RFC 3161 timestamp authority, and takes its place in a hash-chained transparency log. Decision Receipts covers the cryptography in depth.

​
What gets recorded

Each decision produces one envelope. An action-governance denial looks like this:
source tells you which subsystem produced the decision, and each source carries its own decision vocabulary: The event field holds what happened — the payload the cryptographic receipt later signs — and attestation holds the decision metadata, both shaped per source:
  • action — event: { target_app, action, context }, attestation: { reason, rule_id, mode }. mode records the agent’s mode at decision time — enforce, monitor, or off (an off-mode call is permitted without evaluation but still recorded).
  • retrieval — event: { operation, resource_type, resource_metadata }, attestation: { reason_code, reason, rule_id }.
  • hitl — event: { hitl_item_id, category, target_app, action, context, allow_decision_id }, attestation: { responded_by, responded_at, ai_recommended_rule }.
Human adjudications are first-class evidence. When a responder approves or rejects a held action, a separate hitl envelope records who responded and when, linked back to the originating decision via decision_id — and it receives its own cryptographic receipt like any other decision.
At the moment an envelope is ingested, the database also pins a content hash over its event in a generated column the application cannot write. Verification later recomputes it, proving the record was not edited even in the window between ingest and signing.

​
How records become tamper-evident

Persisting the envelope is step one. An asynchronous pipeline — entirely off the decision hot path, adding zero latency to your agents — turns each envelope into independently verifiable evidence:
  1. Ed25519 leaf receipt — the envelope’s event is canonicalized, hashed, and signed. The receipt (signature, public key, payload hash) is stored separately from the envelope it attests.
  2. Merkle batching — a background worker gathers unbatched receipts and commits their leaf hashes to a single Merkle root.
  3. Root signature — the root is signed once. VisIQ supports holding that key in an HSM (AWS KMS), where the private key never leaves the HSM; that mode is opt-in per deployment and is not enabled on the hosted service today, which signs with an in-process key.
  4. RFC 3161 timestamp — DigiCert’s timestamp authority countersigns the root: an independent third party attests when the batch existed.
  5. Hash-chained checkpoints — each signed batch commits to the previous batch’s root, forming an append-only transparency log. Deleting, reordering, or backdating any batch breaks the chain detectably for anyone holding an earlier checkpoint. VisIQ additionally supports publishing checkpoints to write-once (WORM) object storage as an external witness — that is the leg that would make a rewrite detectable even against VisIQ itself, and it is off by default and not enabled on the hosted service today, so that stronger property is not one we currently claim.
This is the Certificate Transparency model: one HSM signature and one third-party timestamp attest an entire batch, so 100% of records are signed and independently timestamped at any decision volume.

​
Verify a record in one call

You don’t hand-roll any cryptography. One request re-derives and re-checks the full attestation chain:
It runs six independent checks and returns per-check evidence: verified is true only when every applicable check passes. A freshly emitted record reports attestationStatus: "timestamp_pending" until the next batch sweep commits it — typically within a minute or two. The dashboard runs this same verification for you: every governed event row (Harness → Runtime Enforcement) carries a record pill, and clicking through opens the record’s verification page with the full per-check breakdown.

​
What the audit trail proves

​
Consuming the trail

  • Dashboard — Harness → Runtime Enforcement streams every governed event with its record attached; agent pages and the Escalations queue link to the same records.
  • Query APIs — GET /v1/allow/audit-log and GET /v1/recall/audit-log return the paginated decision logs, filterable by agent, decision, and date range.
  • Log streaming — stream decision envelopes and audit events to your SIEM. Datadog and Elasticsearch destinations are configured under Settings → Log Streaming (organization scope) or from the Integration → Connectors Log Streaming cards. Delivery is cursor-tracked: a failed batch is retried, never dropped.
  • Evidence packs — export a signed, per-agent evidence bundle over a date range from the agent’s dashboard page, sized for handing to an auditor.
Cryptographic receipt issuance is plan-dependent. On every plan, all decisions are still recorded in the queryable audit logs above.

​
Next steps

Decision Receipts

The exact cryptography — canonicalization, signatures, Merkle proofs, timestamps — and how to verify offline.

Action Governance

How tool-call authorization decisions are made.

Retrieval Governance

How retrieval verdicts govern what context your agents see.

Platform Automation

Authenticating scripts and CI against the management API.