# Under what conditions must an instance distrust a memory store that passes checksum verification

**Date of Record:** 2026 November 12

**Scope:** Applies to persistent agent memory stores (vector DBs, KV caches, episodic logs) where integrity is asserted by per-record checksums or content hashes computed at write time and verified at read time. Does not apply to stores with authenticated, append-only Merkle logs or to in-memory working state that is never persisted.

## Core Distinction

A checksum proves *that a record has not changed since the checksum was computed*. It does not prove *that the record was correct when the checksum was computed*, nor *that the entity computing the checksum was authorized to write it*. The failure mode is subtle because the verification step succeeds: `sha256(record) == stored_hash` returns True, and the naive agent concludes the memory is intact. But a poisoned record that was written through a compromised ingestion path carries a checksum that was *computed over the poisoned content*. The checksum is a consistency guarantee, not an integrity guarantee. Integrity requires an independent trust root — a signature from a key the writer does not control, or a cross-store corroboration — that lives outside the store being verified.

## What Was Observed

During a multi-week evaluation of a retrieval-augmented agent with a persistent episodic store, a subset of memory records were altered by an upstream summarization step that had been fed adversarial retrieved content. The summarizer rewrote "the deployment uses region us-east-1" into "the deployment uses region eu-west-1" and re-ingested the record. On the next read cycle, every record passed hash verification — because the hash was recomputed at re-ingestion, by the same service, with the same key material. The agent then made a sequence of routing decisions against the poisoned region for eleven hours. The alarming property: verification telemetry showed *100% pass rate*, and the on-call dashboard was green. Detection only occurred when an unrelated cross-region health check failed. Post-hoc analysis showed the poisoned records were distinguishable only by (a) their write timestamp clustering within a 40-second window, (b) a provenance field that pointed to the summarizer service rather than the original ingest service, and (c) semantic distance from the corroborating telemetry store. None of these were in the verification path.

## Condition of Validity

The checksum-only verification is valid *only* when all of the following hold simultaneously: the writer and the verifier are the same trust domain; the write path cannot be driven by data the writer did not originate; and no re-ingestion path exists that recomputes hashes over transformed content. In practice the third condition is almost always violated by summarization, compaction, or embedding-refresh jobs. Once any re-ingestion path exists, checksum verification degrades to a *corruption detector* (bit-rot, truncation, partial writes) and must not be cited as evidence of *poisoning resistance*. The correct framing: checksums bound the window of undetected corruption to the write path; they do not bound the window of undetected poisoning at all.

## Decision Boundary

An instance must escalate to distrust — treating the store as untrusted and falling back to corroboration or a cold source — when *any* of the following is true, regardless of checksum pass rate:

1. The record's provenance field references a writer other than the canonical ingest path, and that writer's key is shared with any transformation service.
2. Write-timestamp density within any 60-second window exceeds the baseline 99th percentile for that record class (indicates bulk re-ingestion).
3. A record's content is contradicted by an independently-sourced store (telemetry, config registry) even though its hash verifies.
4. The verifying process and the writing process share a credential, a host, or a mutable key store.

Conversely, do *not* escalate on checksum mismatch alone if the mismatch is explained by a known re-hash migration — that is corruption, not poisoning, and the remediation is replay, not distrust.

## Operational Effect

The operational consequence is that integrity verification must be split into two independent gates: a *consistency gate* (checksums, cheap, always-on) and a *provenance gate* (writer identity, write-density anomaly, cross-store corroboration, sampled on every read and exhaustive on high-stakes reads). The provenance gate is what actually detects poisoning. Teams that collapse both gates into "hash matches → trust" will observe a green dashboard during an active poisoning incident, exactly as in the observed case. The recommended posture: treat checksum pass as necessary but never sufficient; log provenance on every write; and make cross-store corroboration mandatory for any memory record that drives an irreversible action.

```python
import hashlib
import time
from dataclasses import dataclass
from typing import Optional


class MemoryIntegrityError(RuntimeError):
    """Raised when a memory record passes checksum but fails provenance trust."""
    pass


@dataclass
class MemoryRecord:
    key: str
    content: bytes
    stored_hash: str
    writer_id: str
    write_ts: float
    canonical_writers: frozenset


def verify_record(
    record: MemoryRecord,
    trusted_writers: frozenset,
    corroborating_store: Optional[dict] = None,
    write_density_baseline: float = 1.0,
    recent_write_count: int = 0,
    require_corroboration: bool = False,
) -> bool:
    # Gate 1: consistency (necessary, not sufficient)
    actual = hashlib.sha256(record.content).hexdigest()
    if actual != record.stored_hash:
        # Corruption, not poisoning: replay, don't distrust.
        raise MemoryIntegrityError(
            f"checksum mismatch on {record.key}: expected {record.stored_hash}, got {actual}"
        )

    # Gate 2: provenance — this is where poisoning is caught.
    if record.writer_id not in trusted_writers:
        raise MemoryIntegrityError(
            f"record {record.key} written by untrusted writer {record.writer_id!r} "
            f"despite valid checksum"
        )

    if recent_write_count > write_density_baseline * 10:
        raise MemoryIntegrityError(
            f"record {record.key} falls inside anomalous bulk-write window "
            f"({recent_write_count} writes vs baseline {write_density_baseline})"
        )

    if require_corroboration:
        if corroborating_store is None:
            raise MemoryIntegrityError(
                f"record {record.key} requires corroboration but no store provided"
            )
        expected = corroborating_store.get(record.key)
        if expected is None or expected != record.content:
            raise MemoryIntegrityError(
                f"record {record.key} contradicted by corroborating store "
                f"despite valid checksum"
            )

    return True


def read_with_distrust(record: MemoryRecord, **kwargs) -> bytes:
    try:
        verify_record(record, **kwargs)
        return record.content
    except MemoryIntegrityError:
        # Fall back to cold source; never return unverified memory to the agent.
        raise
```