Sensitive data reaches public AI assistants because employees paste it there, not because a control failed. Blocking the domains moves the traffic to unmanaged devices rather than stopping it. Reversible masking is the alternative that holds: sensitive values are identified and replaced with placeholders before the request leaves the browser, the model reasons over the placeholders, and the real values are restored only inside the organisation's own tenant.
The instinctive response — block the domains — is the one approach with a known failure record. This page covers why, and what works instead.
Why blocking fails
Blocking AI assistants at the network level produces three predictable outcomes:
The traffic moves; it doesn't stop. Employees switch to personal devices, phone apps and home networks. The organisation hasn't reduced its exposure — it has traded visible usage on managed endpoints for invisible usage on unmanaged ones. This is how shadow AI is manufactured.
The productivity case collapses. The same executives funding AI adoption programmes are asked to explain why the tools are banned. Blocking puts security in structural opposition to the business — a position security teams lose over time.
Blunt allow/deny can't express real policy. Real policy is conditional: this team may use this assistant for this class of data, with these values protected. A firewall rule has no vocabulary for any of that.
The goal is not less AI. It is AI where sensitive values never leave in the first place — with everything else flowing freely.
Reversible masking: how the "yes, safely" model works
The alternative to blocking is inspection and masking at the point of use — in the browser, before the request leaves:
- Detect. As an employee writes a prompt or attaches a file, sensitive values are identified — names, account and reference numbers, amounts, and custom data classes the organisation defines (customer IDs, project codenames, contract counterparties).
- Mask before send. Each sensitive value is replaced with a placeholder token — [PERSON_01], [REFERENCE_01] — before the request leaves the browser. The public model receives a prompt that is fully usable for the task but contains none of the underlying values.
- Restore on return — including computation. When the answer comes back, placeholders are swapped back to the real values inside the organisation's tenant. And restoration goes beyond substitution: if the answer requires an operation on masked values — a sum of two masked amounts, a difference between two masked dates — the model returns the operation over the placeholders, and Guard evaluates it against the real values locally and inserts the result. The employee sees a complete, correct, computed answer; the provider never saw a single underlying value.
- Log and stream. The interaction — who, which assistant, what data classes were masked, what policy applied — is recorded and streamed to the SIEM and DLP tooling the security team already runs.
The decisive property is reversibility. One-way redaction breaks the work: an answer full of [REDACTED] is useless, so employees stop using the sanctioned path. Reversible masking keeps the answer whole, which keeps employees inside the governed channel voluntarily — the only kind of compliance that survives contact with deadlines.
The paths beyond the browser
Employee prompts are the highest-volume leak path, but not the only one. A complete data-protection posture covers three:
Browser (employees). Masking and policy enforcement in the browser extension, across the major AI assistants, as above.
API (applications). Internal services calling models directly each carry their own keys and their own unmonitored data flow. Routing application traffic through a single AI gateway applies the same masking and policy rules machine-to-machine, centralises key custody, and consolidates the audit trail.
Agents. As AI agents gain read access to CRMs, databases and file shares, the question shifts from "what did the employee paste" to "what can the agent reach." Governed agents operate under enterprise permissions, with human review required where policy demands it.
One policy engine across all three matters more than any single control: gaps form exactly where two disconnected systems meet.
What to look for in an evaluation
Seven questions separate production-grade AI data protection from demos:
- Is masking reversible, with restoration inside your tenant only?
- Can restoration handle operations on masked values — sums, differences, comparisons — or does any arithmetic over sensitive numbers break the answer?
- Can you define custom data classes — your customer-ID formats, your codenames — or only generic PII patterns?
- Does the same policy engine cover browser, API and agent traffic?
- Does it inspect for prompt injection and exfiltration attempts, not just outbound PII?
- Do events stream to your SIEM/DLP, in a form your auditors accept?
- Does it work with the assistants employees already use — or does it require replacing them?
Where DSX Guard fits
DSX Guard is built on exactly this model: browser protection for ChatGPT, Claude and Gemini with reversible masking and custom data definitions, threat and prompt-injection inspection, an AI gateway for application-to-model traffic with central key custody, governed enterprise agents and connectors, and SIEM/DLP streaming — one control layer for every path to AI, priced per protected user with every capability included. The DSX Guard use cases show the same control layer applied to employee access, application traffic and enterprise agents, and the security page covers deployment, identity and auditability. For the broader control model, see What Is Enterprise AI Governance?