Investigation & forensics

A suspicious interaction usually looks like a sequence: a sensitive retrieval, then a downstream action attempt. Because both surfaces are governed by one engine, their decisions reconstruct together. In order, the record shows what the agent read, what it attempted, what was denied, and who approved what.

Did the agent do this stops being a forensic project and becomes a query with a verifiable answer.

Each decision's canonical payload is signed with Ed25519; the receipt carries the signature, the signing public key, and the payload's SHA-256 hash. Receipts are batched into an RFC 6962-style Merkle tree, and each carries its inclusion proof.

Batch roots are countersigned by an independent RFC 3161 timestamp authority, so when a record was sealed is asserted by a third party rather than by the operator's clocks. Batches also chain to their predecessors: a deleted batch leaves a gap, and a reordered one breaks recomputation.

One API call re-derives the whole attestation chain for any record, and each check reports its result explicitly; a check that cannot verify fails closed. A receipt also verifies fully offline with standard cryptographic libraries, so your auditor does not need the vendor's cooperation to check the vendor's records.

Signing runs asynchronously, off the decision hot path, so evidence adds no latency to the agent.

A receipt attests to decisions made on the instrumented path. It says nothing about actions taken outside it, and signing seals a record without fact-checking the attributes inside.

The default guarantee is tamper-evidence: alteration, deletion, and reordering are detectable. A deployment that also needs protection against the operator can enable the write-once external checkpoint leg, which is implemented and off by default.