Before You Press Send

Executive summary

Is ChatGPT sending your message before you press send? Yes. Not as a theory, and not as an edge case: the assistant receives what is in the composer while you are still typing it, through a channel that exists for a helpful feature and has nothing to do with the send button. Most people picture the send button as the moment their text leaves the browser. For the mainstream AI assistants it is not the first moment, and often not even the important one.

That gap breaks the one safety habit almost everyone relies on: type something, notice a secret or a name in it, delete that part, then send the cleaned version. The habit assumes nothing has left until you decide it should. When the draft is transmitted as you type, the sensitive text is already gone before you delete it, and the clean version you send is the only version you ever see. This paper shows the channel that does this, with a measurement from our own instrumentation, walks two ordinary situations where remove-before-send quietly fails, and describes the control that closes the gap: detection that runs on the device and governs the draft channel, not just the send.

The problem: the text leaves before you decide to send it

A modern AI assistant is a web application, and a web application does not wait for a button to talk to its servers. It sends telemetry, it saves drafts, and increasingly it predicts what you are about to type so it can offer to finish your sentence. Every one of those features needs the current contents of the box you are typing in, so every one of them is a path by which that content leaves the browser before you have finished the thought, let alone decided to send it.

This is not a vulnerability in the ordinary sense. Nobody broke in. The assistant is doing exactly what its product design intends, on a connection the user is allowed to make to a vendor the user chose. That is precisely why it is dangerous to a security program: the content leaves through a permitted request to an approved destination, so a network control sees a normal session and a data-loss tool built for email and file shares never sees it at all. The only place the exposure is visible is between the keyboard and the first outbound request, and almost nothing watches there.

The draft channel, measured

The clearest example is autocomplete. chatgpt.com posts the composer's current contents to an endpoint named generate_autocompletions on every batch of keystrokes, so it can suggest the rest of your sentence. That request carries whatever is in the box at that instant, which means the box's contents reach the server repeatedly, keystroke batch after keystroke batch, long before any send.

We did not infer this from documentation. We watched it. When our own browser control was run against a real, logged-in ChatGPT session and its decisions were recorded, 178 of 200 recorded decisions were that single autocomplete endpoint. The record of a person using the assistant was made almost entirely of their keystrokes leaving the browser, not of the messages they chose to send. The send is the visible event; the drafts are the volume.

Autocomplete is the example that is easy to point at, not the whole of the problem. Draft-saving, typeahead and suggestion features across assistants all share the same shape: the composer's live contents are useful to the product, so the product reads them continuously. Any feature that helps you while you type is, by construction, a feature that has your text while you type.

Why remove-before-send is a false sense of safety

Manual redaction is a control that acts at one instant: the moment before you click send. It works only if that instant is the first time the text could leave. Against a channel that fires as you type, the instant is too late. The delete key removes the sensitive text from what you will send, and from what you can see, but not from what already left. You are editing the copy that stays with you, not the copy that is already on the vendor's servers.

This is the uncomfortable part, because remove-before-send is exactly the behaviour every policy asks for and every careful person performs. The habit is not sloppy. It is defeated by a mechanism most people do not know exists, and cannot see even if they do, because the browser gives no sign that a draft was transmitted. A control that depends on the user seeing the sensitive text in time cannot govern a channel that already sent it while it was being typed.

Two ways remove-before-send fails

Scenario 1: the developer and the deleted API key

A developer is debugging a service and pastes a whole configuration file into the assistant to ask why a request is failing. The file includes a live API key, because configuration files usually do. Halfway through writing the question the developer notices the key, selects it, deletes it, and replaces it with a placeholder before pressing send. By the standard everyone is taught, that is the right move, done in time.

But the paste landed in the composer, and the composer's contents were read by the draft channel on the keystroke batches that followed. The full file, key included, was transmitted while the developer was still reading it. The message that arrives at the assistant is the clean one; the key left several seconds earlier, in a request the developer never saw and the browser never flagged. The developer will remember having removed it, and be right, and still be wrong about whether it leaked.

Scenario 2: the clinician and the removed patient name

A clinician drafts a summary of a difficult case to ask the assistant for wording help, and pastes in a patient record to give it context. Following de-identification policy to the letter, they then delete the patient's name and identifiers before sending, so the assistant sees only the clinical detail. This is the discipline the training asks for, and it is being followed exactly.

