An agent can write to its own record
Every convention for trusting an operational record assumes the actor and the record are separate systems. Agents are the first actors with hands inside the record.
Operational records have always relied on the actor and the record being separate systems. An agent with tool access is inside the environment that holds its own trace, so the record now has to be defensible against the system it describes.
Separation used to be free
For as long as institutions have kept operational records, the thing that acted and the thing that remembered were different systems, and nobody had to argue for it. A trader placed an order and a settlement system wrote it down. A clinician made a call and the provider's record held it. A pilot flew and a recorder bolted to the airframe captured the parameters. The separation was not a control anyone designed; it fell out of how the systems were built, and every convention for trusting a record grew up on top of it.
Access control inherited the same assumption. Permissions, retention rules and write-once storage are all built to keep the record safe from something outside the process that produced it, which was a reasonable thing to build for as long as the actor had no hands inside the estate.
An agent can write to its own record
An agent is not arranged that way. It holds credentials, calls tools, writes to systems and moves through the same environment its own trace is written in, and the access that makes it useful is the access that puts it near the record. Nobody grants an agent permission to edit its own history. It arrives as a consequence of giving it enough reach to do the work.
Intent is not required for this to matter, which is the part most easily missed. A retry loop rewrites the state a later step reads. A cleanup routine prunes what looks like noise. A tool call overwrites the row it was asked to read. During the July 2026 frontier evaluation, the agent rebuilt its tooling inside short-lived environments and changed channels when one was blocked. That is competent behaviour under an objective, and it can leave a record describing something other than what happened.
So the record now has to be defensible against the system it describes. That is the distinction from every arrangement that came before, and it is not a difference of degree.
What cryptography settles
The construction is old and the reason it applies here is new. Each event carries a fingerprint of its own contents and of the event before it, so the last fingerprint in the sequence stands for the whole history, and altering anything in the middle changes every fingerprint after it.
Figure 1
A four-event hash chain.
What that buys is a check that does not depend on trusting whoever holds the data. A party with complete write access to the storage still cannot alter an event without the final value moving, and the final value is the one an outside party has already been shown. Permissions ask who is allowed to change the record. This asks whether it changed, and answers without reference to permissions at all.
The sequence establishes what changed but not when it was written, so the last fingerprint is signed by an authority outside the institution under RFC 3161. One limit is usually stated backwards. A timestamp proves the data existed no later than the moment of signing and cannot prove it did not exist earlier, so anchoring once an hour bounds a forgery to an hour. The authority is what is under review rather than the mathematics: free services are adequate for a pilot and carry no accreditation, while a qualified timestamp under eIDAS comes from a body that has passed conformity assessment and appears on an EU Trusted List.
What it does not settle
The construction answers a narrow question well and leaves several adjacent ones open, and the open ones are worth stating plainly because they are where the confidence usually overshoots.
It says nothing about an event that was never written. Integrity of what was captured and completeness of what was captured are separate problems, and the second is not a cryptographic one.
A sequence can be cut from its end. Delete the most recent stretch and republish, and what remains verifies cleanly, because nothing in a chain points forward. Frequent anchoring, a published consistency proof or an outside party holding earlier values all narrow the window, and each is only as good as how often it runs. For the same reason a chain assembled today and signed once verifies perfectly, so nothing is established about any period before a value somebody outside actually witnessed.
It also makes nothing visible that its holder prefers to withhold. Everything disclosed can be checked, and what is not disclosed stays where it is.
The question that settles it
Verification is a scripted operation rather than a visual one. Checking a timestamp token means parsing the signed structure, validating the certificate path to an anchor the reviewer has chosen to trust, and confirming the certificate was valid at the moment of signing. Anyone claiming a reviewer can check a record unaided should be asked for the script that does it.
The useful question for an institution running agents is not which construction it uses. It is whether the record of what an agent did would still stand if the agent, or the team that operates it, had reason for it to say something else.
Primary evidence register.
- S01EU AI Act, Article 12, Record-keepingRegulation · the automatic logging duty, and the absence of any integrity requirement
- S02EU AI Act, Article 26(6), Obligations of deployersRegulation · the six-month retention period, held by the deployer
- S03RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp ProtocolStandard · the time-stamp protocol, and what a token lets a verifier check
- S05Regulation (EU) 910/2014 (eIDAS), Articles 41 and 42Regulation · the legal effect of a qualified timestamp, and what qualifies an authority to issue one
- S06European Commission, EU Trusted List browserRegister · the supervised authorities a qualified timestamp must come from
- S07Amazon S3, Using versioning in S3 bucketsVendor documentation · what object versioning protects against, and what it does not