How do you keep credentials and customer data out of what gets pasted into an assistant?

On the detection layer specifically, since that is what you are being sold: know what it is good at.

Good at: structured secrets. API keys, tokens and connection strings mostly have recognisable shapes, and the same scanners used for repositories work well here. High precision, low effort.

Weaker at: personal data. Names, addresses and free-text customer detail have no shape. Detection is a classifier, it has false positives that annoy people and false negatives that matter, and screenshots need optical character recognition first, which adds its own errors.

Cannot do anything about: context. A hostname is not sensitive until you know it is your production database. No filter has that knowledge.

So treat these tools as raising the floor, not as a boundary. The thing I would insist on before deploying one is that it fails open or closed by an explicit decision, a redaction tool that silently drops a block of a user's message produces very confusing bug reports.

Order the interventions by where they sit, because the effective ones are upstream of the paste.

Best: the secret is not in the artefact. Most of what gets pasted contains credentials because the log printed them. Scrubbing at the logging layer fixes it for every downstream use: assistants, ticket systems, screenshots, screen shares - permanently and with no user behaviour required. This is unglamorous and it is by far the highest-value change.

Next: an approved tool with a contract. People paste into whatever is available. Providing a sanctioned assistant whose terms exclude training on your data, and blocking the unsanctioned ones, converts an uncontrolled exposure into a controlled one. It does not stop the data leaving your building; it changes who holds it and under what agreement.

Then: detection at the boundary. A proxy or endpoint agent that spots credential-shaped strings on the way out and blocks or redacts. This is what the runtime tools are selling.

Last: user behaviour. Training and policy. Necessary, and least reliable.

The screen-blurring category is worth separating out because it solves a different problem than people assume.

It is aimed at screen sharing and recording, a call, a demo, a screenshot for a ticket. There the exposure is visual and momentary, and blurring at the compositor before anything is captured genuinely works.

It does very little for the paste problem, because pasting copies the underlying text, not the pixels. Somebody whose screen is blurred can still select and copy the token.

So if the concern is calls and recordings, that category is right. If the concern is what goes into an assistant, it is the wrong shelf, and the vendors are not always careful about the distinction.

One low-effort thing that changed behaviour on my team more than any tool: make the safe path faster.

We added a one-key command that copies the current log with secrets already scrubbed. People use it because it is less work than selecting the text by hand, not because of policy.

Security measures that add a step lose to convenience every time. Ones that remove a step win without needing anybody to agree with them.