The Sanitation Layer

The problem

Every agent in this body of work runs on top of a design rule I built in from the start: an agent should never have raw customer PII in its context window, full stop. Not because the model cannot be trusted with it, but because the data an agent can see should be the smallest thing that still lets it do the job. That discipline is what makes it safe to persist an investigation’s output, hand it to another tool, or paste a clean summary into a doc without a second round of review.

Layer 1 — Sanitize before the agent ever sees it

• Customer ID, name, phone, and transaction IDs are replaced with a deterministic SHA-256 hash or a derived fake name computed from the real ID. Same customer, same fake identity, in every file, on every run.
• Structural patterns are preserved on purpose: a bank account keeps its real last-4, a retried transaction keeps its real retry suffix, because the reconciliation logic needs those patterns to detect real bugs.
• Every financial column, date, status, and reason code passes through untouched. The checks compute the identical real answer on sanitized data as they would on raw data.

Layer 2 — Credentials never touch the agent directly

• Database access goes through a container with credentials pre-mounted, never an ad-hoc driver or a credential sitting in the agent’s own session.
• Every query runs through an audit-logged wrapper that records a SQL hash and row count, and explicitly never logs parameter values.

Layer 3 — Verify the purge, do not assume it

• Daily backups run a two-pass secrets gate, validated by deliberately planting dummy credentials and confirming both passes caught them before ever trusting the system with real ones.
• A real PII purge needed three successive grep passes before it returned zero hits. "Clean" is treated as a claim to verify, not a status to assume.

Stack

Python (hashlib / SHA-256, csv), Docker (containerized DB access and an audit-logged query wrapper), git (two-pass secrets gate).