AI agent audit trails:
what they are, and how to verify one.

An AI agent audit trail is a record of every action an agent took: which tool it called, with what inputs and outputs, on whose behalf, when, and whether the action was allowed or blocked. A chat transcript tells you what was said. An audit trail is built to answer a harder question: who told the agent to do that, and can you prove the record itself was not edited afterward.

That second clause is the whole topic. Most teams discover it the first time someone asks them to demonstrate, not assert, that an agent did only what they claim. We build Pinchy, a self-hosted AI agent platform whose audit trail is one of its core features, so we have a stake here. The design discussion below stands on its own either way, and the parts where the answer is genuinely contested are marked as such.

Why an agent audit trail is not just application logging

Every backend already writes logs. The instinct is to point an agent at the same pipeline and call it done. Three things make that insufficient.

The log is the evidence, and ordinary logs are editable. As one analysis of the EU AI Act's logging mandate put it, application logs "live on infrastructure someone controls. They can be edited or replaced without anyone noticing," and "if your logs can be silently altered and you can't show otherwise, their evidentiary value is zero" (Help Net Security). A log you can quietly rewrite proves nothing about an autonomous system that took actions on your behalf.

Agents are non-deterministic. The same prompt can produce a different sequence of tool calls on two different runs. Observability stacks built for deterministic services assume a request maps to a predictable path. An agent does not, which is exactly why the per-run record of what it actually chose to do matters more, not less.

The interesting events are tool calls, not page views. An agent reads a customer record, drafts an email, updates an invoice, hands off to a sub-agent. The audit-worthy moments are these actions and the decisions around them: which tool, which user asked, what was returned, what was refused. A request-and-response log of the chat endpoint captures almost none of it.

What an agent audit trail has to capture

Working back from "could you reconstruct and defend this later," an agent audit entry needs at least:

• The actor. The specific user who triggered the action, not just "the agent." If everyone shares one identity, the trail cannot answer who asked.
• The action. The tool that ran, its inputs and outputs, and the result. A "read Odoo invoices" call and a "send email" call are different events with different stakes.
• The decision. Whether the action was allowed or blocked, and against which rule. A record of what an agent attempted and was refused is often more useful than the successes.
• The outcome and errors. Success, failure, retries. Silent failures are where incidents hide.
• Time and identity of record. When it happened, and enough to tie the entry to a specific run and step.

This maps onto what regulators are starting to demand. EU AI Act Article 12 frames logging around recording the events needed to identify risk situations, support post-market monitoring, and monitor operation, and it expects traceability across inputs, outputs, and the people involved. A common gap, even in mature setups, is that the log captures the action but not the decision context: the system prompt, accumulated history, and tool results that shaped the agent's choice. Without that context you can show what the agent did but not why, which is often the question being asked.

The hard part: making the log tamper-evident

Capturing the right fields is the easy half. The half that separates an audit trail from a diary is whether anyone, including an administrator, can change an entry after the fact without it showing. Access controls help, but access controls protect the living system; they say nothing about whether last quarter's log was rewritten last night. For that you need the record to carry its own proof.

There is a small design space here, and the choice has real consequences.

A hash chain is the approach most teams reach for first, and you can watch it happen in the open: agent projects file issues asking for a "SHA-256 hash-chained action log for tamper-proof agent accountability" (a real example lives in the hermes-agent issue tracker). Each entry includes a hash of its own data combined with the previous entry's hash, so altering one entry changes its hash and breaks verification for every entry after it. It is elegant, and for an append-only system that never has to remove anything, it is a fine answer.

Why hash chains and the right to be forgotten collide

The trouble is that real systems do have to remove things. GDPR's right to erasure can require you to delete a specific person's data on request. If your audit trail is a hash chain, deleting one entry breaks the hash of every entry recorded after it, and your tamper-evidence collapses into "this log has been altered" for the entire remainder of the chain. You are forced to choose between honouring a lawful deletion and keeping a verifiable log. That is not a trade-off most compliance teams will accept, and it is rarely surfaced in the tutorials that recommend chaining.

