History is privacy-sensitive data

What it is

Prompts will contain customer names, unreleased revenue, medical record numbers, code not yet committed. If history is treated as ordinary “recently used” — synced, shared, fed back into training — those contents leave the boundary of the original task. Prompt history as sensitive data treats the stream, saved reusable objects, even “harmless weekly prompts” as sensitive by default: who can see, where it lives, when it dies, whether it enters training, all have to be explicit decisions, not a shrug of “it’s just my own chat log.”

Save and textbook-use both add copies. Sensitivity is not an argument against those capabilities. It is that once they open, the fate of the copies has to be designed, not happen as a side effect.

Why it happens

Open input has no field-level sensitivity mark. People will not tick “this sentence has personal data” in front of every line. The sensitivity of the whole history is therefore pulled up to the most sensitive sentence — weather chat and a draft employment contract share one log, and permission can only be granted to the lump. Sync to many devices, an enterprise admin looking, support debugging, model improvement: every reasonable-looking downstream copies that mixed log.

Surface anonymization fails too. Strip the name and you can still invert to a person via a project nickname, a stack trace, a unique weekly structure. Citations inside generated artifacts rewrite secrets from the prompt; deleting the prompt and not the artifact is not deleting. Shared screens and projectors turn “history only I can see” into third-person visible on the spot.

Studying it

Tasks containing different sensitive classes (direct identifiers, quasi-identifiers, trade secrets, third-party data). Watch which downstreams the product sends history to by default: local, account cloud, team admin, training pipeline, support ticket. Independent variables: whether retention is classified, whether per-thread delete exists, whether delete covers artifacts and saved reusable objects, whether a pre-send warning says “this may be used to improve.” Dependent variables: user awareness of downstreams, match of actual downstreams to the claim, whether forensics after delete can still find it.

Do not only test whether the privacy policy is readable. Forensics: after tapping delete, is it still in the reuse library, the search index, the device backup.

Where it stops holding

Local, no-account, no-upload tools shorten the sensitive downstream, and still have the unlocked-device and backup-to-cloud problems. In enterprises, admin visibility is part of the contract, but that does not license sending a personal exploratory prompt (“help me draft a resignation”) to a line manager by default — workspaces and personal spaces are needed. Public demo accounts and classroom projection should have empty or fake history. Law sets retention for medical, children, finance; when deletion rights collide with retention duties, the surface must say which one wins. This entry does not argue against saving effective prompts. It argues against treating save as a costless convenience.

Applying it

• Treat the whole history at the highest sensitivity by default: encryption, least privilege, training opt-out. Entering training or team visibility needs a separate on, separately said.
• Delete is a first-class act, with scope written down: this thread / saved items / artifacts / search index. After delete, the same search should confirm it is gone.
• Before share, export, or project, warn what this history may contain, and offer “a window with no history.”
• Check: write a prompt with an obvious identifier, run save, sync, search. Then delete, and forensics on another logged-in device, the reuse library, the admin console. If it remains anywhere, the sensitive lifecycle did not close. Put that forensics on the release list, signed off apart from “can we reuse” and “can it be a textbook.”

Related

• Same group: L2.07.1 Effective inputs must be savable and reusable · L2.07.2 History is the main source for learning how to use the system
• Nearby: L2.14 Carrying and Clearing Context · L6.06 Inferred Preferences and Their Limits · L4.15 Accountability and Traceability
• Search terms: prompt history as sensitive data · prompt log PII · conversation data lifecycle