Privacy and Security
Know where pasted text goes, keep secrets and other people's data out of prompts, redact before you paste, and check AI-written code for security holes.
On this page
A login bug has you stuck, so you paste the config file and the last fifty lines of the server log into an AI assistant. It spots the problem in seconds. What you did not notice is that the log also held a customer's email address and the config held the production database password.
Maybe nothing bad ever comes of it. But that password now sits in a chat history on a server you do not run, kept for as long as that service keeps things, and visible to whoever can open your account. You gave away control of it to fix one bug.
Pasted text leaves your hands
When you send a prompt to a hosted assistant, the text travels to the provider's servers to be processed. What happens next depends on the provider, your plan and your settings. It can be kept in your chat history, kept in logs for a while for abuse monitoring or debugging, and in some setups used to improve future models.
You do not need to fear this. You need to know the answers for the tools you use, once:
- Is this tool approved for this kind of data? At work, your employer may allow some tools for code and forbid them for customer data. Ask before you find out the hard way.
- Is my data used for training, and can I turn it off? This often differs between personal and business plans.
- How long are conversations kept, and does deleting a chat delete it everywhere?
- Who else can see my history? Shared workspaces, admins and shared devices all count.
What to keep out
- Secrets: passwords, API keys, access tokens, private keys, connection strings.
- Other people's personal data: names with contact details, health, financial or student records. They did not agree to share it with a third party, and laws in many places say you need a reason to.
- Confidential work: unreleased plans, contract terms, code your employer has not cleared for the tool.
The model rarely needs the real value. To debug a login, it needs to know that a password is set, not what it is. Replace sensitive values with placeholders like [EMAIL] or [SECRET], and the help you get is the same.
Redact before you paste
For logs and config files, a small script does this faster and more reliably than your eyes. Each rule replaces one known shape of sensitive text, in order.
// Rules run in order. Each replaces one known shape of sensitive text.
const RULES = [
[/[\w.+-]+@[\w-]+\.[\w.]+/g, "[EMAIL]"],
[/\b(\w*(?:password|secret|token|key))\s*[=:]\s*\S+/gi, "$1=[SECRET]"],
[/\b[A-Za-z0-9_-]{32,}\b/g, "[TOKEN]"],
];
function redact(text) {
for (const [pattern, replacement] of RULES) {
text = text.replace(pattern, replacement);
}
return text;
}import re
# Rules run in order. Each replaces one known shape of sensitive text.
RULES = [
(r"[\w.+-]+@[\w-]+\.[\w.]+", "[EMAIL]"),
(r"(?i)\b(\w*(?:password|secret|token|key))\s*[=:]\s*\S+", r"\1=[SECRET]"),
(r"\b[A-Za-z0-9_-]{32,}\b", "[TOKEN]"),
]
def redact(text):
for pattern, replacement in RULES:
text = re.sub(pattern, replacement, text)
return textStep through the three rules on a five-line log.
for each (pattern, replacement) in RULES: text = replace every match of patternreturn text- log
1 ERROR login failed for maria.lopez@example.com 2 db_password=hunter2-Prod! 3 Authorization: Bearer 9f8a7c6e5d4b3a2f1e0d9c8b7a6f5e4d 4 retrying in 30s (attempt 2 of 5) 5 the support login is Tulip88 for now - rule
- none yet
1The raw log. Three lines hold something sensitive: an email, a password and an access token.
- log
1 ERROR login failed for [EMAIL] 2 db_password=hunter2-Prod! 3 Authorization: Bearer 9f8a7c6e5d4b3a2f1e0d9c8b7a6f5e4d 4 retrying in 30s (attempt 2 of 5) 5 the support login is Tulip88 for now - rule
- emails
2Rule 1 matches anything shaped like
name@domain.tld. The customer's address becomes[EMAIL]. The model still knows a login failed for some user, which is all it needs. - log
1 ERROR login failed for [EMAIL] 2 db_password=[SECRET] 3 Authorization: Bearer 9f8a7c6e5d4b3a2f1e0d9c8b7a6f5e4d 4 retrying in 30s (attempt 2 of 5) 5 the support login is Tulip88 for now - rule
- name = value
3Rule 2 matches a name ending in password, secret, token or key, then
=or:, then a value. It keeps the name and hides the value, so you can still see which setting it was. - log
1 ERROR login failed for [EMAIL] 2 db_password=[SECRET] 3 Authorization: Bearer [TOKEN] 4 retrying in 30s (attempt 2 of 5) 5 the support login is Tulip88 for now - rule
- long tokens
4Rule 3 catches any unbroken run of 32 or more letters, digits,
_or-, which is what most tokens look like. "Authorization" is not in rule 2's list, so this is the rule that saves line 3. - log
1 ERROR login failed for [EMAIL] 2 db_password=[SECRET] 3 Authorization: Bearer [TOKEN] 4 retrying in 30s (attempt 2 of 5) 5 the support login is Tulip88 for now - redacted
- 3
- missed
- 1
5Done: three lines cleaned, line 4 untouched. But line 5 holds a password in plain words, and no rule has its shape. A script catches known patterns. It does not replace reading what you paste.
Security risks that come back out
Privacy is about what goes in. Security is also about what comes out, because AI output often ends up running on your machine.
- Insecure fixes. Asked to "make the error go away", a model may suggest turning off certificate checks, opening permissions wide, or building a database query by gluing strings together. Each one works, and each one opens a hole. When a fix disables a safety check, find out why the check failed instead.
- Packages that do not exist. Models sometimes suggest plausible package names that were never published. An attacker can register such a name and publish a harmful package under it. Before you install anything new, check that it is the real, maintained project.
- Commands you have not read. Read a command before you run it, especially anything that deletes, changes permissions, or downloads and runs a script in one line.
- Assistants with access. An assistant that can read your files or act on your accounts can be steered by text hidden in what it reads. Prompt Injection covers how, and why you should give such tools only the access the task needs.
Try it yourself
You want help writing a reply to this customer email. Rewrite what you would paste so the assistant can still help, but nothing personal or secret leaves your hands.
Show a sample answer
Why it works: the assistant needs the situation, not the identity. The name, email, account number and card digits added nothing to the reply and are all personal data. The temporary password was a live secret; it should not go anywhere, and it should be reset rather than reused. Adding what you are allowed to promise is extra context that makes the reply accurate.
Common mistakes
Check yourself
You realise you pasted a live API key into a chat an hour ago. What should you do first?
In the tracer, why did line 5 survive redaction?
An assistant fixes your HTTPS error by adding an option that skips certificate checks. What is the right response?
What to practise next
Look up the data settings of the assistant you use most, and write down the four answers from this lesson. Then continue with Choosing a Model, where privacy is one of the trade-offs alongside quality, speed and cost.