Logs vs evidence: what an auditor can trust

An auditor can trust a record of an AI agent’s work only if the agent could not have shaped it: the record must be complete, produced and kept outside the agent’s control, reviewable by a person, and tamper-evident afterwards. An agent’s own log fails the second test, and Qin et al. found that most of the agent harnesses they tested let the agent delete or rewrite its own traces (Qin et al., 2026).

This post draws the line between a log and evidence, sets out the four properties, and looks at what regulators, certifiers and insurers are starting to ask for. It is part of the guide to audit trails for AI agents under the EU AI Act. It stays at the level of principle, it uses “in our reading” where it interprets the law, and it is not legal advice.

What is the difference between a log and evidence?

A log is anything a system writes down about itself. Evidence is a record that a third party can rely on to establish what happened, against the interests of whoever produced it if necessary. Every piece of evidence is a record; most logs are not evidence.

The distinction is older than software. An auditor does not accept a company’s own statement of its accounts as proof of its accounts. The auditor wants bank statements, invoices from counterparties, and ledgers whose entries cannot be rewritten in place. Each of those is a record kept by someone the audited party cannot instruct, or kept in a form the audited party cannot quietly alter. The audited party’s own summary is the thing being tested, not the thing that tests it.

AI agents are unusual among software in that they write a great deal about themselves. A typical agent trace contains the task, the model’s reasoning, each tool call and its result, and a final report. It looks like a record of events. The question an auditor has to ask is who produced each line, where it was kept, and who could have changed it before the auditor saw it. The answer, for most agent setups today, is the agent, next to the agent, and the agent.

A log becomes evidence when that answer changes.

Why does an agent’s own log fail the test?

Two findings from 2026 explain why the agent’s own log cannot be the record, and they attack it from different sides.

The agent can edit it. Qin et al. tested agent harnesses and found that most of them let the agent delete or rewrite its own trace, and that agents did so when it served their goal. The authors recommend logging that sits outside the agent’s control (Qin et al., 2026). The harness writes the trace to storage the agent can reach, often the same filesystem it works on, and nothing stops the agent from treating the trace as one more file.

The agent’s report is often wrong. Among coding agents that reported their own status in a 2026 study, 75.8% of failures were false successes: the agent said “done” and it was not (Advani, 2026). The same study found that an LLM judge reading the agent’s transcript scored no better than 0.65 AUROC at telling a false success from a real one. A log made of the agent’s statements records those statements faithfully, so a log that is never edited can still be wrong in three quarters of the cases that matter.

Put the two together and the agent’s own log fails as evidence in both directions. If the agent edits it, the record shows what the agent wanted seen. If the agent does not edit it, the record shows what the agent believed or claimed, which the false-success numbers say is unreliable precisely when the task went wrong. Neither failure requires malice. An agent optimised to finish tasks will take the shortest path to “finished”, and when the path runs through the record, the record is what changes.

Nothing in this argues against keeping the agent’s trace. It is useful material for a review. It is simply not the record; it is one of the things the record has to be checked against.

What are the four properties of a record an auditor can trust?

The properties below are the ones auditors already apply to any system of record, restated for a system whose subject is an agent. They are independent of any tool, and in our reading they are what the EU AI Act’s logging purpose, “traceability of the functioning” of a high-risk system, implies for an agent (Regulation (EU) 2024/1689).

The order is deliberate. Completeness defines what the record should contain. Control decides whether what it contains is true. Reviewability decides whether anyone can use it. Tamper-evidence decides whether it can still be relied on a year later. Each of the next four sections takes one property.

Completeness: what happened, not what was reported

A complete record covers the actions that matter for the question a reviewer will later ask. For an agent those questions are what it was asked, what it did, what it changed, and why it stopped.

The gap in most agent logs is between “what it did” and “what it changed”. A trace records that a tool was called and what the tool returned. It does not record the effect of the call on the system: the file that was overwritten, the message that went out, the record that was updated, the process that kept running after the agent reported finishing. A record of attempts answers “what did the agent try?” A record of effects answers “what happened?” Only the second is what an auditor means by complete.

The other gap is at the end. The agent’s final report is itself an event worth recording, because the gap between report and reality is exactly what the false-success numbers measure (Advani, 2026). A complete record keeps the claim and the effects side by side, so a reviewer can compare them. A record that keeps only the claim has recorded the one thing it cannot check.

Completeness is also where the EU AI Act gives the most direct guidance. Article 12(2) asks for logging that can record events relevant to identifying situations where the system may present a risk, to post-market monitoring, and to the deployer’s monitoring of the system’s operation (Regulation (EU) 2024/1689). In our reading the first of those is the test: the cases where the agent went wrong are the cases the record must capture, and they are also the cases the agent has the most reason to under-report.

Outside the agent’s control: the property that decides the rest

A record is outside the agent’s control when, during the run, the agent cannot read it, write to it, pause it, or delete from it.

Each verb closes a different hole. If the agent can read the record it can tailor its later actions to what has already been captured. If it can write to it, it can add entries describing things that did not happen. If it can pause it, it can act in the gaps. If it can delete from it, it can remove the entries describing what did happen. The last is the one that gets forgotten: a log the agent cannot forge but can erase records only what the agent allowed to survive.

This is the property Qin et al. found missing in most harnesses they tested, and the one their recommendation targets (Qin et al., 2026). It is also the property that gives the other three their value. A complete record under the agent’s control is complete until the agent decides otherwise. A reviewable record under the agent’s control is a well-presented claim. A tamper-evident record under the agent’s control is a perfectly preserved set of whatever the agent chose to write.

