The audit trail is the product
Why a hash-chained ledger turns 'we ran a workflow' into 'we paid for a verified outcome with proof' — and why that's the actual value of governance software.
Paste a manifest into the public demo or bring a scoped workflow to the private beta.
Logs vs ledgers
Most AI products treat the audit log as an afterthought. A log line per LLM call gets written to Datadog or LangSmith. If something goes wrong, an engineer searches the logs.
That's a log, not a ledger. Logs answer engineering questions ('why was the latency high last Tuesday?'). Ledgers answer compliance questions ('prove the agent didn't spend on a blocked vendor in March'). The two have different requirements.
A ledger needs three properties logs don't. First, every entry references the previous entry — tampering is detectable. Second, the ordering is deterministic — the entries can't be silently reshuffled. Third, the schema is fixed — you can write tools that reason about the ledger without parsing free-form messages.
Why the chain matters
Mission Control's audit ledger SHA-256-hashes every event, with each hash derived from the previous hash plus the event's canonical JSON payload. The chain anchors to a 32-byte zero genesis. verifyChain() re-derives every hash and returns the index of the first broken link, or { ok: true } if intact.
An attacker who edits a payload — to remove evidence of an unauthorized spend, to backdate an approval, to change which vendor was paid — breaks every downstream hash. We detect that immediately. An attacker who tries to rewrite the entire chain has to re-derive every hash; the chain's genesis anchor and the rowid-based read order make insertion attacks visible.
Why the schema matters
Mission Control's events have fixed types: MissionCreated, MissionPlanned, RouteQuoted, PolicyEvaluated, ApprovalRequested, ApprovalGranted, PaymentIntentCreated, PaymentRequirementReceived, PaymentSigned, PaymentSettled, VendorResponseReceived, VerificationCompleted, MissionCompleted, MissionFailed, DisputeOpened, RefundRequested, ProviderScoreUpdated.
That schema is what lets a CSV export drop into a SOC 2 evidence pack without translation. It lets a regulator ask 'show me every PolicyEvaluated event in March' and get a query, not a research project. It lets a buyer prove to a third party that their dispute was filed within the SLA window.
Audit trail as a sales feature
The audit trail is what flips Mission Control from 'a way to run agents' to 'a way to run agents on behalf of a regulated company'. Most enterprise buyers don't care about the architecture; they care that they can hand the audit_url to their auditor without a slide deck explaining what it means.
That's the product. Everything else — Policy Engine, Smart Router, Verifier, Disputes — exists to produce events that the audit trail seals. The trail is the artifact; the rest is plumbing.
Related reading
- What Is AI Agent Security Preflight?— AI agent security preflight checks tools, permissions, payments, signer boundaries, and receipts before an agent touches production systems.
- Signed Security Receipts for AI Agents— A signed security receipt turns an agent safety check into portable evidence: subject hash, policy hash, decision, findings, evidence hash, issuer, and verifier identity.
- Designing route explanations that survive a SOC 2 audit— The router's score is one number; the explanation is what a reviewer reads. We walk through how Mission Control composes 'Acme chosen — certified provider, verification pass rate 94%, fast (p95 1200ms)' and why it matters more than the score itself.