Every guardrail this course has built so far assumes the agent legitimately holds some sensitive data and asks how to stop it leaving through the wrong door. This lesson asks a question one step earlier: does the agent need to hold that data at all? A support agent that never receives a customer's full card number cannot leak it, cannot mis-scope a tool around it, and cannot have a redaction filter fail to catch it — because it was never in the context window to begin with. Minimisation, not detection, is the primary control this lesson teaches, and redaction is what you fall back to only for the data you genuinely could not avoid collecting.
Teams routinely get this order backwards: they pipe an entire customer record — name, address, card details, date of birth — into an agent's context because it was convenient to fetch the whole record in one API call, and then bolt on a regex-based redaction filter to catch anything sensitive before it reaches the model's output. This treats a data-minimisation problem as a data-loss-prevention problem, and it inherits every weakness a filter has: it can only catch patterns it was built to recognise, it runs after the data is already in the context the model reasons over, and a single missed pattern is a real leak, not a near miss.
This lesson is explicit about a limit: no detector's accuracy is quoted here as a number, because published accuracy figures vary enormously by data type, language, and format, and quoting one figure as if it generalises would be exactly the kind of invented statistic this course does not traffic in. What follows instead is the actual design discipline — minimise first, redact what remains, and never treat redaction alone as sufficient.