Payload-free, tamper-evident audit/drop-log design

DEC-0059's Layer-3 compensating control. Because detection has irreducible false negatives, the boundary must keep a tamper-evident audit trail that proves nothing sensitive landed — but the trail must record decisions (per-item verdict + sensitivity-label snapshot + drop reason), never the sensitive payload.

The audit paradox

A payload-bearing audit log is the breach. So the discipline is to scrub before anything reaches a logged layer — a logging regression must be physically unable to capture raw PII. This is the same payload-free principle Dumb-fast trace capture + off-hot-path distill/prune applies to the trace tier (capture the decision/metadata, not the sensitive content), now applied to the sensitive-data drop log. Make it tamper-evident (append-only / hash-chained) so the proof-of-non-landing is trustworthy.

The LiteLLM nuance to watch

If LiteLLM sits in the model path, set turn_off_message_logging — but it has a documented history of leaking messages into the Postgres proxy_server_request field anyway, which is exactly why scrubbing must happen at ingestion before any logged layer rather than depending on a downstream flag.

Why a task, not a fix-in-place

A real design + build (log schema, scrub-before-log ordering, tamper-evidence) with a demonstration that a dropped item's payload is never written — owner judgment + code. Detail + citations: research/2026-06-18-sensitive-data-and-injection-defense.md §6 and §10. confidence: inferred (agent-filed from DEC-0059).