ingest-scrubbinglisted

# Ingest Scrubbing Companion to [[prompt-injection-defense]]. That skill hardens the runtime request path (a user's message, a tool's result). This one hardens the write path: anything that gets embedded and stored so a *future, unrelated* query can retrieve it. ## Why this is a distinct problem Indirect prompt injection via a poisoned corpus is worse than a poisoned chat message in one specific way: the attacker doesn't need to be the one asking the question. They plant instructions in a PDF, a scraped web page, an uploaded spreadsheet — anything that ends up in the knowledge base — and wait. Weeks later, someone else's innocent query retrieves that chunk and the injected instructions ride along into that person's LLM context. This was the gap found auditing a reference RAG codebase (rag-supreme, mid-2026): ingestion did file-type sniffing and text extraction, but the only "cleaning" step was `.strip()`. Retrieved chunks went into the prompt verbatim, with no scrub at write time and no re-check at read time. ## Where to scrub Two checkpoints, not one: 1. **At ingestion** (before embedding/indexing) — this skill. 2. **At retrieval** (before the retrieved chunk enters a prompt) — reuse [[prompt-injection-defense]]'s baseline (`sanitize_untrusted_text`, `flag_injection_attempt`) on every retrieved chunk. Retrieval is just another untrusted-text-into-prompt path. Scrubbing only at ingestion misses new attack patterns discovered after a document was already index