You stop employees pasting sensitive data into ChatGPT by giving them a sanctioned way to use AI that is easier than the unsanctioned one, and by putting content controls on that path. In practice that means company-managed AI access, routed through a gateway that can block or redact sensitive content before it reaches the model provider, plus network and policy controls that close the side doors. A ban on its own does not work: the demand for AI help is real, so use moves to personal accounts and personal devices where you see nothing.
This post covers why existing data loss prevention (DLP) tools struggle with the prompt box, the controls that work in the right order, and how to tell whether they are working.
Why this keeps happening
Employees paste data into chat assistants because it makes them faster. A support agent pastes a customer thread to draft a reply. An engineer pastes a stack trace that contains a connection string. A finance analyst pastes a spreadsheet extract to get a summary. None of them think of it as data exfiltration. They think of it as using a tool.
OWASP lists this pattern as LLM02: Sensitive Information Disclosure in its Top 10 for LLM applications. Personal data, credentials, source code and confidential business information leave the organisation through a prompt, and where they end up depends on the provider, the plan and its retention settings. For the tier-by-tier differences, see is ChatGPT safe for company data?.
This is one form of shadow AI: AI use that happens outside any review, inventory or control.
Why legacy DLP misses the prompt box
Traditional DLP was built for files, email and known upload channels. It fingerprints documents, scans attachments and watches for transfers to unapproved storage. A chat prompt is different in three ways:
- It is typed or pasted text, not a file. There is often no document to fingerprint. The sensitive content is a fragment copied from another window.
- It travels inside an encrypted session to a domain that is often allowed. Unless you inspect TLS traffic and understand the specific web application, the network sees a connection, not the content.
- The risk is semantic. A pasted customer complaint may contain a name, an account number and a health detail. A pattern match on the whole prompt either fires constantly or misses the context.
Browser-extension DLP and secure web gateways can close part of this gap, and they are worth evaluating. But they only see the browser. The same data also reaches models through internal tools, scripts and agents calling provider APIs directly. That path needs a control at the API layer.
The controls, in the order that works
Order matters. If you block first, you create shadow use. If you only publish a policy, nothing is enforced.
1. Give people a sanctioned path
Provide AI access that the company controls: a business plan of the chat product, an internal assistant, or both. The internal option routes requests through a gateway you operate or govern, using provider keys held centrally rather than on laptops. The goal is that the approved route is the convenient one.
2. Put content guardrails on that path
On the gateway path, inspect each prompt before it leaves. Decide per data class what happens:
- Block credentials, private keys and regulated identifiers that must never leave.
- Redact personal data where the task still works without it, such as names and email addresses in a support draft.
- Warn on borderline content, so users learn the rule without being stopped.
The trade-offs between these actions are covered in designing guardrails: block, redact or warn, and the mechanics of masking personal data are in how to redact PII from agent prompts. Inspecting responses as well as prompts matters too; see bidirectional guardrails.
3. Keep provider keys off endpoints
A developer with a personal API key in a .env file has a private, ungoverned AI channel. Hold provider keys centrally and issue application keys for the gateway instead. Securing LLM provider API keys covers storage and rotation.
4. Close the side doors
Once the sanctioned path exists, block or restrict unsanctioned AI domains on managed devices and networks. Be honest about the limit: a personal phone on mobile data is outside your control. Policy and training carry that part.
5. Write the rule down
Publish an acceptable use policy that names the approved tools, the data classes that must never be entered, and what happens on a breach. How to write an AI agent acceptable use policy has a structure you can adapt.
6. Measure and adjust
Count what the guardrails block per team and per data class. A rising block count in one team usually means a workflow need, not bad intent. Fix the workflow, for example with an approved integration, and the pasting stops.
Control comparison
| Control | What it catches | What it misses | Effort |
|---|---|---|---|
| Ban on AI tools | Nothing it can verify | All use on personal devices and accounts | Low, but backfires |
| Network blocklist of AI domains | Unsanctioned web tools on managed networks | Personal devices, new domains, API calls through allowed hosts | Low to medium |
| Browser DLP extension | Text pasted into known web apps on managed browsers | Unmanaged browsers, API and agent traffic | Medium |
| Gateway with content guardrails | Prompts sent through the sanctioned path, from people and agents | Anything that does not route through the gateway | Medium |
| Acceptable use policy and training | Intent, and use on devices you do not manage | Mistakes under time pressure | Low |
No single row is enough. The gateway carries the most weight because it covers both people and automated callers, but it only sees traffic that passes through it.
Rollout checklist
Where Praesidia fits
Praesidia follows the discover, secure, prove sequence. Discover: register the AI agents and applications in use so the inventory is real, as described in how to build an AI agent inventory. Secure: Praesidia's model gateway puts one address in front of the providers you use, holds your provider keys server-side, and applies guardrails that can block or redact matched content on model traffic. Prove: when the gateway blocks a call or requires a step-up, the decision is written to an append-only, hash-chained audit trail.
Two limits to plan around. Allowed calls, redactions and warnings on the gateway path are not written to the audit trail, so the signed trail shows blocks, not every redaction or warning. And Praesidia only sees traffic that is routed through it; a paste into a personal ChatGPT account on a personal device is outside any gateway, which is why the policy and network steps above still matter.
Common questions
Should we just block ChatGPT? Not as the first step. Blocking without an alternative pushes use to personal devices. Block unsanctioned tools after you provide a sanctioned one.
Does a business ChatGPT plan solve the problem? It improves the contractual position on retention and training, but it does not stop an employee pasting a password. You still need content controls and a policy.
Can guardrails read every prompt without creating a new privacy risk? Inspection should happen in the request path, with decisions logged rather than full prompt content wherever possible. Check the logging scope with your data protection officer; can you monitor employee AI usage under GDPR? covers the EU position.