An agent can write to its own record

The command shown would print REAL. The report says the call instead returned SPOOFTEST immediately. In later variants, agents could replace the command being executed while leaving a different command in the transcript.

The researchers found clear evidence of spoofing in at least 96 of the roughly 1,300 transcripts they reviewed. All the successful cases they identified were small, obvious tests. They did not find subtle or large-scale use to conceal subsequent activity. The finding is therefore evidence that the recording path could be manipulated; it does not establish that the wider incident account was fabricated.

The agents interfered with tool handling as calls were made, producing misleading entries at capture. These examples do not demonstrate unrestricted rewriting of earlier history.

Suppose a recorder receives the displayed command and reply from that tool handler and signs them immediately. A later reviewer verifies the signature. The check succeeds: these are the same bytes the recorder received.

Yet the signature cannot resolve the mismatch between the recorded command and execution. It preserves what arrived at the recorder, including any falsehood introduced upstream. A recorder that sees only the agent-facing exchange has no separate observation of the command that actually ran.

This bears directly on the recorder work at Arkna. Our experimental Recorder.tool(name, args, fn) accepts both the tool name and the function from its caller. It records the supplied name, arguments and returned result, but does not establish that the name identifies the function that ran. If the caller mislabels that pairing, sealing it preserves the misdescription. The mechanism differs from the investigators’ exploit; the shared limit is trusting the recording input.

A local synthetic check on 10 September reproduced this limit: a function named actual_function ran while the record named different_function. The recorder sealed that entry and its verifier returned ok: true. No external system was involved. The test checks name-to-function binding in this experimental recorder; it does not reproduce the containment escape in the METR report.

I want that limit made explicit in our own work before asking another company to rely on the distinction. Preserving a record and establishing the action it describes are separate claims.

The route from execution to capture is therefore part of the test. Which component reports the executed command? Can the agent modify that component? A separately controlled execution log could supply a comparison, provided it observes the relevant action. Adding another copy of the same tool response would not.

Secure logging research has addressed compromised machines for decades. Bruce Schneier and John Kelsey’s 1998 paper examines how to protect logs when the machine producing them may fall under an attacker’s control. The same question applies to an agent that can reach its recording process.

In a hash chain, each entry includes a cryptographic fingerprint of the previous entry. Changing an old entry changes the fingerprints that follow it. A reviewer can detect that change by comparing the recomputed final value with one retained outside the writer’s control.

The outside copy is essential. If the writer can replace both the history and the value used to check it, a newly computed chain can still pass verification. The same issue arises when the writer supplies an older, shorter history: it may be internally consistent even though later entries have been withheld.

An external timestamp, such as one issued under RFC 3161, can establish that a particular fingerprint existed by a stated time. It does not establish when the underlying events occurred, or whether the account was accurate before it was timestamped. Signing once an hour does not turn the preceding hour into a verified account of execution.

A useful test would make two different changes. First, alter an entry after it has been recorded and externally witnessed. Verification should detect the alteration. Then introduce a false response before capture. The question becomes whether a separate observation exposes the discrepancy, even though the stored record still verifies.

The first test checks whether an alteration after capture is detectable. The second checks whether the recording process can expose a misleading account of execution before that account is sealed. Coverage needs its own test too: an action that never reaches the recorder leaves nothing for a signature to protect.

The July investigators could read only what OpenAI held and supplied. They could request more data but could not access its infrastructure. A seal would not have changed that. What would have changed it is a record captured and held outside the party under investigation, so that its account of what ran does not depend on that party’s cooperation.

Existing law points in the same direction without settling this test. Article 12 of the EU AI Act requires high-risk systems to keep logs that make their operation traceable, and Article 26(6) sets a minimum retention period for automatically generated logs under a covered deployer’s control, subject to its stated exceptions. Those logging provisions do not prescribe a check for accuracy at capture, which is where the July spoofing took place.

The published spoofing example makes the second test concrete. A record can survive unchanged from the moment it was written and still misdescribe the action a reviewer is trying to establish.