Everything you paste into an LLM is a disclosure

The argument about whether a model trains on your chats has eaten most of the oxygen in this conversation, and it is the least interesting part of it.

Assume the vendor is telling the truth. Assume your plan excludes your data from training, the retention window is thirty days, and the SOC 2 report is current. All of that can be true, and a copy of whatever you pasted still exists on infrastructure you do not run, inside an account that can be subpoenaed, logged for a window you did not choose, reachable by a support engineer under a process you have never read.

That is a disclosure. It is often an acceptable one. The problem is that nobody is deciding whether it is acceptable, because nobody is looking at what they pasted.

The paste is the risk, not the conversation

Watch what people actually send a model. It is almost never a sentence describing a problem. It is a sentence, and then four hundred lines underneath it.

A stack trace, because the stack trace is the problem. A config file, because the question is about the config. A failing request with its headers, because the headers are where the answer will be. A thread from the support queue, because you want a draft reply. A chunk of a CSV, because you want the shape of the data understood.

Every one of those is the right thing to send for the question being asked, and every one of them is a category of text that routinely carries something it should not. Not through carelessness — through structure. A stack trace carries file paths, and file paths carry usernames. A config carries connection strings, and connection strings carry passwords. A request carries an Authorization header, and that header is a live session. A support thread carries the customer, in full, by name and address and order number.

The person pasting is thinking about the bug. The secret is a passenger.

Three risks that get collapsed into one

When someone says "we can't use these tools, it's a security issue," they are usually gesturing at three unrelated things at once, and the mitigation for each is different.

The model learns it. This is the one everybody argues about and the one most easily addressed: read the terms, pick the plan that excludes training, move on. If this is your only concern you have already solved it.

The copy persists. Logs, retention, abuse-monitoring pipelines, backups. Your text sits somewhere for a period, under someone else's access control. No setting on your side changes the fact that it left. This is the risk that survives every enterprise agreement, because it is not a policy question — it is physics.

A credential in that copy is still live. This is the one nobody talks about, and it is the only one that is an incident today rather than a risk profile. A retained copy of a sentence about your architecture is a disclosure you can reason about. A retained copy of a working AWS secret key is an exposed key, and the thirty-day retention window is thirty days during which it is somewhere you cannot see it.

The first is a procurement problem. The second is a judgement call. The third is a rotation ticket, and it needs opening the moment you notice.

Enterprise plans do not fix the mechanical mistake

Zero-retention endpoints are genuinely good and worth buying. They do not solve this, because the failure is upstream of the vendor.

The same paste that goes into the approved tool goes into a ticket, a Slack thread, a screenshot in a bug report, a pastebin a contractor used because it was faster, and a model someone opened on their phone because the approved one was down. The credential was in the text before any of those choices were made. Fixing the destination does nothing about the content, and content is the part you control.

There is also the honest version of what happens when you ban the tools: people use them anyway, on personal accounts, where you have no agreement at all. A policy that is routed around is worse than no policy, because it removes your visibility without removing the behaviour.

Redaction has to keep the structure

The obvious answer is to strip the secrets before pasting, and the obvious implementation of that is bad: replace everything sensitive with XXXX.

Do that and you destroy the thing that made the text worth sending. A model reading a log needs to know that the request in line 4 came from the same user as the error in line 40. Replace both with XXXX and it cannot tell. Replace every email address in a thread with XXXX and a three-way conversation becomes one indistinguishable voice. The answer you get back gets worse in a way that is hard to notice, so people conclude redaction is not worth it, and they stop.

The fix is cheap: stable placeholders. The same value becomes the same token everywhere it appears — [EMAIL_1], [AWS_KEY_1], [EMAIL_2] — so the relationships survive while the values do not. The model can still reason that two lines refer to one person; it simply never learns which person.

Then reverse it. When the reply comes back with [EMAIL_1] in the draft, swap your real values back in locally. The round trip costs nothing, and it is the part that makes this survive contact with a working day. A safety measure that makes the output worse is a safety measure you will use twice.

The redactor has to run where the secrets already are

A hosted service that removes secrets from your text has to receive your text containing the secrets. The absurdity should be the end of the discussion.

This belongs in the browser, which is why the prompt sanitizer runs there — it reads what you paste, masks what should not travel, keeps the mapping in the tab, and makes no network request carrying any of it. It is the only arrangement where the promise is checkable rather than merely stated.

What pattern matching cannot do

It will find the mechanical things: keys in the shapes vendors publish, private key blocks, connection strings, Authorization and Cookie headers, JWTs, emails, phone numbers, card numbers that pass a Luhn check, public IPs, the username inside /Users/you.

It will not find a person's name, because a name is a word. It will not know that a project codename is confidential, that a revenue figure is unpublished, or that the paragraph you typed above the log describes an architecture you have never discussed publicly. It will not catch a credential in a format nobody has standardised, and it will not read an image you attach.

So it is not a gate. It is the thing that catches the passengers — the pasted key, the stray address, the header you forgot was in the request — while the judgement about everything else stays yours. That is a smaller claim than most tools in this space make, and it is the true one.

One rule worth adopting

If a credential has been in a chat window, it is spent.

Not "probably fine because retention is thirty days." Not "fine, it was the staging key." A secret that has been somewhere it should not have been is not a secret you still own, and the only honest response is a new one. The same goes for a key in a ticket, a Slack channel, a screenshot, a CI log.

Rotate it, then check what it was permitted to do during the window you were not watching. That second step is the one people skip, and it is the one that tells you whether this was a disclosure or an incident.