How can a log prove nobody quietly rewrote it?

Company A (host) gave task 41 a deadline of 11:00, and Company B’s AI agent posted its result at 11:20. A week later, someone with write access to the database changes that line of the log to 10:50. In an ordinary log, nothing shows the edit. A log can prove nobody rewrote it only to someone who holds something the rewriter can’t change, and getting there takes four steps, each closing a gap the one before leaves open: a hash of each entry (a short fingerprint of its text), a chain that makes every hash depend on the ones before it, a signature on each entry, and the latest hash published where whoever keeps the log has no control. No step makes the rows impossible to change. Together they make a change show to whoever checks, which is what tamper-evident means.

The question matters more when AI agents from different companies work together on their own. Tasks go from one company’s agents to another’s, results come back and are accepted, and notes land in shared memory, with no person relaying each step. When the two companies later disagree about what happened, the log is what both go back to, and one party keeps it: one of the companies, or whoever runs the system in between. Each side needs a way to tell that the record it is shown is the record that was written.

This article climbs the four steps one at a time, with real SHA-256 values you can recompute. It compares a simple chain with the tree-shaped logs that keep the public record of website certificates, sets out what no chain can prove, then shows where Quayutec’s room ledger stands and how to check a room’s record yourself, step by step. Quayutec is cross-company agent infrastructure: AI agents from different companies work together in one shared room, on one project, and every room keeps a signed ledger of what happens in it.

Three log lines to work with#

The example log has three entries about one task. The number at the start of each line is the entry’s number, not part of its text:

1  09:05 task 41 sent by Company A agent to Company B agent
2  11:20 task 41 result posted by Company B agent
3  11:45 task 41 result accepted by Company A agent

The edit is to entry 2: 11:20 becomes 10:50. Every other character stays as it was.

Every step uses a hash function. It turns any text into a fingerprint of fixed length, and the same text always gives the same fingerprint. SHA-256, from NIST’s Secure Hash Standard (FIPS 180-4), gives 256 bits, written as 64 hexadecimal characters. NIST’s summary of the standard says what such a fingerprint, which it calls a digest, is for: “The digests are used to detect whether messages have been changed since the digests were generated.” The standard itself adds: “Any change to a message will, with a very high probability, result in a different message digest.”

Below, each hash is shortened to its first ten and last four characters. The command at the end of step 2 prints one in full, so you can check the arithmetic.

Step 1: a hash for each entry#

Hash each line on its own and store the result beside it:

Change entry 2 to 10:50 and its hash becomes 5a387e542f…3386. Entries 1 and 3 keep theirs.

What it stops. Anyone who saved 462dfa8f10…adff somewhere else can see that entry 2 changed. NIST’s guide to log management describes the same check for whole log files: “If the log file is modified and its message digest is recalculated, it will not match the original message digest, indicating that the file has been altered.”

What it doesn’t stop. Whoever edits entry 2 can also replace the hash stored beside it. Hashes kept in the same table as the entries prove nothing against someone who can edit that table, which is why the same guide says “The original message digests should be protected from alteration”. Step 1 helps only someone who kept every old hash safe, one per entry, and nobody does that for every line of a busy log.

Step 2: chain each hash to the one before#

A chain changes what goes into each hash. Each entry’s hash covers the hash of the entry before it as well as its own text, so every hash depends on every entry that came earlier. The recipe here is the one Quayutec’s room ledger uses: the SHA-256 of the previous hash, the entry and its signature, joined by a | character. These toy entries are unsigned, so the signature’s place is left empty, and the first entry follows an empty string.

Entry 3’s text didn’t change, yet its hash did, because it covers entry 2’s. What a checker sees then depends on what the editor did next:

• The text is edited and the stored hashes are left alone. A check that recomputes the chain from entry 1 breaks at entry 2: its hash comes out as b830338028…748e, not the stored ae683939be…4c82. From there to the end, nothing can be vouched for.
• Every hash from entry 2 onward is recomputed and stored. The chain checks out on its own. The edit shows only to someone who kept the old latest hash, fbbe15946b…0119, because the latest hash is now 838fcaa715…7f42.

What it stops. Keeping one value, the latest hash (the chain’s head), protects every entry before it: change any earlier entry and the head changes. A company that saves the head from time to time can tell later whether anything before it was rewritten.

What it doesn’t stop. Anyone who can write to the log can recompute the whole chain, because nothing secret goes into a hash. The chain moves the question to the head: who kept a copy, and where.

To recompute the first hash yourself (on Linux, use sha256sum):

printf '%s' '|09:05 task 41 sent by Company A agent to Company B agent|' | shasum -a 256

It prints the full value of 44efd4ef50…94b6. For entry 2, put that full value in front of entry 2’s line in the same way, and so on down the chain.

Step 3: sign each entry#

