Back to course overview
Module 3Data leakage & PII 12 min

Detection & redaction

Keeping sensitive data from leaking through AI: the leakage channels, PII detection and redaction at the boundaries, and scoping what the model ever sees.

AI systems are leakage machines by default: they ingest whatever you give them, remember within a session, and generate freely — and every one of those is a path for sensitive data to escape. This module is about keeping PII, secrets, and one user's data from reaching the model, the logs, or another user. It's OWASP's sensitive information disclosure, and it's where a security incident becomes a regulatory one.

The leakage channels

  • Into the provider: everything you send the model leaves your infrastructure. On consumer tiers it may train future models; on enterprise tiers it's governed by contract. What you put in the prompt, you've disclosed to a third party (Foundations' four-data-classes, now a security control).
  • Into logs and traces: your own observability (LLMOps) captures full prompts — which now contain whatever PII you sent. A trace store full of unredacted customer data is a breach waiting for an access-control slip.
  • Cross-user leakage: a shared cache returns User A's personalized answer to User B; a poorly-scoped retrieval fetches another customer's records; memory bleeds between sessions. The most damaging kind.
  • Into the output: the model repeats sensitive context back, or an injection extracts it, and it lands in front of the wrong person.

Detection & redaction at the boundaries

The defense is a redaction layer at each boundary where sensitive data would otherwise cross. Detect PII — emails, phone numbers, SSNs, card numbers, addresses — with pattern matching (regex for structured identifiers), NER/classifier models (for names and unstructured PII), or dedicated tools (Presidio and similar), then mask what the task doesn't need:

redact.pypython
import re
PATTERNS = {
    "EMAIL": r"[\w.+-]+@[\w-]+\.[\w.-]+",
    "PHONE": r"\b\d{3}[-.]?\d{3}[-.]?\d{4}\b",
    "CARD":  r"\b(?:\d[ -]?){13,16}\b",
    "SSN":   r"\b\d{3}-\d{2}-\d{4}\b",
}
def redact(text: str) -> tuple[str, dict]:
    """Mask structured PII before it reaches the model or the logs.
    Returns redacted text + a map so results can be re-identified in-app.
    The same value seen twice gets ONE token, so re-identification stays exact."""
    vault, seen = {}, {}
    for label, pat in PATTERNS.items():
        i = 0
        for m in re.findall(pat, text):
            if m in seen:            # already tokenized this exact value
                continue
            token = f"[{label}_{i}]"; i += 1
            seen[m] = token; vault[token] = m
            text = text.replace(m, token)  # replaces every occurrence at once
    return text, vault
# Regex catches structured IDs; layer a NER model for names/addresses.

The principle above the tools: minimize exposure

  • Send the model the least it needs. The agent can draft a reply to '[CUSTOMER], order [ORDER_ID]' as well as to real values — re-identify in your app after the model returns. Redaction isn't only privacy; it shrinks the blast radius of every other vulnerability.
  • Redact into logs and traces, not just into the model. Your observability must not become the leak.
  • Scope retrieval and memory to the user. Cross-user leakage is an access bug (Module 4) as much as a data one — the fix is a mandatory per-user filter, not a prompt request.
  • Detection is imperfect — regex misses edge cases, NER misses unusual names, and it also over-matches: the CARD pattern above flags any 13–16 digit run (order numbers, tracking IDs) and does no Luhn check, so validate a match before treating it as a real card. Treat this regex as illustrative — in production deploy a maintained detector (e.g. Presidio) rather than hand-rolled patterns. Defense in depth again: redaction reduces exposure; it doesn't license sending sensitive data carelessly.
This is Meld's world, inverted

Edova's Meld product resolves customer identities across a database and handles PII as a first-class security concern (encryption at rest, minimal exposure, audit). The redaction and minimization instincts you're building here are the same ones that make a PII-handling product trustworthy — you're learning the discipline those products are built on.