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, with an HSM-backed KMS key where a deployment enables that mode (the hosted service does), so the batch-root private key stays inside the HSM. The per-receipt leaf signatures beneath it are produced in-process, from a key stored only in KMS-wrapped form and unwrapped at point of use.
  4. RFC 3161 timestamp: DigiCert’s timestamp authority countersigns the root, so 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. This is what we mean by tamper-evidence: altering the record is not prevented, but it cannot go unnoticed. Retain a checkpoint yourself if you want an independent witness: any checkpoint you hold is enough to detect a later rewrite, and it is held by you rather than by us.
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 (Control AI → Agent Events) 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: Control AI → Agent Events 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.