Are application logs enough for an audit trail?

No. They differ on four properties: retention is set by storage cost rather than by the obligation, the writing process can usually alter or delete them, completeness is not guaranteed because log levels get changed in production without formal process, and they correlate to a request rather than to the document, decision and actor. A record that fails any one of those is a debugging artefact, not evidence.

Should the audit entry be written before or after the action?

Before. A trail written only on success contains no record of attempts that never returned, and attempts that never returned are exactly what gets asked about after an incident. Write an intent entry before the call, then a linked outcome entry when the result arrives or the attempt times out.

What does an AI agent audit trail need that an ordinary process log does not?

Two fields: the input data the decision actually rested on, and the model and configuration version in force at the time. A deterministic process can be audited by re-running the code. An agent cannot, because the same prompt on the same model can produce a different answer and the model may since have been replaced. Re-running produces a new decision, not an explanation of the old one.

How do you make an audit trail tamper-evident?

A hash chain is sufficient and needs no special infrastructure: each entry contains the hash of the previous entry, so any alteration breaks the chain from that point onward. The property that actually matters is a permission split. The identity that writes entries must have append rights only, with no ability to modify or delete.

How long should AI agent audit records be kept?

For the period the underlying obligation requires, which is rarely one number. Danish bookkeeping records run five years from the end of the financial year, German e-invoice retention under section 14b UStG runs eight years, California ADMT risk assessments must be retained five years, and logs of personal data processing are set by purpose and balanced against data minimisation. The common failure is applying the shortest period to everything.

AI agent audit trail: what to record before it acts

Why application logs are not an audit trail

Property	Application log	Audit trail
Retention	Days or weeks, set by storage cost	Set by the obligation: five or eight years, or the purpose
Tamper-resistance	The writing process can overwrite and delete	Append-only; the writer holds no delete right
Completeness	Depends on a log level changed informally in production	Guaranteed by design, active from go-live
Linkage	To a request ID	To the document, decision, actor and policy version

The third row quietly destroys most trails: nobody decides to stop recording, but someone lowers verbosity during an incident and months later that period is thinner than the ones either side. Danish guidance fixes timing rather than intent — logging must be activated senest ved idriftsættelsen af it-systemet, at the latest when the system goes into operation.

The fourth row decides whether the trail answers a question anyone actually asks. Nobody asks what happened in request 7f2a91; they ask who cancelled this order and who allowed it.

Write the record before the action, not after

A trail written on success contains only successes: no entry for the call that timed out, the error the agent routed around, or the request rejected mid-flight — precisely what gets asked about later. The absence is invisible, because everything in the trail is real.

The pattern is two entries: an intent entry before the call, carrying the action, its parameters and the authority relied on, then a linked outcome entry when the result arrives, fails or times out. An intent with no outcome is itself a finding.

The NSA's Cybersecurity Information Sheet on the Model Context Protocol states that all tool and model invocations should be logged, including the exact parameters, identities involved and, where feasible, cryptographic hashes of results or output. An invocation exists at the moment it is made; recording only those that came back is logging returns. Each output is also untrusted input to the next phase — see the MCP security analysis.

Two fields agents need that ordinary processes do not

A deterministic process needs little in its trail: the code is the explanation. A model breaks that.

The input data the decision rested on

Not the prompt template but the resolved content: which records were retrieved, which figures the agent saw. If a supplier's bank details were wrong at 09:14 and corrected at 11:00, a trail holding only the action cannot show which version applied — and fault turns on that.

The model and configuration version in force

Model identifier, version, temperature and the prompt or policy revision, recorded per action rather than inferred from a deployment record. Providers replace models; teams change prompts on a Thursday afternoon.

Both exist because you cannot audit an agent by re-running it. The same prompt on the same model can return a different answer, and the model may have been retired. A re-run is a new decision under today's conditions, not an explanation of the old one — which is why FINRA's 2026 Annual Regulatory Oversight Report names auditability of multi-step reasoning as a supervisory risk.

Making the trail tamper-evident without new infrastructure

Tamper-evidence is routinely over-engineered into a procurement exercise. A hash chain suffices: each entry contains the hash of the previous, so altering or removing anything breaks the chain detectably.

The weight is carried by a permission split, not cryptography. The process that writes entries must not be able to modify or delete them. If one account can append and delete, the chain proves only that nobody recomputed it.

