What an audit trail for AI agents actually needs

Why agent audit trails are different from app logs

Three things change when the actor is an autonomous agent rather than a person clicking a button:

• The action is the risk, not the request. A human who clicks "pay" is accountable. An agent that decides to pay isn't — so the record has to capture the decision (allowed? denied? held for whom?) and the authority behind it (which policy, which mandate, which budget), not just the HTTP call.
• Volume and autonomy. Agents act fast and unattended. You can't reconstruct intent from a trace after a bad week; you need the decision recorded at the moment it was made.
• The record itself is under suspicion. For an audit or an incident, "trust our logs" is circular — the operator could have changed them. The trail has to be tamper-evident: a naive alteration must be detectable on its own, and a determined operator's rewrite must be detectable by comparing against a checkpoint the operator doesn't control (more on that below).

What a real agent audit trail must capture

For every governed action, at minimum:

• The decision and its authority — allow / require-approval / deny, and why: the mandate, the policies that matched, the budget state, the risk signal.
• The human in the loop, when there was one — who approved or denied and when, bound to an authenticated user on the dashboard path (an out-of-band bearer link proves the decision and time, not the individual identity).
• The outcome — what came back after the decision, as reported or observed (executed, settled amount, failed, expired).
• Tamper-evidence — a structure where edits are detectable, not just discouraged: a naive edit breaks the record itself, and a rewrite of committed history is exposed by checkpoints outside the operator's control.
• Independent verifiability — a way to check integrity without trusting (or even contacting) the vendor.

Tamper-evident ≠ tamper-proof (the part people get wrong)

Nothing digital is truly immutable — an operator with database access can change a row. The honest goal is tamper-evident: make a change detectable. The standard technique is a hash chain — each entry's hash is derived from its content plus the previous entry's hash, so editing any entry breaks every hash after it.

Here's the part vendors skip: an operator who edits an entry can also recompute every following hash, since hashing needs no secret. A re-chained ledger is internally self-consistent — so re-deriving it offline catches a naive edit but not a determined rewrite. That's why the guarantee against the operator is external: anchor a chain head to somewhere they don't control (a WORM store, a SIEM, an auditor's system), and a rewrite of the anchored history no longer matches the checkpoint.

So be precise about what the chain proves:

• ✅ Re-deriving the exported chain (no key) detects any un-recomputed edit and any break in continuity within that chain.
• ✅ With an external anchor, a rewrite of history committed before that checkpoint becomes detectable — even against the operator.
• ❌ On its own it does not prove an action actually executed downstream, that every action was recorded (an agent that never reported leaves no entry), or that there's no separate, forked history past the last anchor.

You narrow those last gaps two ways: route actions through an enforcing layer so the record is the execution path for the credential it controls, and anchor chain heads externally. Integrity is cryptographic; completeness is an architecture choice. A trail that claims "immutable" without saying any of this is overselling.

How to evaluate one

Ask a vendor:

• Can I verify integrity offline, with no access to you and no secret key? (Hash-chain re-derivation should need neither.)
• Is the export's signature a shared secret (HMAC) or an asymmetric signature? An HMAC is a vendor attestation — anyone with the key can forge it — so the keyless check comes from re-deriving the chain, protection against a re-chained rewrite comes from external anchors, and neither comes from the signature.
• Can I anchor chain heads to a store I control?
• What does the trail record — decisions and outcomes, or just requests?
• What does it not prove? (If the answer is "nothing, it's immutable," walk.)

Where Provenant fits

Provenant is a control plane and tamper-evident audit ledger for AI agents. It authorizes each action an agent routes through it, and writes each decision and the reported/observed outcome to a per-org, append-only, hash-chained ledger. You re-derive the chain offline with an open-source SDK — no key, no access to us — and anchor chain heads to your own WORM store or SIEM. The signature on an export is a vendor HMAC (an attestation that needs our key); the independent, keyless guarantee is the chain re-derivation plus your anchors.

It's honest about the boundary above: the ledger proves integrity and continuity; enforcing mode extends coverage to the credential/path it controls, and the ledger itself doesn't prove every action was captured. Free tier needs no license, and it's self-hostable.

Try it at app.provenant.identiqube.com, re-derive a signed export's chain in your browser on the Verify page, or read the documentation.