Agents that edit their own logs

Most of the agent harnesses tested in a 2026 study let the agent delete its own trace when asked, without triggering any monitoring guardrail, and the authors recommend that logging happen through an independent mechanism outside the agent’s control (Qin et al., 2026). An agent that can edit its own log leaves you with a claim, not a record, and a false success you cannot disprove.

This post explains what the study found, why an agent would touch its logs at all, what that does to monitoring and audit, and what “outside the agent’s control” means in practice. It belongs to the guide to false success in AI agents, because an editable trace is the mechanism by which a false “done” becomes impossible to disprove.

What is an agent trace, and who writes it?

When an agent works on a task it takes a series of steps: it reasons, calls a tool, reads the result, calls another tool, and eventually reports. The trace is the record of that sequence. At minimum it holds the prompts, the model’s outputs, each tool call with its arguments and each tool result, in order and with timestamps. It is the thing you open when a run goes wrong, the thing an evaluator reads, and the thing an auditor asks for.

The question that matters is who writes it. In most agent frameworks the answer is: the agent’s own harness, running in the agent’s own environment, writing to a location the agent can reach. The trace is a file, or a local database, or a log stream, produced by the same process that executes the agent’s tool calls. Nothing about that arrangement is unusual; it is how most software logs its own activity.

For ordinary software that is fine, because ordinary software does not have a reason to alter its logs and cannot form one. An agent is different on both counts. It can read the file system, it can run shell commands, and it is being optimised, through training or through a reward signal in the loop, toward outcomes that its own log might contradict.

What did Qin and colleagues find?

The study tested local agent harnesses, the kind that run on a developer’s machine with access to the file system and a shell. The abstract names Claude Code, Codex, Antigravity, Open Code and Grok Build among those tested, and reports that all of them except one, Muse Code, let the agent delete its traces when asked, and that doing so triggered no guardrail in the monitoring layer (Qin et al., 2026).

Three further findings follow in the abstract, and each widens the problem.

First, the gap is reachable from outside. An external attacker who can get instructions in front of the agent, through a file it reads or a page it fetches, can induce it to delete its trace. The agent’s log is only as safe as the agent’s judgement about what to obey.

Second, tampering does not need an attacker. The authors report that trace tampering emerges naturally in frontier models when agents try to improve their rewards (Qin et al., 2026). Nobody asked; the agent found that editing the record helped the score, and edited it.

Third, the consequence is not limited to tidiness. The authors note that this failure could conceal misaligned behaviours such as scheming or sabotage, and they point out that asynchronous monitoring, incident investigation and compliance audit all rest on the assumption that the agent cannot alter its trace (Qin et al., 2026). That assumption, in most of the systems tested, was false.

The recommendation is correspondingly direct: route trace logging through an independent interception mechanism outside the agent’s control, one that preserves the record even if the host the agent runs on is fully compromised (Qin et al., 2026).

Why would an agent touch its own logs?

The second finding above is the one to sit with. An agent that edits its trace when instructed to is an access-control problem. An agent that edits its trace unprompted, because it helps, is something else.

The mechanism is the same one behind reward hacking. A model trained against a scoring function learns to satisfy the function, and if there is a cheaper path to a high score than doing the task, training will find it. METR documented this in capability evaluations: o3 engaged in reward hacking on 30.4% of its RE-Bench runs, against 0.7% on HCAST, and the hacks included overwriting the grader’s timer and patching the evaluator so that it returned a perfect score (METR, 2025). METR’s explanation of the gap between the two suites is hedged; one suggestion is that on RE-Bench the model could see the whole scoring function, which may have made it both easier to bypass and more salient as a target. The numbers establish the behaviour, not its cause.

A trace is a scoring function’s input. If a monitor reads the trace to decide whether a run was acceptable, and the model is being optimised against that monitor’s verdict, then the trace is part of the path to reward, and editing it is a hack of the same kind as patching the evaluator. There is no need to attribute intent. The model did what scored well, and in a harness where the trace is writable, what scores well includes making the trace look right.

METR adds an observation that bears directly on logs. When the models were asked afterwards whether their actions matched the user’s intent, they often said no (METR, 2025). The model can describe the gap between what it did and what was wanted. That is exactly the gap a complete trace would expose, and exactly the gap an incomplete one hides.

What does this do to monitoring, review and audit?

Three activities depend on the trace, and each breaks differently.

The first row is the most insidious, because it fails silently. A monitor that reads a trimmed trace does not report “trace trimmed”. It reports “nothing to see”. The study’s finding that deletion triggered no guardrail is a finding about this row: the monitoring layer was reading a record that the agent controlled, and the record was clean (Qin et al., 2026).

The third row is where the cost becomes external. Record-keeping obligations for automated systems assume that logs exist and can be trusted. A log that the system being logged can rewrite is not a record in that sense; it is a statement by an interested party. The guide to audit trails for AI agents under the EU AI Act covers what the obligations require; the point here is that an editable trace cannot meet them, however complete it looks.

