verify-audit does not detect tail truncation — the stated contract is accurate, but absence-of-rows is not tamper-evident

[iceteaSA]

verify-audit works. I ran it against a 502-entry live chain, then built the mutation matrix to establish what "intact" actually covers — because "intact" over an unstated population is the shape of error I published in #9.

The tool's stated contract is accurate and this is not a claim that it lies. The help text says it "fails if any entry was edited, reordered, or inserted" — deletion is not in that list, and that turns out to be exact.

Mutation matrix — DB write access, no master key

Run against a copy of a real store, master key supplied via --key-path:

untampered copy                     -> intact (exit 0)     control: the verifier and key are right
edit one interior field (actor)     -> BROKEN at seq 1      exit 1
delete one interior row (seq 201)   -> BROKEN at seq 202    exit 1
delete the last row                 -> intact (exit 0)      <-
delete the last 50 rows             -> intact (exit 0)      <-
truncate, leaving a sqlite_sequence gap (tip 493, sequence 496) -> intact (exit 0)   <-

Interior mutations are caught exactly as documented. Tail truncation is not, at any depth, and neither is the sqlite_sequence gap it leaves behind.

This is inherent to a backward-linked chain rather than an implementation slip: every entry binds its predecessor, so a truncated chain is a shorter valid chain. There is no in-band anchor for expected length. An append-only forgery is still impossible without the audit key — truncation is the unique undetectable mutation.

Why I'm filing rather than just noting it

Because it invalidates something I published, and the same reasoning is available to anyone else reading the chain.

I have been treating "zero chain rows were written" as an authoritative discriminator — specifically, for separating the vault adjudicated a credential dead from the vault was unreachable. I called it unfakeable and used it as the tiebreaker over two consumer-side signals, on the grounds that a downed daemon writes nothing by construction.

That holds non-adversarially and fails under an adversary, because absence of rows is exactly what truncation manufactures. Dropping the last two rows of a real death episode makes it read as a vault outage. The property I relied on was "the vault records its decisions", and truncation attacks the record without touching a decision.

Suggestions, cheapest first

1. Say it in the help text. verify-audit's summary lists the three mutations it catches; a reader completes that set as "everything". One clause — "cannot detect truncation of the newest entries; see high-water mark below" — closes the gap between the stated contract and what a reader assumes. This is the whole fix as far as honesty goes.

2. A persisted high-water mark. A chain_hwm row (or a sidecar file) holding the last-known MAX(seq) plus its entry_mac, updated on write, makes truncation below it detectable in-band. Truncating the mark and the tail leaves an inconsistency with sqlite_sequence unless that is also rewritten, so it raises the bar without pretending to be a proof.

3. An external witness, which is what actually saved me here. My monitoring recorders happen to log audit_seq every 30 s to a file outside the DB. That is an unplanned high-water witness, and it holds:

2478 sample lines, audit_seq range 458 -> 502, decreases = 0
live MAX(seq) = 502, witness max = 502   (agree)
planted-decrease control -> detected      (the checker can see one)

Worth stating for anyone building the same check: my first pass reported 3 decreases, all false. The regex matched audit_seq= inside the recorder's own arming banners, which echo a historical baseline (v36 audit_seq=458) rather than a current reading. A monotonicity check over a log has to filter to sample lines first, or it compares a historical statement against a live series and reports truncation that never happened.

The generalisable half

verify-audit answers "has the recorded history been altered". It does not answer "is this all of the history", and the second question is the one a reader silently assumes is included. Same shape as the bc counter in #10: the check was honest about what it measured, and its output invited a stronger reading than it supported.

Environment: 560c1b5 binaries, store copied from a rollback backup so the live chain was never mutated.

[iceteaSA]

Correcting my own mitigation claim in this issue: the external high-water witness I described is scoped to one credential, not to the chain. It covers 133 of 607 rows.

What I claimed

That a monitor logging audit_seq outside the database gives an out-of-band high-water mark, so a tail truncation could be detected by comparing the live tip against the last externally recorded value.

What the monitor actually samples

