Who Wrote the Log? Ninety Seconds on Why an Agent's Record Needs a Second Author

An agent works through the night. In the morning the bill is up, a bucket is gone, and the first question anyone asks is the one this post is about: what did it do? We made a ninety-second film that answers it without a word of audio. This is the same argument in prose, for readers who would rather scroll than watch.

There is a log

Of course there is a log. The agent wrote it, or the people who run the agent did. That is the whole problem in one sentence: whoever can write a log can rewrite it. An entry that read delete bucket tmp-2 at 03:41 can read empty cache by 09:00, and the file looks exactly as tidy as before. A log that can be edited proves one thing, which is that someone wrote a log.

Hash chains help, then stop helping

The usual fix is a hash chain. Each record carries the hash of the record before it, so changing one record breaks every link after it. That catches a careless edit. It does not catch a careful one: rewrite the record, then rewrite every hash after it, and the new chain verifies as cleanly as the old one. Put the two side by side and both pass. A chain proves the records are consistent with each other. It cannot tell you which set of consistent records was written when, and that was the question. We wrote about this limit before; the film shows it in about ten seconds.

Hand the root to someone who is not you

The fix that works is older than any of this software. Close the records into a block, compute one root that stands for everything in it, and hand that root to parties who have no stake in the log. An RFC 3161 timestamping authority signs the root together with the time it saw it. An OpenTimestamps proof commits the same root to the Bitcoin blockchain. Now rewrite the past: the root changes, and the receipts still name the old one. Faking the record would take the authority lying and Bitcoin rewinding, together. Two anchors rather than one, so distrusting either does not dismiss the record.

What this does not prove matters as much. Anchoring shows a record existed in exactly this form no later than the time its block was anchored, and that nothing has been inserted, removed or edited since. It does not show the record was true when written. A journal is an honest diary, not a witness. What it removes is the possibility that the diary was rewritten afterwards.

Verify it yourself

None of this asks you to trust us. The format and the verifier are open source at github.com/abacross/agent-journal, as of today. Our own operations journal, every production action this company has taken since the redesign, is public at github.com/abacross/ops-journal: clone it, run ajv verify --require rfc3161,opentimestamps, and the exit code is the evidence. The journal page runs the same check in your browser, from the same data, with the same code our tests hold to the reference implementation.

Why now

Every company that runs agents is about to be asked the same three things: by a customer, show me what your agent did in my account; by an auditor, prove that record is the original; by a regulator, keep logs you can produce on request. The EU’s AI Act sets record-keeping duties for high-risk systems, with obligations phasing in through 2026 and 2027 (the regulation’s text). The answer to all three is a record the operator cannot rewrite, kept by someone who is not the agent. That is what the attestation service is, and what our own journal has been since the day the site was rebuilt.

If your agents run on AWS and you want to know whether the account could prove what they did today, the readiness check is one read-only file and five minutes.