Rea

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.

One thing worth checking rather than assuming when a product claims on-device: whether it means all of it.

Common and legitimate patterns that are all described as "runs on your device":

• Everything local, no network. The strong claim.
• Local for the routine path, cloud for the hard one, with a toggle.
• Local for the media, cloud for the reasoning about it — very common in editing tools.
• Local processing, cloud sync of the results.

These have completely different privacy properties and all four get the same sticker. The test is the boring one: run it with the network off and see what still works, then watch the connections when the network is on.

If privacy is the actual reason you are choosing it, that ten minute check is the whole due diligence.

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 architecture that actually holds up, and it is not either of the two things in the question: constrain what the system can do, not what it may say.

If the agent has no credential for the destructive operation, no prompt and no filter is load-bearing. If it can only write to a scratch area, an injected instruction to delete production fails at the permission layer, silently and completely.

So the ordering I would argue for:

1. Capability limits. Least privilege, per agent, enforced outside the model.
2. Runtime checks on input and output, for the categories a classifier is genuinely good at.
3. Prompt instructions, as the last layer and the one you assume can fail.

Most teams build these in exactly the reverse order, because the third is free and the first requires touching infrastructure.

Two practical points that get skipped and later become incidents.

Fetching a URL a user supplied is a server-side request forgery risk. Somebody will pass an internal address or a cloud metadata endpoint. Allow-list schemes, block private ranges, resolve before you connect and check what you resolved to.

Page content is untrusted input that reaches a model. Text on a page can be written to instruct your agent, and it will. Keep fetched content clearly separated from your instructions and never let it grant the agent anything it did not already have.