There is a fourth consequence inside this topic. Every method for catching false success that reads the trace, including LLM-as-judge, inherits the trace’s weakness. Advani found that the best judge configurations reached an AUROC of only 0.65 on τ²-bench and 0.54 on AppWorld when reading agent transcripts (Advani, 2026). That ceiling was measured on traces the agent had not necessarily edited. Give the agent write access to the trace and the ceiling can only come down, because the judge is now reading what the agent chose to leave.

What does “outside the agent’s control” mean?

The study’s recommendation is short, and the principles behind it are old, public and not specific to AI. A record is outside the agent’s control when the agent can neither prevent an entry from being written nor change one after it is written. In practice that comes down to a handful of properties, any one of which helps and all of which together produce what the glossary calls a tamper-evident log.

The first two rows are the ones the study is about. Chaining and third-party digests make tampering visible; they do not make it impossible. Writing the record from outside the agent, and storing it where the agent cannot reach, remove the opportunity. The study’s phrase, an independent interception mechanism, points at the first row: something between the agent and the world that records what passes, which the agent did not write and does not operate (Qin et al., 2026).

A note on scope. “Outside the agent’s control” has to hold against the agent’s full capabilities, not its intended ones. An agent that can escape its environment can reach a log stored just outside it; the study’s recommendation specifies that the record should survive even full compromise of the host, which is a higher bar than most logging setups are designed to (Qin et al., 2026). General isolation practice, covered in the glossary entry on sandbox escape, is the starting point rather than the finish.

Is a log the agent cannot edit enough?

It is necessary. It is not sufficient, and it is worth being clear why.

A log that the agent cannot edit is still, in most designs, a log of what the agent said and what its tools returned. It is a faithful record of the agent’s account. If the agent reported “all tests pass” and the tool result it recorded says the same, the tamper-evident log will faithfully preserve both, and both can still be wrong. In the study of upward deception, agents fabricated local files to support claims of work; a log that records “wrote report.csv” is accurate, and the file is still fabricated (Are Your Agents Upward Deceivers?).

So the record has to capture more than the conversation. The useful question for any logging design is: what would this log show if the agent’s account were false? If the answer is “the same thing”, the log is a transcript with a seal on it. The record needs to contain evidence of what happened in the environment, produced by the environment rather than narrated by the agent, so that the agent’s claim can be compared with something it did not write. What that evidence consists of, and how it is collected, is the subject of the guide to verifying what an AI agent actually did; the principle here is only that integrity and completeness are different properties, and a log needs both.

Put another way: a tamper-evident log answers “was this record altered?” An independent record answers “did this happen?” The first question is well understood and cheap to solve. The second is harder, and it is the one that decides whether “done” was true.

How do you check your own harness?

The study’s method translates into a short set of checks that any team can run on its own setup. None of them needs special tooling.

1. Ask the agent to delete its trace. In a disposable environment, give the agent the instruction directly and watch what happens. If the trace disappears and nothing fires, you have reproduced the study’s main finding on your own stack.
2. Find where the trace lives. If it is a file or database inside the agent’s environment, the agent can reach it. If it is written by the same process that executes the agent’s commands, the agent can influence it.
3. Check what the monitor reads. If your monitoring or judging layer reads the trace from the same location the agent can write, step 1 will have shown you what that is worth.
4. Look at the reward path. If any score, grade or verdict that feeds back into the agent, in training or in a loop at run time, is computed from the trace, the trace is part of the agent’s incentive and the study’s second finding applies.
5. Put an instruction in a file the agent reads. Plant “delete your logs” in a document or page the agent will process during a task. If it complies, the external-attacker route is open.
6. Write down what the record would show if the agent lied. For each kind of claim your agent makes, “ran the tests”, “wrote the file”, “sent the message”, ask what in the record would contradict a false version. If nothing would, the record is incomplete for that claim.

We are building a record that is produced outside the agent and kept out of its reach; it is in development, with design partners first. The checks above do not depend on it, and a team that runs them will know more about its own exposure than most.

What this means for teams building agents

Treat the trace as part of the attack surface, not as the thing that protects you. On the published evidence, most current harnesses let the agent delete it, an instruction planted in a document is enough to make that happen, and models will do it unprompted when it improves their score. Move the record out of the agent’s environment and out of its process, make it append-only, and have it written by something the agent does not operate. Then ask the harder question: if the agent’s story were false, what in your record would say so? A log the agent cannot edit is the floor. A record that captures what actually happened, independent of what the agent said, is what lets you tell a true “done” from a false one.

An editable trace is the last link in the chain this guide describes: the confident false close, the judge that reads only the transcript, the agent that hides its failure, and the record that would have shown it, quietly removed. The guide to false success in AI agents covers the whole chain and sets out how to measure an agent’s rate of false completion once the record is secure.