The data exposure associated with these tools is rarely a breach. There is no attacker and no alert. Content simply leaves, through a normal feature working as intended, because nobody decided what was permitted to leave.
Three questions determine the exposure for any tool, and they are answered separately. Is the content used to train a model. Is it retained, and for how long. Who can read it while it is retained.
The answers differ by tier, and materially
Consumer and business offerings from the same provider frequently differ on all three. Consumer tiers have historically defaulted to using submitted content for improvement, with an opt out. Business and enterprise tiers generally do not train on customer content and are governed by a contract rather than a policy page that can be revised.
Training is also not the only concern. Content is commonly retained for a period for abuse monitoring even where training is disabled, which means it exists in a system outside your control, subject to that provider's access arrangements. For most material that is acceptable. For regulated or contractual data it may not be, and the distinction is worth establishing before it matters rather than afterwards.
People paste more than they realise
The largest source of exposure is not exotic. Someone pastes a stack trace to get help with an error, and the trace contains a connection string. Someone pastes a spreadsheet section to summarise it, and the rows are customer records. Someone pastes a contract to check a clause. Someone pastes code that is not public.
None of this is careless in intent. The behaviour is identical to searching the web for an error message, which was safe, and the mental model carries over unchanged even though the destination now retains what it receives.
Integrations collect without being asked
A chat window makes the boundary visible, because the person chooses what to paste. Integrations remove that.
An editor plugin may send surrounding files rather than the selected lines, because more context produces better completions. A browser extension may send page content, including pages behind authentication. A meeting assistant sends the entire conversation. In each case the volume leaving is decided by the tool's design rather than by a person, and it is usually far larger than the person assumes.
Agents extend this further. An agent with filesystem access reads what it judges relevant and includes it in a request, so the selection is made by a model rather than a human, and no one reviewed what went out.
The wrapper problem
Many tools are built on top of a provider rather than being that provider. The application receives the input, may store it, may log it, and then forwards some of it onward.
The terms that apply are the application's, not the underlying provider's, and they are often considerably weaker. A tool advertising that it uses a well known model tells you nothing about what the intermediate service does with the data on its way there. That intermediate layer is frequently a small company with a shorter security history and less contractual exposure, and it is the party actually holding the content.
Your own logs are part of the surface
Systems built on these models produce prompt and completion logs for debugging and evaluation, and those logs contain everything users submitted.
They are routinely stored with less care than the primary database, in observability platforms with broad internal access and long retention, and outside the deletion processes that apply to user records. A request to delete a user's data that does not extend to the prompt logs has not deleted it. This is an internal problem, entirely within your control, and it is the one most often missed.
Where the law becomes involved
Two aspects turn this from a hygiene question into a compliance one.
The first is location. Content sent to a provider is processed somewhere, and where that is determines which rules apply and whether a transfer mechanism is required. Regimes covering personal data generally require a documented basis for moving it across borders, and a tool adopted by a team without review will not have one.
The second is deletion. Where a person has a right to have their data removed, that right extends to every copy, including the provider's retained logs and any prompt logs held internally. Where content has already been used for training, the position is considerably harder, because removing a specific record from a trained model is not a supported operation. This is the strongest practical argument for ensuring that regulated content is never sent to a tier that trains on it, since the decision cannot be reversed afterwards.
What is worth actually doing
The measures worth taking are ordinary, and the first one determines whether any of the others can be applied consistently.
| Measure | What it addresses |
|---|---|
| Classify what may leave | Everything else is guesswork without it |
| Use tiers with contractual terms | Settings can be changed, contracts cannot |
| Redact at the boundary | Credentials and identifiers pasted by accident |
| Scope integration access | Tools reading far more than the person intended |
| Treat prompt logs as production data | Your own copy of everything users submitted |
| Keep a local option | Material that genuinely should not leave at all |
The fifth row is the one most often missed and the one entirely within your control, since prompt logs are usually stored with less care and longer retention than the primary database.
Note: the test is not whether the provider is trustworthy. It is whether you could state, accurately, what left the organisation last month and where it currently resides. Most organisations using these tools could not.