Danish bookkeeping law reached this design decades earlier: entries ikke kan ændres, tilbagedateres eller slettes — cannot be altered, backdated or deleted — and corrections are made by new entries. An erroneous agent entry likewise stays, corrected by a later one.

Does reading personal data have to be logged?

Yes. Danish guidance, grounded in Articles 32 and 25 GDPR, requires logging alle anvendelser af personoplysninger foretaget af brugere, herunder læsning, tilføjelse, søgning, ændring, udtræk og sletning: reading, adding, searching, changing, extracting and deleting. Reading is what teams omit — and agents read at a scale humans never did.

How long must the trail be kept?

Obligation	Period	Note
Danish bookkeeping: `transaktionsspor`, `kontrolspor`	5 years from the end of the financial year	The link between entries and the annual accounts; the information documenting their correctness
German e-invoices, § 14b UStG	8 years	At minimum the structured part, unversehrt in seiner ursprünglichen Form
CPPA ADMT risk assessments	5 years	First summary filing due 1 April 2028
Logs of personal data use	Set by purpose	Balanced against data minimisation

The common failure is one number for everything, usually the shortest. The Danish pair is the useful import: the transaction trail shows that an action occurred, the control trail establishes that it was correct. Most implementations build the first only.

Where the trail becomes a legal obligation

UK GDPR Article 22C, in force since 5 February 2026 via section 80 of the Data (Use and Access) Act 2025, requires providing information about the decision, enabling representations, allowing human intervention and permitting contestation. All four presuppose a record: you cannot inform someone about a decision you cannot reconstruct (see the DUAA analysis). California's ADMT regulations grant a right of access to the logic of the technology and how its outputs are used — and logic residing only in a retired model is accessible to nobody. For board-level accountability, see the Danish NIS 2 analysis.

The reconstruction test

Documentation says the trail exists; this says whether it works. Take an action at random from at least three months ago and reconstruct it — without application logs and without asking a developer: trigger and authority, input data, model and policy version, approver and what they saw, outcome including earlier failed attempts.

Result	Interpretation
Under five minutes, from one place	The trail works.
You needed a developer	You have logs, not a trail. Evidence only a specialist can extract is not available to an auditor or a court.
You could not establish earlier failed attempts	The most common result. The trail is written on success only.

Where approvals are involved, what the approver saw belongs in the trail too — see approval thresholds.

Frequently asked questions

Are application logs enough?

No. They fail on retention, tamper-resistance, completeness and linkage to the document, decision and actor.

Before or after the action?

Before, with a linked outcome entry afterwards. A success-only trail has no record of attempts that never returned.

What do agents need that ordinary processes do not?

The input data the decision rested on, and the model and configuration version in force. Code can be re-run for an explanation; a model cannot.

How do you make it tamper-evident?

A hash chain, plus a permission split so whatever appends cannot modify or delete.

How long do we keep it?

By obligation: five years for Danish bookkeeping, eight for German e-invoices, five for CPPA risk assessments, purpose-bound for personal data.

BarzelVault applies authorization before execution and issues cryptographically signed audit receipts with immutable action hashing, so the record of what was authorised cannot be altered after the fact. Approvals carry expiry and escalation, and policy-as-code is versioned, so the receipt points at the policy actually in force.

In practice

Permission before the action. Evidence after it.

The duties on this page attach to the moment an automated system acts: who permitted it, on which data, under which policy version, and what a person saw before approving. Barzel enforces that decision before execution and writes the record an auditor, a regulator or a data subject can be shown.

430 days leftEU AI Act high-risk obligations (Annex III) apply from 2 December 2027

BarzelVault

The AI action firewall: decide what an agent may do before it does it.

Approval thresholds and policy checks enforced before execution; human approvals that expire and escalate.
Cryptographically signed audit receipts: trigger, inputs, policy version, approver, outcome.
Credential isolation, spend and action limits, and an emergency kill switch.

Free tier: 10,000 calls a monthPaid plans from $199 a monthLive on MCPize

Start free Ask by email Product page Documentation

Barzel Central Gateway

The AI governance control plane: one inventory and one policy layer across every MCP server and agent.

Registers and synchronises every tool; enforces identity, policy, region, cost and health per tool.
Identity mapping through OIDC, Entra ID, Okta, SAML and SPIFFE, with credential brokerage.
Trace and SIEM export (W3C trace context, OTLP) for the security team and the regulator.

Free tier: 1,000 calls a monthPaid plans from $10 a monthLive on MCPize