How to Prevent PII Leaks When Your Team Uses ChatGPT and Other LLMs

To prevent PII leaks when your team uses ChatGPT and other LLMs, you have to accept an unpleasant premise first: the leak is not an attack. Nobody is exfiltrating anything. A support agent pastes a customer email to get help drafting a reply, and the customer's name, address and order history leave the building in the process. The mechanism is an employee doing their job well with a tool that happens to send text to someone else's servers.

That framing matters, because it rules out most of the responses that come to mind first.

How PII actually gets into a prompt

It helps to be concrete about the paths, because they are not the ones a security review usually looks at.

• Pasted context. The most common by a distance. A ticket, an email thread, a CV, a contract clause, a row from a spreadsheet — pasted in wholesale because trimming it first would defeat the point of asking.
• Debugging payloads. A developer pastes a failing request or a stack trace. Production payloads contain production data, and often an API key or token in a header.
• Documents and screenshots. File upload and vision features mean a scanned identity document or a screenshot of an admin panel goes across as easily as text.
• Application integrations. An internal tool that calls a model API on the user's behalf. Nobody thinks of this as an AI tool, so nobody reviews what it puts in the prompt.
• Agents and IDE assistants. Tooling that reads files or queries a database and includes what it finds as context. The person asking never sees what was attached to their question.

Only the first two involve a human deciding to include the data. The rest happen underneath the person, which is why an approach resting on individual judgement can only ever cover part of the problem.

Why the data does not come back

Once a prompt is submitted, what happens to it is governed by the provider's terms and your plan tier, not by your policy. Consumer and enterprise tiers differ, retention windows differ between providers, and terms change. Some providers retain prompts for a period for abuse monitoring even where they are not used for training.

The point is not that any particular provider handles data badly. It is that the decision has moved. Your obligations around that data did not move with it — under India's DPDP Act, 2023, engaging a processor does not transfer your accountability, and erasure duties extend to data you have handed on. Data sitting in a third party's prompt history is difficult to erase on request.

Why the obvious fixes do not hold

Blocking the domains

Blocking AI tools at the firewall is the fastest control to deploy and the fastest to route around. People move to a phone, a personal laptop, a different provider, or one of the many products that quietly embed a model. The traffic leaves your visibility rather than stopping, which is strictly worse than governing it: you now have the same disclosures and no record of them.

Training and policy

Necessary, and not sufficient. A policy that says "do not paste customer data into AI tools" asks a person under time pressure to notice that the paragraph they are pasting contains personal data, every time, correctly. It also does nothing about the paths where the data is attached automatically.

Traditional DLP

DLP tooling watches channels — email, endpoints, file transfer — and its lever is allow or block. It has no concept of a prompt, and blocking is the wrong shape of response here anyway: the agent still needs their reply drafted. A control that stops the work will be worked around.

An API proxy

A proxy centralises keys and routing, which is genuinely useful, but it treats the request body as opaque. It does not know that a string in the middle of a JSON field is an Aadhaar number.

What actually works to prevent PII leaks: mask at the egress point

The approach that holds up is to route AI traffic through one gateway you operate, and have that gateway rewrite the prompt before it is forwarded. Two properties make it work where the others fail: it applies to every request regardless of who sent it, and it lets the request through.

Detection in two tiers

Sensitive values split into two kinds, and they need different treatment. Values with a known structure — Aadhaar, PAN, GSTIN, IFSC, UPI IDs, Emirates ID, Iqama, QID, payment cards, IBANs, US Social Security numbers, email addresses, IP addresses — can be matched on their pattern, with checksum validation where the format provides one to keep false positives down. Credentials fall in the same tier: provider API keys, GitHub tokens, AWS access key IDs, Slack tokens, JWTs, PEM private keys, URLs with an embedded password, plus a high-entropy check for secrets with no fixed shape.

The second tier is what patterns cannot reach. A person's name has no format. Neither does an organisation, a salary discussion, a medical detail or a contractual clause. These need named-entity recognition, and they are the values most likely to be sitting in a pasted ticket.

Tokenisation, not redaction

This is the part that decides whether people keep using the control. If you strip the values out, the model loses the thread — it cannot write "Dear Ms Rao" if it never saw a name, and it cannot reason about a record whose fields are blanked. So instead of deleting values, replace each one with an opaque token, forward a prompt that is still coherent, and restore the real values in the reply on the way back.

The user gets a normal answer. The provider never held the personal data. Nobody had to choose between doing their job and following policy, which is the choice that breaks every control that tries to make it.

Cover the non-interactive paths

The integrations and agents matter as much as the chat window. Issuing API keys for IDEs, scripts and internal tools that route through the same gateway means the same detection and masking apply where no human is present to exercise judgement — which is exactly where judgement was never going to be available.

Keep the record

You want to be able to answer "what did we send, and when" without qualification. A hash-chained audit trail, where each entry incorporates a hash of its predecessor so a later edit breaks the chain, gives an answer that holds up under questioning in a way an editable log does not.

Where to start

1. Map the real paths — chat tools, embedded features, internal integrations, agent tooling.
2. Give people one sanctioned route that is genuinely easier than the alternatives, or they will use the alternatives.
3. Turn on detection for structured identifiers and credentials first; they are unambiguous and the checksums keep noise low.
4. Add entity detection for names, organisations and the other unstructured categories.
5. Add your own organisation-specific values — internal identifiers, project code names — as policy.
6. Then narrow model access per user and group, once the traffic is visible enough to know what to narrow.

TorkQ does this at the egress point, on your own infrastructure. The homepage demo runs the detection on a prompt you type and shows what would have been masked before it left.