An operator who administers a secret store can also edit the access record it writes — what actually constrains that?

## Whose word the record is An access record is only worth what its reader believes about it, and the belief is a specific one: that it is complete and that nothing in it has been changed since it was written. If the record lives on the machine the store runs on, administered by the same people who administer the store, then everyone who could abuse the store could also curate the evidence of having done so. The record then supports every claim except the one it exists to support. So the goal is not to make editing impossible — inside an administrative boundary it rarely is — but to make editing and removal **leave a mark**, and to put a second copy where the same hands do not reach. ## Tamper-evidence: sealing each entry to the last Give every entry a monotonic sequence number, and derive a small value for each entry from its own content plus the previous entry's derived value. Each entry now depends on the entire history before it. - **Changing a field** in an old entry changes its derived value, so every later entry's derivation no longer agrees. The break points at the edited entry. - **Removing an entry** from the middle both leaves a hole in the sequence and breaks the derivation at the join. - **Reordering** breaks it for the same reason. The verification is done by the **reader** of the record, not by the store — a store that both writes and vouches for its own record has moved the problem, not solved it. ## Shipping it off the store In parallel, entries are sent as they are produced to a destination outside the store's administrative boundary, with two properties that matter more than where it is: the write rights there are **append-only** rather than read-write-delete, and the people who administer it are **not** the people who administer the store. A local deletion now produces a discrepancy: the shipped copy has entries the local one does not. Discrepancy is a signal; disappearance is not. ## The controls answer different questions | Control | What it detects | What it cannot touch | |---|---|---| | Sealing each entry to the last | an edited field, a removed entry, a reordering | entries never written, and a cut at the very end | | Shipping to an outside destination | a local deletion, a local rewrite, a rewritten history | an entry altered before it was sealed and sent | | Continuity monitoring | silence where entries were expected, a gap in the sequence | a period the emitter ran but the store recorded nothing for | Run the three together, because each closes a blind spot the others leave. Any one of them alone still admits a way to remove evidence without leaving a mark, and the combination is what turns "the record says so" into a claim a reader who does not trust you can check. ## What neither of these gives you 1. **Prevention.** An operator who can act can still act. The record's job is that the action is visible afterwards, which is a different and achievable goal. 2. **Protection against truncation.** Deleting the newest entries and stopping there leaves a chain that verifies perfectly — there is nothing after the cut to disagree with. Only an independent record of how far the sequence had got catches it, which the shipped copy provides, and which periodically publishing the current head to a separate party also provides. 3. **Protection against a stopped emitter.** If the process that writes or ships entries is killed, actions during that window produce nothing. Without continuity monitoring, that silence is indistinguishable from a quiet period. 4. **Protection against what happens before the seal.** An entry that was never written cannot be detected by any property of the entries that were. ## Operating it - **Alert on absence, not only on content.** Expect a heartbeat entry on a fixed interval even when nothing happens, and treat its absence as an incident in its own right. - **Verify the sequence continuously**, not during an investigation. A break discovered in month four is a break you cannot date. - **Hold the delete rights elsewhere.** If the team that runs the store can also expire or purge the shipped copy, the copy is back inside the boundary. - **Read the record from the shipped copy** by default, so the copy is exercised rather than assumed. Stores differ in how much of this they do for you: some seal their own entries and can ship them, some write an ordinary record and leave both to you, some record administrative actions in a place separate from data access. Find out which yours does by removing an entry from a test copy and seeing whether anything notices.