Capture at the composer
A proxy sees the request after send. A browser extension reads the textarea before submission — the only point at which blocking is still possible.
The four approaches
Each one fails in a specific, predictable way.
Domain blocking looks decisive and produces the worst measurable outcome: employees who need the tool will use it on hardware you do not manage, where you have no telemetry at all. You have converted a visible, governable risk into an invisible one.
| Approach | What it does | How it fails |
|---|---|---|
| Block the domains | Firewall or proxy denies the AI hosts | Usage migrates to phones, personal laptops and tools not on your list. You lose visibility, not risk |
| Training and policy | Tell people what not to paste | Reduces careless use; does not survive a deadline. Necessary, not a control |
| Cloud AI gateway | Route prompts through a scanning service | Works — by sending the content to another third party. The disclosure moves; it does not stop |
| Endpoint detection | Detect locally, before send, warn or block | Requires managed devices and a managed browser. Does not cover personal hardware, by design |
Only the fourth both prevents the disclosure and keeps the data on the device that already legitimately holds it. The honest goal is not zero AI use — it is AI use you can see, with the sensitive fraction stopped at the composer.
What it requires
Four things that must be true together.
Miss any one of them and the control either does not prevent anything, or gets bypassed.
Detection that runs locally
If the check itself calls out to a scanning service, you have re-created the problem you were solving.
Latency low enough to be invisible
An agent that makes people wait gets bypassed or uninstalled. Both are coverage failures.
Precision that keeps warnings meaningful
The real failure mode is not a missed SSN. It is a false-positive rate that trains people to click through.
Rollout
Log, then warn, then block — in that order.
Start in log-only for two to four weeks on one department. You are not protecting anything yet; you are measuring how noisy detection is against real traffic.
Then warn, and watch the click-through rate. High dismissal is a precision problem, not a discipline problem, and escalating to blocking will produce circumvention rather than compliance.
Then block, starting with checksum-validated detectors only — card numbers with a valid Luhn check, recognised key prefixes — where a false positive is nearly impossible.
Straight answers
Can’t we just block ChatGPT at the firewall?
You can, and usage moves to personal phones, personal laptops and AI tools you have not heard of. You lose visibility rather than gaining control, and the leakage continues somewhere you cannot measure it.
Doesn’t an enterprise AI subscription solve this?
It changes the contractual posture of one destination. It does not stop an employee using a personal account, and it does not tell you which data categories are flowing even to the sanctioned tool.
Is training employees enough?
Training reduces careless use and does not survive deadline pressure. It is necessary and it is not a control — treat it as a complement to a technical measure, not a substitute.
What about AI gateway products that scan prompts in the cloud?
They work, by sending the content you were protecting to another vendor’s servers for inspection. That may be acceptable under your risk model, but it relocates the disclosure rather than preventing it, and it is worth naming explicitly during vendor review.
Set different policy for sanctioned and unsanctioned destinations. Treating them identically floods analysts with alerts about the tool you told everyone to use, and the alerts stop being read.