What an AI agent audit trail has to contain
A log tells a reviewer what your system says happened. An audit trail for autonomous actions has to answer a harder question: who authorized this exact action, under which policy, and can that be checked without asking you.
The question a reviewer is actually asking
Every review of an agent action converges on the same four questions. What exactly executed. Who authorized it. Under what rule, as the rule stood at the time. And what the record says when none of that can be established. A trail built for debugging answers the first question well and the other three badly.
The gap is not thoroughness. You can capture every field of every request and still not hold evidence, because the capture is a statement by the system whose behavior is in question.
What the record must carry
| Field | The review question it closes |
|---|---|
| The exact action, parameter by parameter | Was the thing that ran the thing that was approved? A record of the action type alone cannot answer that; the amount, the beneficiary, and the target are where substitution happens. |
| The named approver, signing over that action | Who said yes? A session identifier names a login. It does not name a person who accepted a consequence. |
| The assurance tier actually proven | How was the yes established? EMILIA ranks software below class_a (device signoff) below quorum (m-of-n). A receipt that merely claims the higher tier is graded down to software and refused. |
| The policy pinned at request time | Under which rule? Pinning is what stops a later policy edit from retroactively legitimizing an action taken before it. |
| A one-time consumption key | Was this approval used more than once? Reuse has to surface as an explicit refusal, not as a second successful action that looks identical to the first. |
| The outcome, including "not established" | Did it actually take effect? A record that can only say success or failure will assert one of them when neither was observed. |
Application logs are self-attested
Your application log is written by the system under review, into storage that system controls, and read back through an interface that system provides. Every step of the verification path runs through the party being questioned. Checking the record needs your database, your access grant, and your continued cooperation. When the system itself is what is in doubt, its record inherits the doubt.
That is not an argument against logging. Logs are the right instrument for operating a system and the wrong one for settling a dispute about an irreversible action, and the two jobs are usually assigned to the same file.
The full argument, side by side: audit logs vs authorization receipts
What a signed per-action record adds
An EMILIA authorization receipt is an Ed25519 signature over the canonical JSON of a claim, optionally anchored in a sorted-pair Merkle tree. Verifying one needs the receipt, the canonicalization rule, and the issuer public key the checker pinned. It does not need our servers, your database, or anyone’s permission.
- It can be handed over. An auditor, an insurer, or a counterparty checks it themselves, with the Apache-2.0 reference verifiers for JavaScript and Python.
- It cannot be quietly amended. Any edit to a signed field breaks the signature, so a record that still verifies is the record that was issued.
- It outlives the issuer. The evidence does not depend on the issuing system still running, still being reachable, or still being on your side.
The receipt format is public and implementable in any language: see EP-RECEIPT-v1.
When the provider goes silent, the honest answer is INDETERMINATE
The hardest case in the design is not the attacker. It is the executor that stops answering. An action is authorized, the gate reserves it, the executor is invoked, and then the call throws: a timeout, a dropped connection, a 500 after the write. From where the caller stands, “it fully executed” and “it never happened” are indistinguishable.
A retry-shaped system resolves that by guessing. Treat it as failure and retry, and the effect may land twice. Treat it as success and the record now asserts an effect nobody observed. Either way the trail states something no one checked, and it states it with the same confidence as everything else in the file.
EMILIA records the third answer. Once the executor has been entered, a thrown error is an indeterminate effect, not proof that nothing happened. The authorization is burned rather than reopened, a blind retry on the same operation is refused before the provider can be re-entered, and the reserved budget is not silently restored. The entry stays indeterminate until authenticated provider evidence resolves it: signed by a pinned provider key, bound to the same operation identifier and the same canonical action digest. Evidence for a different destination, or with a broken signature, does not reconcile and never enters the ledger.
$ node examples/indeterminate-effect-reconciliation/demo.mjs 1 PROVIDER COMMITTED effects=1 2 RESPONSE LOST effect_indeterminate 3 CAPABILITY FINALIZED indeterminate 4 BLIND RETRY operation_already_committed 5 AUTHENTICATED GET executed 6 PROVIDER EXECUTIONS 1
That is what surviving review means in practice. The record is allowed to say it does not know, and it is not allowed to guess.
Where the mechanism is checked
The properties above are behaviors of code, so they are tested as behaviors: 21 conformance suites covering 331 vectors, and 8,745 automated test cases, with the refusal paths tested as explicitly as the happy path. The full evidence index, including what each artifact does not establish, is on the engineering evidence page.
Questions
What is an AI agent audit trail?
A per-action record of what an autonomous agent did and what authorized it. To be useful in a review it has to carry the exact action parameters, the named human who approved that action, the assurance tier actually proven, the policy pinned at request time, a one-time consumption key, and the outcome, including the case where the outcome is unknown.
Are application logs enough for an AI agent audit trail?
Logs answer what your system says happened. They are written by the system whose conduct is under review, stored where that system controls, and read back through an interface it provides. That is sound engineering telemetry and a weak evidentiary position, because every step of the verification path runs through the party being questioned.
What does offline-verifiable mean here?
An EMILIA authorization receipt is an Ed25519 signature over the canonical JSON of a claim, optionally anchored in a sorted-pair Merkle tree. Checking it needs the receipt, the canonicalization rule, and the issuer public key the checker pinned. It does not need the issuing system to be reachable, cooperative, or still in business.
What happens when the provider never responds?
The record says indeterminate. Once the executor has been entered, a thrown error is an indeterminate effect, not proof that nothing happened. The authorization is burned rather than reopened, a blind retry on the same operation is refused, and the entry stays unresolved until authenticated provider evidence bound to the same operation and the same canonical action digest resolves it.
Next
The record described here is what an approval leaves behind. For the workflow that produces it, see AI agent approval workflows.