Skip to content
Claudexia TeamSECURITY

What never to send to a language model: a practical list

Secrets, personal data, someone else's code under NDA. What actually leaks, what it costs, and how to build a process that does not rely on discipline.

The rule is simple: assume anything you send has left your perimeter. The only remaining question is how much that matters.

Never

Secrets and keys. Tokens, passwords, private keys, database connection strings. The most common leak path is pasting a whole config file to ask about one line.

Personal data. Real names, phone numbers, addresses, identity documents, medical information. For companies operating in Russia this is also a data-protection law question.

Someone else's code under NDA. If you are a contractor, client code usually cannot leave anywhere, language models included. Check the contract before sending.

Payment card data. Its own regulatory regime, its own consequences.

Handle with care

Database schema. Rarely secret by itself, but combined with a server address it becomes a map for an attacker.

Logs. Almost always contain more than they appear to: session tokens, user identifiers, internal hostnames. Clean before sending.

Stack traces. Often include chunks of environment and on-disk paths.

Not relying on discipline

People make mistakes under deadline pressure. So you want a process, not a poster.

Keep secrets out of code. If a file holds variable names rather than values, there is physically nothing to paste.

Run a scanner on pre-commit. It catches secrets before they reach the repository, and therefore before they reach a prompt.

Separate environments. Use test data for model experiments, not a production dump.

Anonymise at the boundary. If the task itself is about personal data, substitute synthetic values before sending.

What happens to data on our side

We do not store request or response content. The database holds only the metadata billing needs: which model, how many tokens, what it cost.

Take that literally: your prompt cannot be recovered from our database because it is not there.

If a secret did get out

The order is the same as any leak:

  1. Revoke and reissue the key immediately, not at end of day.
  2. Review access logs for the window the key was alive.
  3. Find how it reached the prompt and close that path.

The first step matters more than the rest. Everything else can follow.

In short

Secrets, personal data and NDA code go nowhere. Everything else gets cleaned first. Process beats a reminder: secrets out of code, a pre-commit scanner, test data for experiments.