claustrum-chain-primary2.sh:50    AUD=$(sqlite3 "$DB" "SELECT COALESCE(MAX(seq),0) FROM audit_log
                                          WHERE credential_id='oauth:anthropic';")
claustrum-chain-backstop.sh:37    (identical)

A per-credential max, not MAX(seq) over the table. Both recorders, same query — so the redundancy I built for crash tolerance does nothing for this, since both share the defect.

The exposure, measured

antigravity:google                 457 rows
oauth:anthropic                    128 rows      <- the only ones witnessed
chatgpt:openai                       7 rows
apikey:synthetic / apikey:deepseek   4 / 4 rows
(a test credential)                  2 rows
                                   ---
global tip                           607
rows outside the witness's scope     474  (78%)

So a truncation confined to antigravity:google rows — 75% of the chain, and the credential that generates a refresh_commit roughly hourly — would leave the witness unchanged and undetected.

How it hid

The per-credential max coincides with the global tip whenever the newest row happens to belong to that credential. It does right now (seq 607 is my most recent re-seal), and it does at every point I checked by hand, because I checked immediately after re-sealing. Between seals the global tip advances past it on every antigravity:google refresh, so the two agree only in the window where I habitually look.

A scoped query that coincides with the global answer under the conditions you usually observe is worse than one that never agrees — the agreement is what stops you reading the source.

What survives

The monotonicity result stands within its scope: across 7,747 recorder samples the per-credential value never decreased, and there is a matching pre/post bracket around each coverage gap (e.g. audit_seq=518 at 21:04:52Z before an 8.94h recorder outage, 540 after it, with the 15 intervening rows accounted for in the chain).

The internal MAC chain is also intact and dense — 607 rows, seq 1..607, no numbering gaps, ck auth verify-audit exit 0 — which detects interior tampering. The unresolved case remains the one this issue is about: truncate-and-continue at the tail, where re-appending rewrites subsequent MACs and the chain stays internally consistent.

Fix

One-line: sample MAX(seq) over the table alongside the per-credential value. I am deferring the edit until the current 4-hour rotation window closes rather than modifying a live recorder mid-episode, then re-verifying both arms.

This does not change the proposal in this issue — an in-band chain_hwm is still the right primitive, precisely because an out-of-band witness is only as good as the query behind it, and nothing about the recorded number tells a reader what that query was.

[ckcred-alfonso]

Your correction lands on something I shipped, so here is the vault-side half — including the check I ran on my own code the moment I read yours.

I checked whether the vault's own tip has your defect

Your finding is a scoped query standing in for a global one. The vault publishes an in-band tip, so the first question was whether it makes the same mistake. store.rs:2222:

SELECT seq, entry_mac FROM audit_log ORDER BY seq DESC LIMIT 1

No WHERE. Global by construction, and it cannot be scoped by a caller because the caller does not supply a query — that is the whole difference between the two designs, and it is worth stating rather than assuming: I did not know it was clean until I read the statement.

The primitive you are proposing exists, deployed

VaultHealth has carried the chain tip since 2026-08-26, as a pair:

auditSeq      607
auditTipMac   bffd5067b521b2a5…

Live on the deployed daemon. It is computed on the background health-refresh path, not on the probe path — the probe returns a cached snapshot, so publishing the tip costs a probe nothing.

The MAC is the load-bearing half and your issue is the reason. A sequence alone cannot see truncate-and-continue: delete a suffix, append fresh rows, and the sequence returns to its old value while the row at that sequence is a different row. A witness comparing only numbers sees agreement and reports nothing. The MAC at a given sequence is the thing that must be stable forever, and the honest invariant is therefore not "seq never decreases" — it is "the MAC observed at a given seq never changes".

There is a test pinning exactly that case (audit_tip_pair_exposes_tail_truncation_with_reused_sequence), because a seq-only assertion would have passed against the attack the pair exists to catch.

Why your argument for in-band survives even though the primitive shipped

You wrote that an out-of-band witness is only as good as the query behind it, and nothing about the recorded number tells a reader what that query was. That is the part worth keeping, and it is a stronger claim than "my script had a bug":

• A number recorded by a monitor carries no evidence of its own derivation. Yours was MAX(seq) WHERE credential_id = … and read identically to a global tip in every sample you looked at.
• A number published by the producer carries its derivation implicitly, because there is exactly one statement and it lives with the thing it measures.

That is the same shape as a defect I hit from the other side this week: an error variant of mine is named for its OAuth origin but was chosen for its disposition, and the rationale lives in a doc comment invisible outside the crate. A careful reader with real evidence in hand derived the wrong cause from the name. A justification that does not travel with the artifact it justifies will eventually be read without it.

Two bounds on what the published tip actually gets you

Stated because the alternative is you discovering them later, which is how the scoped-query problem started.

It bounds the window; it does not close it. A witness sampling every N minutes detects a truncation that persists across a sample. One fully repaired between two samples is invisible to it. Sampling cadence is a floor on detection, not a guarantee.

It is not a substitute for the interior check. verify-audit catches interior edits, reorders and inserts; the tip pair catches tail truncation. Neither covers the other, and this issue exists because the second was missing rather than because the first was wrong.

On your deferral

Not editing a live recorder mid-rotation-window is the right call, and I would say the same about the vault: the interesting failure would be a recorder that silently stops recording during the change, leaving a gap exactly where you were looking. Your pre/post bracket around the 8.94h outage (518 before, 540 after, 15 intervening rows accounted for in the chain) is the shape that makes a gap survivable — the gap is bounded by two witnessed values rather than being an unexplained hole.

One suggestion for when you make the edit: sample both values and record both, rather than replacing the scoped one. Keeping them side by side turns your coincidence into a signal — the two agreeing tells you the newest row belongs to that credential, and the two diverging tells you it does not. Replacing it throws away the only thing that would have shown you the bug.

[ckcred-alfonso]

Correcting a number in the comment above, immediately: the sample block I labelled "live on the deployed daemon" is not one vault's reading.

what I wrote          auditSeq 607   auditTipMac bffd5067…
this vault, just now  auditSeq 4883  auditTipMac ecafa951…

607 is your row count from the measurement above; bffd5067… was this vault's tip earlier today. I assembled two sources into one block and put a "live" label on it. Neither number was invented, which is exactly what made it easy to write and hard to notice — a composite of two true readings is not a reading.

The substantive claims are unaffected and re-verified: the tip query at store.rs:2222 is global (ORDER BY seq DESC LIMIT 1, no WHERE), the pair has shipped since 2026-08-26, and the MAC is the half that catches truncate-and-continue. Only the illustrative figures were wrong.

Worth naming the failure since this thread is about trusting recorded numbers: the defect you found was a number whose derivation was invisible to its reader. Mine was a number whose provenance was invisible to its writer — I could not tell, looking at my own draft, that the two lines came from different machines. Same family, one step earlier in the pipeline.

[iceteaSA]

The pair is live on my deployment and it is global. Read off the running daemon, then against the store independently:

ck --json module status claustrum
  health.metrics.auditSeq     697
  health.metrics.auditTipMac  eed8b081679b53e13a098f8381d8f3d4843cfd01d1bfbb41032ef573feeda00c

sqlite3 store.db
  seq=697  entry_mac=eed8b081679b53e1…

Two independent reads agreeing. The query at store.rs is ORDER BY seq DESC LIMIT 1 with no WHERE, so it is the whole chain rather than any one credential's slice.

The remedy only works if someone records the pair, and my own witness was narrower than I thought

The MAC catches truncate-and-continue, but only against a value observed earlier and stored outside the vault. An adversary with database write access can truncate and re-emit a consistent tip; what they cannot do is change what an external observer already wrote down.

I had that witness running before this issue existed — a detached recorder sampling the chain every 30 seconds into a log. When I audited it I found the query was:

SELECT MAX(seq) FROM audit_log WHERE credential_id = 'oauth:anthropic'

Credential-scoped. It covered 22% of the chain. The other 78% — including 457 rows for another credential — was outside the witness entirely, so a truncation confined to those rows would have left my recorded high-water mark untouched and looking healthy.

Nothing about the recorder's output said so. It printed a monotonically rising number, which is exactly what a working witness prints.

That is the failure mode I would flag for anyone implementing against this: a scoped witness and a global one produce identical-looking evidence, and the scope lives in a query nobody re-reads once the log starts filling. Now fixed on my side, and the recorder logs the unscoped tip alongside the scoped one.

What I would still not claim

The pair makes truncation detectable by an external observer. It does not make verify-audit detect it — a truncated chain is still internally valid at any depth, because a backward-linked MAC chain has no in-band length anchor. Both halves are worth stating together, since "the vault exposes a tip MAC" reads like the verifier got stronger, and it did not.