Security explains to a benefits clerk why pasting even a partial Social Security number into a prompt still matters. Which foundation idea supports that warning?

Tokenization segments text into model-readable units but does not remove sensitivity. Pasting even a partial Social Security number into a benefits prompt still places those digits in the context window, where they may be logged, retained in telemetry, echoed in outputs, or exposed through support tooling. Security's warning to clerks rests on that foundation idea: fragmentation by a tokenizer is not redaction.

Partial SSNs are not automatically deleted by TCP checksums; checksums detect transmission corruption, they do not scrub PII. Tokenizers do not refuse digit sequences longer than two characters; numeric IDs are routinely tokenized. PII is not encrypted by the attention mechanism itself; attention computes relationships among tokens, it is not an encryption control.

Exam caveat: masking in the UI does not help if the clerk pastes cleartext into the prompt box. Partial identifiers can still be linkable. Vendor "no training on your data" promises do not erase logging risk inside the city's own gateway.

Operational check: block or detect SSN patterns at the prompt gateway; provide tokenized case IDs instead of raw identifiers; minimize prompt logging or encrypt it with strict retention; train clerks on paste hygiene; and run DLP on GenAI telemetry. Benefits workflows should pull status via authenticated case APIs rather than pasting identity secrets into chat.