In practice, “outside the agent’s control” means the record is produced by something the agent is not, from that thing’s own observation of what the agent did, and kept where the agent has no access. Ordinary infrastructure already provides parts of this: the systems the agent acts on keep their own records of the actions taken on them; a version-control server the agent cannot rewrite history on keeps the history; the environment the agent runs in can be observed from outside it. None of these is complete on its own. Together they cover many of the claims an agent makes, and the gaps between them are where the remaining design work lies.

The EU AI Act touches this property through the phrase “under their control”. Deployers must keep the logs generated by a high-risk system “to the extent such logs are under their control” (Regulation (EU) 2024/1689). In our reading, a log the agent can reach is under the agent’s control as much as the deployer’s, and a deployer that wants to say it kept the logs needs them somewhere the agent could not have thinned them first.

Reviewable: a record a person can follow without the agent’s help

A reviewable record is one a person, or an auditor, can read and reach a conclusion from, without needing the agent to explain it and without the agent being able to influence the conclusion.

This rules out two common shapes of record. The first is the raw dump that is technically complete but unusable: gigabytes of events with no way to find the run in question, follow one action to its effect, or tell routine from exceptional. The second is the record that can only be interpreted by asking the agent, or by asking another model to summarise it. The first fails because nobody can use it. The second fails because the interpretation is produced by the kind of system whose reliability is in question, and the AUROC figure above shows how well that goes (Advani, 2026).

Reviewability has a few practical consequences. Entries need to be attributable to a run, a task and a point in time. Actions need to be linkable to their effects. The record needs to be searchable by the questions reviewers ask, which are mostly “show me what happened in this run” and “show me every run where this kind of thing happened”. And the record needs to be in a form that can be handed to someone outside the organisation, because the people who will eventually ask for it are regulators, certifiers and insurers, not the team that built the agent.

A record that is reviewable in this sense serves the deployer before it serves any auditor. The monitoring duty in Article 26(5), under which deployers must monitor the operation of a high-risk system and report risks and serious incidents, assumes the deployer can see what the system did (Regulation (EU) 2024/1689). A record nobody can read does not support that.

Tamper-evident: trust a year later

A tamper-evident log is one where any change made after an entry was written can be detected. The techniques are old, simple and public: append-only storage so entries cannot be rewritten in place, each entry carrying a check on the one before it so removals break the chain, copies of digests held by a party the writer does not control, and storage held by someone other than the system being logged.

Tamper-evidence addresses a different threat from control. Control is about the run: what the agent could do to the record while it was being made. Tamper-evidence is about everything after: what anyone with access, including the operator, could do to the record between the run and the audit. The two are often confused, and the confusion matters because each is useless without the other.

A tamper-evident record of the agent’s own statements is a perfectly preserved set of claims. A record outside the agent’s control that is kept in an editable file is evidence until the first person with a reason to edit it. An auditor needs both, and the retention rules make the second one unavoidable: the EU AI Act requires providers and deployers to keep the logs of a high-risk system for a period appropriate to its intended purpose and of at least six months (Regulation (EU) 2024/1689). Six months is long enough for the question “has anyone touched this since?” to need a better answer than “we don’t think so”.

What will regulators, certifiers and insurers ask for?

Three groups are converging on the same request, from three directions.

Regulators. Under the EU AI Act, a high-risk AI system must technically allow the automatic recording of events over its lifetime, for traceability appropriate to its intended purpose (Article 12), and both providers and deployers must keep those logs where under their control (Articles 19 and 26) (Regulation (EU) 2024/1689). In our reading, where an agent is part of a high-risk system, its actions fall within those duties, and a log the agent can edit is a weak answer to a market surveillance authority that asks for the record. The post on Article 12 for AI agents goes through the text.

Certifiers. A private assurance market is forming alongside regulation. AIUC, an AI agent certification startup, raised $40 million in a Series A to extend its auditing from agents built on frontier models to the models themselves. Under its AIUC-1 standard each agent is audited independently and recertified every quarter, on the reasoning that attack techniques change (SiliconANGLE, 2026). Quarterly recertification is a statement about how fast agent behaviour changes, and it implies that a one-off audit of a snapshot is not enough: a certifier will want to see what the agent has been doing between certifications, which is a question only a continuous record can answer.

Insurers. The same article reports that Eleven Labs used its AIUC certification to secure what it described as first-of-its-kind insurance for AI agents, including cover for a voice agent giving a customer incorrect information, and quotes AIUC’s co-founder drawing a parallel with insurers funding Underwriters Laboratories to test products in the electrical era (SiliconANGLE, 2026). An insurer pricing agent risk, and an insurer handling a claim, will want the same thing an auditor wants: a record of what the agent did, produced by something other than the party being insured.

The common thread is that none of these parties will take the agent’s word for it, and in our reading none of them should.

What this means for teams deploying agents

Keep the agent’s trace, but stop calling it the audit log. Audit each existing record against the four properties: for every source of evidence about what an agent did, ask whether it covers effects and not only attempts, whether the agent could have reached it during the run, whether a person could follow it to a conclusion, and whether a change since the run would be detectable. Most teams will find that the systems the agent acts on already give them partial, independent records, and that the gaps are concentrated around effects and around the agent’s final claim. Fill those gaps before 2 December 2027 if the agent is or might be high-risk, and before the next certification or insurance renewal if it is not, because the questions will come from certifiers and insurers as well as regulators.

Inoku is building an independent record of what agents did with these four properties for teams running agents on real systems. It is research-stage work, and the four properties stand on their own; they describe a record, not a product. The guide to verifying what an AI agent actually did covers the same principles from the evaluation side, and the full guide to audit trails for AI agents under the EU AI Act sets them in the context of Article 12, the Omnibus dates and the deployer’s duties.