Cryptographic audit trails for AI agents: the definitive guide

A cryptographic audit trail for AI agents is a record of what an agent did that can be verified by mathematics rather than trusted by policy. Each action is captured as a signed receipt, the receipts are linked into an append-only hash chain, and anyone holding the chain can check offline that it is authentic and that nothing before or after it was altered. If a single byte changes, the check fails. That is the whole point: the record proves itself, so you do not have to take the operator's word for it.

Most things sold as "audit logs" cannot do this. This guide explains the difference, the four properties that turn a record into evidence, and the open protocols underneath. There is a short walkthrough so you can verify a chain yourself, and a broken-chain test you can run to see tampering caught in the act.

Why a normal log is not evidence

A standard application log is a mutable file. Whoever holds write access can append, edit, or delete a line, and there is no way for a reader to tell after the fact. A cloud logging dashboard is the same problem with extra steps: the provider, an admin, or a compromised process can rewrite history, and the log's own timestamps offer no defence because they were written by the same trusted party.

For AI agents this gap matters more than for ordinary software. An agent takes actions on your behalf: it calls tools, moves data, spends budget, and touches other systems. When something goes wrong, "the log says the agent did X" only helps if the log could not have been quietly changed to say something else. A record you have to trust is not evidence. It is a claim.

The fix is not a better dashboard. It is changing the record so that tampering is detectable by anyone, without access to your infrastructure.

What separates evidence from a log

A record crosses from log to evidence when it has all four of these. Miss any one and it is weaker than it looks.

• Hash-chained. Each entry includes the cryptographic hash of the entry before it. The entries form a chain, so removing or editing any one of them breaks every hash that follows. You cannot rewrite the middle of history without rewriting everything after it, and the break is visible.
• Signed. Each entry carries a digital signature from the party that produced it. The signature binds the content to a key, so a reader can confirm the content has not changed since signing, and, if they hold the signer's public key, who asserted the action.
• Witnessed. An independent party observes the chain and issues its own receipt that a given state existed at a given time. A witness receipt can be content-free: it attests to the hash without holding the underlying data, so the witness proves timing and integrity without becoming a copy of your secrets.
• Offline-verifiable. Verification needs only the receipts and the relevant public key, not a call back to the system that made them. Anyone can check the chain on a laptop, years later, with the vendor absent.

The failure modes map straight onto the missing property. Signed but not chained: individual entries are authentic, but entries can still be dropped. Chained but not witnessed: the operator can regenerate the whole chain to tell a new story. Verifiable only against a live service: the service can lie or disappear.

The open protocols underneath

Quox implements these properties as four open protocols rather than one closed product, so the evidence outlives any single tool.

• AEE is the envelope. Every agent action, whether a tool call, a policy decision, or an approval, is captured as a structured event envelope with a stable shape.
• AOCL is the control layer. It defines where governance happens in the action's life: an L3 policy gate decides whether an action is allowed before it runs, and an L8 verify step confirms the evidence after. The protocol is documented at /docs/aocl.
• VOLT is the ledger. It is an append-only, SHA-256 hash-chained record with Ed25519 signatures, and entries can carry RFC 3161 trusted timestamps where a timestamping authority is available. This is where the chaining and signing properties live.
• WARD is the witness. It issues content-free receipts that attest to the ledger state without holding the content itself, which is how you get third-party attestation without leaking data. The protocol is documented at /docs/ward.

Together they turn "the agent did X" into a receipt you can hand to an auditor, a customer, or a court, and that they can check without trusting you. For how these fit into a self-hosted control plane, see verifiable AI operations, and the architecture write-up in QuoxCORE trust infrastructure.

Verify a chain yourself with quoxproof

The properties above are only real if you can check them without us. quoxproof is a Python package on PyPI that verifies tool-call receipt chains offline. You do not need a Quox instance to run it.

A passing check confirms, for every receipt in the chain, that each signature is valid, that each entry's hash links correctly to the one before it, and that nothing has been altered since signing. No network call is made, so a green result is a property of the file in your hand, not of a server that could be down or dishonest.

There is an honest ladder inside that green result, and it is worth understanding before you rely on it:

• Self-consistent. With the signing key embedded in the receipts, a pass proves the chain is internally intact and unaltered. It does not prove who the signer was, only that one consistent key signed throughout.
• Identity-pinned. Supply the signer's public key with --pubkey and the pass now proves the receipts came from that specific signer, not merely from a self-consistent chain.
• Witnessed. A third party attesting that the chain existed at a given time is a further rung, and that is exactly what a WARD witness receipt adds on top.

Reach for the rung the situation needs. Internal debugging can live at self-consistent. Anything you hand to an outside party wants identity-pinned at least, and witnessed if timing is contested.

The broken-chain test

The fastest way to understand why this beats a log file is to break it. Take a verified chain, change one character in a recorded action, and run quoxproof verify again. It fails, and it names which link broke. Now do the same to a line in a normal log: nothing complains, because nothing was ever anchored.

That failure is the feature. A cryptographic audit trail does not stop tampering, it makes tampering undeniable. An altered record announces itself, so silence becomes meaningful: if every receipt in a chain verifies, you know the history is intact, end to end.

Where this fits

If you are choosing controls for an agent deployment, treat the four properties as a checklist and ask any vendor to demonstrate each, not describe it. Incumbents tend to describe an audit trail. The real test is whether you can take the receipts off their platform and verify them on your own machine with the vendor absent, and how far up the trust ladder that check reaches.

Quox is pre-launch, and the approach here is deliberately open: AEE, AOCL, VOLT and WARD are protocols anyone can read, and quoxproof is on PyPI today. For the security posture around all of this, see /security. For a worked example of proving a specific agent action, read how to prove what your AI agent did. This page is the pillar the rest of that evidence work links back into.