The record, name and all, was already read from the composer as it was typed and pasted. The identified version left the browser during editing; the de-identified version is what the clinician sends and what they believe they disclosed. The policy was honoured against the send and bypassed against the draft, and the difference is invisible to the person doing everything right. Remove-before-send cannot de-identify a record that was transmitted while it still had the name in it.

VisIQ's answer: edge-isolated real-time control

The fix has to move the decision to where the text actually is, which is on the device, in the browser, before any request leaves. The Context Firewall is a browser extension that sits between the composer and the network. It reads what is about to leave, applies policy to it, and governs the draft channel on the same terms as the send, so a secret or a personal identifier is caught on the keystroke path and not only when you press the button.

Detection runs locally, inside the extension, with a small on-device model. There is no round trip to a classifier, which matters twice over. It is why the control can act before the first outbound request, in the narrow window remove-before-send misses, and it is why the tool that inspects your sensitive text does not become one more place your sensitive text is sent. The content the extension reads to protect you stays on your machine.

How the draft channel is actually governed

The draft path is not treated like the send, because a draft is not a message and pretending it is would be both noisy and wrong. Three deliberate differences define it:

• on the draft channel there is nothing to mask, so a detected secret withholds the request entirely: the half-typed content simply does not go, rather than being rewritten in flight
• a draft produces no report, no verdict and no stored record, so a person's keystrokes never become a log of what they typed; only a real send emits a decision
• the subject-matter model that scores topics on a finished message is not run on every keystroke, because a half-typed sentence is not something a topic score should judge, and running it on each keystroke is the cost this separation exists to avoid

The visible outcome the user sees still arrives at the send, where a protected value is masked or the message is stopped. What the draft governance adds is that the same secret cannot slip out the side door a few seconds earlier. A suggestion that quietly did not arrive is invisible, and that is the point: the leak is prevented without interrupting the person's typing.

What leaves the device, and what does not

Because detection is on-device, the sensitive content the firewall inspects is never sent to VisIQ to make a decision. The decision is made where the text is. What can leave, when an organization turns it on, is the record of a decision: that a send on a given surface was masked or blocked, with the metadata a security team needs to govern, and only according to the organization's own policy. Drafts, as above, produce no record at all.

The default posture is the private one. An organization that wants an audit trail of what its people's assistants were about to leak can choose to record decisions; an organization that wants only prevention can leave that off and still get the protection. The content itself is not the thing that travels. The judgement about it is, and only when someone asked for it.

What this is, and what it is not

Honesty about scope is what makes the rest of this credible. The Context Firewall is a working control proven in a real browser, not a finished, generally available product you download today, and this paper describes mechanism and coverage rather than a self-serve install. It governs the assistants it carries a per-surface adapter for, because every assistant composes and sends differently: ChatGPT, Gemini, Microsoft Copilot, Claude and Perplexity, chosen by measured web-traffic share. An assistant is either adapted or it is not, and naming the list is what keeps the coverage claim checkable.

The on-device detector targets recognizable high-risk classes and value shapes: secret- and credential-shaped strings, payment-card and personal identifiers. It is not a claim to understand every sensitive concept in every phrasing, and it complements the classification and controls an organization already runs rather than replacing them. Stating that boundary plainly is what separates a real control from a promise no tool could keep.

Rolling it out

Phase 1: see the drafts

Run in observation mode first. The extension evaluates the draft and send channels and records what it would have caught, blocking nothing. Within days a security team has the first factual picture of how much sensitive content is already leaving through the composer before anyone presses send, which is usually more than expected and almost never previously visible.

Phase 2: enforce on the draft and the send

Turn on enforcement for the high-confidence classes. Secrets and identifiers are withheld on the draft channel so they cannot leave while a person types, and masked or blocked on the send so the person sees the outcome. Typing is not interrupted and the assistant behaves normally; the only visible difference is that protected values arrive masked, or a clearly unsafe message is stopped.

Phase 3: widen coverage

Extend to the assistants your people actually use as adapters are added, tune the classes to the organization's own sensitive material, and decide the recording posture per policy. The principle does not change as the surface list grows: decide on the device, decide before the request leaves, and never make the inspecting tool a new place the data goes.

Conclusion

The send button is not the boundary people think it is. For the mainstream assistants, the text in the composer reaches the vendor while it is being typed, which means the near-universal habit of cleaning a message before sending it is protecting the wrong copy. The answer is not to ask people to type more carefully. It is to move the decision to the device and onto the draft channel, so sensitive content is caught before it can leave at all, and to keep that detection local so the control is not itself another exposure. Learn more at visiqlabs.com · Technical documentation at docs.visiqlabs.com