A per-row signature avoids the collision. Each entry is signed independently, typically with an HMAC (a hash keyed by a secret) or a digital signature. Tampering with any single entry breaks that entry's signature and only that one, so verification still points at the exact altered row. Because the entries are not linked, you can delete or redact a single entry to satisfy an erasure request, and every other entry still verifies on its own. You give up the "this entry came after that one" ordering guarantee that a chain provides, but you keep the property that actually matters for compliance: each record can be proven unaltered, and lawful deletion does not destroy the rest of the log.

This is the reasoning behind Pinchy's choice of per-row HMAC signatures rather than a chain. It was a deliberate decision to keep tamper-evidence and the right to be forgotten from fighting each other.

How to verify a tamper-evident audit trail

Verification is mechanical once the design is right. For a per-row signed log:

1. Serialise the entry canonically. Take the entry's fields and serialise them in a fixed, reproducible form, for example with the keys sorted. This step is easy to get wrong and easy to skip: many databases, including PostgreSQL's JSONB, do not preserve key order, so signing the stored representation directly produces signatures that fail for reasons that have nothing to do with tampering.
2. Recompute the signature. Run the same keyed hash over the canonical bytes that the system ran when it wrote the entry.
3. Compare. If the recomputed signature matches the stored one, the entry is intact. If it does not, that specific entry was changed.
4. Verify outside the system. The check is only convincing if it can run somewhere other than the system that produced the log. That means the signatures have to be exportable. A CSV export that carries each row's signature lets an auditor, or you, run the verification independently against the row data alone.

The test of a real audit trail is that last point. If the only thing that can tell you the log is intact is the same application that could have edited it, you have a claim, not evidence.

What the regulations actually require

The driver behind most of this work in 2026 is regulatory. EU AI Act Article 12 requires high-risk AI systems to "technically allow for the automatic recording of events (logs) over the lifetime of the system." Two words carry weight: automatic means the system generates the logs itself, not a person writing notes, and lifetime means from deployment to decommissioning. Related provisions set a minimum retention of six months, and the article expects logs detailed enough to identify risk situations and to support both post-market monitoring and operational oversight. Its high-risk obligations are phasing in on a timeline that has already shifted once: the 2026 Omnibus package moved the use-based high-risk deadline to 2 December 2027.

Worth knowing: there is not yet a finalised technical standard for how to satisfy this. Two are in draft (prEN 18229-1 and ISO/IEC DIS 24970), which means the specifics are still moving. The safe reading is to build for the property the law is reaching for, an automatic and trustworthy record, rather than to a checkbox. The same per-entry integrity and external verifiability also map cleanly onto SOC 2 and onto GDPR's expectation of accountability, so the work is not single-use.

A checklist for evaluating an agent audit trail

Whether you are building one or assessing a vendor's, these are the questions that separate evidence from decoration:

• Is each entry independently verifiable, or does "tamper-proof" just mean "we restrict who can edit it"?
• Is it a hash chain or per-row signatures, and if a chain, what happens to verification when you must delete one entry?
• Does it capture the acting user, or does one shared identity make "who asked" unanswerable?
• Does it record what was blocked, not only what succeeded?
• Can you export the signatures and verify the log outside the system that wrote it?
• Does it cover tool calls and decisions, not just chat request and response lines?
• Is the data serialised canonically before signing, so verification does not fail on key-order noise?

How Pinchy does it

This is the part where we describe our own product, so read it as such. Pinchy records every agent action in an audit trail where each entry is individually signed with an HMAC-SHA256 over its canonically serialised fields. Tampering with an entry breaks that entry's signature and points at the exact row. The design is deliberately per-row rather than a chain, so a lawful deletion removes one entry without invalidating the rest, and the entries can be exported to CSV with their signatures so the integrity check can run independently of Pinchy. Pinchy can recompute the signatures and report any rows that no longer match.

The audit trail sits behind the rest of the model: an allow-list of tools per agent so the log records actions the agent was actually permitted to take, and a self-hosted deployment so the records, and the data they describe, never leave your infrastructure. If you build your own layer instead, the design above is what we would build toward, and if you try Pinchy and something here does not hold up, that is an issue report we want.