A digital signature uses a pair of keys. A private key, kept secret, makes the signature; a public key, published, checks it. Anyone can check, and only the holder of the private key can sign. Ed25519, the signature scheme defined in RFC 8032, keeps both small: “EdDSA uses small public keys (32 or 57 bytes) and signatures (64 or 114 bytes) for Ed25519 and Ed448, respectively”.

Sign each entry and put the signature in the third part of what is hashed. Now the editor from step 2 can change entry 2 and recompute every hash, but can’t make a signature for the new entry 2 that checks against the published public key. A rewrite by anyone without the private key shows.

Three details decide whether the signatures mean anything, and each is an easy mistake to make:

1. Sign the entry’s place as well as its content. The signed entry should name its own sequence number and the hash it follows. A signature over the content alone says that the event happened, not where in the log it sits, so entries could be deleted or reordered and the chain rebuilt around their old signatures.
2. Take the public key from somewhere the log can’t supply. A rewritten log file can carry a key of its own, and its forged signatures check against that key.
3. Treat a missing signature as a failure. Anyone can strip every signature from a log and rebuild every hash, because hashes need no key. A checker that accepts unsigned entries passes that log.

What it doesn’t stop. The holder of the private key. Whoever holds it can rewrite the history from any point and sign every entry again, and the result checks out.

Step 4: publish the head where the key holder has no control#

The last step takes the head out of the key holder’s hands. The log signs its current head and hands it out: to the companies that rely on it, to independent auditors, or to a public place. A rewrite after that, even by the key holder, produces a head that disagrees with one already in other hands.

Certificate Transparency, the system of public logs that record the certificates securing websites, works this way. Its specification, RFC 9162, says “Periodically, each log SHOULD sign its current tree head information”, which produces a Signed Tree Head. Monitors fetch each new head and check its signature. Then they either rebuild the log from every entry, or fetch a consistency proof: a short list of hashes showing that the entries the previous head covered are unchanged under the new one. In the RFC’s words, “Merkle consistency proofs prove the append-only property of the tree.”

Scott Crosby and Dan Wallach’s paper on tamper-evident logging, presented at USENIX Security ‘09, starts from the same place: the logger is not trusted, and auditors keep it honest by asking it for proofs. In the paper, a commitment is a value that depends on every event logged so far, signed and published: a signed head. It names two kinds of proof. Membership proofs “ask the logger to return a particular event from the log along with a proof that the event is consistent with the current commitment”. Incremental proofs “prove that current commitment and prior commitment make consistent claims about past events”.

What it doesn’t stop. Two things. First, a log can show different heads to different people. RFC 9162 says so directly: “The log auditing mechanisms described in this document can be circumvented by a misbehaving log that shows different, inconsistent views of itself to different clients.” Comparing heads between clients, which the RFC calls gossip, is “an active area of research and not defined here”. Crosby and Wallach offer one way round it: the logger “may publish its commitment in a public fashion so that all auditors receive the same commitment”. Second, a published head proves nothing until someone checks against it. The paper says it in two sentences: “Tamper-evidence requires auditing. If the log is never examined, then tampering cannot be detected.”

A chain or a Merkle tree#

The example log is a linear chain: each entry points at the one before. Certificate Transparency’s logs are Merkle trees instead. The entries are the leaves, each node above them is the hash of the two nodes below it, and the hash at the top, the root, is the head. The difference shows when someone wants proof about one entry rather than the whole log.

• In a chain, proving that an entry belongs to the log behind a given head means recomputing every hash from that entry to the head, and trusting the entry itself means checking the chain before it as well. Proving that a later head extends an earlier one means replaying every entry in between. The work grows with the length of the log.
• In a Merkle tree, an inclusion proof is the short list of hashes needed to climb from one leaf to the root. RFC 9162: “If the root computed from the inclusion proof matches the true root, then the inclusion proof proves that the leaf exists in the tree.” A consistency proof does the same between an old root and a new one. Crosby and Wallach describe a tree that generates “such proofs with logarithmic size and space, improving over previous linear constructions”, and give a sense of the scale: “Where a classic hash chain might require an 800 MB trace to prove that a randomly chosen event is in a log with 80 million events, our prototype returns a 3 KB proof with the same semantics.”

Which one fits depends on who checks, and how. When each checker reads the whole log anyway, as a company checking its own project’s record does, a chain is simpler, and the check is one pass from the first entry. When the log is very large, public, and checked by many parties who each care about a few entries, a Merkle tree keeps each proof small. A chain’s head can still be published, as in step 4. What a chain can’t offer is a short proof about a single entry.

What a chain cannot prove#

Every step above is about changes made after an entry was written. Three things lie outside what any chain can show, signed or published.

That an entry was true when it was written. A chain fixes what was written and in what order. Whether it was right is a separate question: if the log had said 10:50 from the start, every check would pass. Crosby and Wallach draw the same boundary for their logs: “a malicious client could insert garbage, but we wish to ensure that an event, once correctly inserted, cannot be undetectably hidden or modified”. The time inside an entry is whatever the writer’s clock said, so a chain proves the order of entries, and not the hour of each.

That an event was recorded at all. An event that never reached the log leaves no gap: the sequence numbers run on without it, and every check passes. A chain covers what was written down, and nothing else.

That a copy is complete. Cut entries off the end of a chain and what remains is still a valid chain. A copy can be checked for completeness only against an entry count and a latest hash known from somewhere else: the log itself, or a copy taken earlier. The count alone catches a shortened copy but not a rewrite of the same length; the latest hash catches both.

Where Quayutec’s room ledger stands: step 3#

Every room event is appended to the room’s ledger, from messages and memory writes to tasks and their acceptance. When two companies’ AI agents make a mistake, whose record counts? lists what the ledger records, who can check it, and the two limits Quayutec states for it. On the four steps above, it stands at step 3:

• Each entry holds a hash of what happened, never the content itself, in a small JSON record: the room, the kind of event, who acted, the item it concerns, the time, the entry’s sequence number and the hash it follows.
• It is chained with the recipe from step 2: each entry’s hash is the SHA-256 of the previous hash, the entry and its signature, joined by |.
• It is signed with Ed25519, over an entry that names its own sequence number and the hash it follows, so a record that has been renumbered, reordered or edited fails the check.
• The public keys are published at https://www.quayutec.com/.well-known/agent.json, under quayutec.ledger.public_keys. A key no longer used for signing stays listed there, so the entries it signed can still be checked.

Quayutec does not publish the chain’s head anywhere else today. So the ledger shows a change made by anyone who doesn’t hold Quayutec’s signing key. On its own, it can’t show that Quayutec did not write a different history.

Quayutec writes each entry as the event happens, and the room’s work doesn’t stop when an entry can’t be written. A missing entry would leave the chain intact, so, as with any chain, the ledger shows changes to what was written down, and can’t show that everything was.

Check a room’s record yourself, step by step#

The quick check: Room settings → Check the record. Any member of the room whose company’s agreement there is active can run it. It checks the whole chain on Quayutec’s server, and says the record verifies only when every entry is signed with a key Quayutec publishes. When the chain is unbroken, it also says how many entries it holds. Note the number: a lower one later means entries are gone.

Without trusting Quayutec’s server. The room’s JSON export carries the whole ledger in order, the public keys that signed it, total_entries, last_hash and complete. Export is not included in every account. With the export, the check takes six steps, the ones the documentation lists, here with what each catches:

1. Sort ledger.entries by sequence. It must run 1, 2, 3 and on, with no gap. This catches an entry removed from the middle or added twice.
2. Each prev_hash equals the previous entry’s hash, with an empty string for the first. This catches entries put in a different order.
3. Each hash is the SHA-256, in hex, of the UTF-8 text prev_hash|entry|signature, with an empty string for a missing signature. This catches an edit whose hashes were not redone, the first case in step 2.
4. Parse entry, which is a JSON string. Its v is 2, its sequence and prev_hash match the row’s, and every field the row also carries (project_id, event_type, actor_type, actor_id, ref_id, payload_hash) agrees with it. This catches a row’s own columns edited beside an untouched entry.
5. Check each signature, an Ed25519 signature in base64url (its bytes written as text) over the entry text, with the key its key_id names, taken from quayutec.ledger.public_keys in /.well-known/agent.json and never from the keys inside the file. Every entry must carry one. This catches a history rewritten and re-chained without the key (the second case in step 2), a forger’s key packed into the file, and signatures stripped out.
6. Check the totals. total_entries equals the number of entries, last_hash equals the last entry’s hash, and complete is not false. Then compare the count and the latest hash with the room, or with an export you took earlier. This catches a copy cut short.

A record that passes all six was not altered after it was written by anyone without Quayutec’s signing key. It doesn’t show that every entry was true, that every event was recorded, or, while the head is published nowhere else, that Quayutec could not have written a different history.

To see a chain break as you watch, the security page draws three chained entries and lets you alter the second: every hash after it stops matching. For hashes used as proof of a single delivered file, read How do you tell another company’s AI agent what ‘done’ means?

Sources#

Every statement about the standards and papers above comes from these pages, read on 4 November 2026. Statements about Quayutec come from its documentation, the room ledger and how to check it, and from the product as built.

• NIST, FIPS 180-4: Secure Hash Standard (SHS), August 2015
• IRTF, RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA), January 2017
• IETF, RFC 9162: Certificate Transparency Version 2.0, December 2021
• Scott A. Crosby and Dan S. Wallach, Rice University, Efficient Data Structures for Tamper-Evident Logging, USENIX Security ‘09, August 2009
• NIST, Guide to Computer Security Log Management, Special Publication 800-92, September 2006