Keep credentials, personal data, customer records, and details of unfixed vulnerabilities out of prompts unless your organization has approved that tool and its data terms for that class of data. Redact first, paste the smallest piece that answers the question, and check the vendor's retention and training settings before anything sensitive goes in.
Why this matters
OWASP's guidance on sensitive information disclosure notes that users may type sensitive information into a prompt, and that the model may later reveal it in an output. The recommended response includes educating users on what not to enter and being transparent about how data is retained, used, and deleted, including opt-outs from training.
Security work is full of exactly the material that should be handled with care: logs, configs, stack traces, tickets, and scan reports.
A short do not paste list
- Credentials of any kind. API keys, tokens, private keys, connection strings, session cookies. Logs and config files often contain them where you do not expect.
- Personal data. Names, emails, IP addresses tied to people, support transcripts, anything covered by privacy law.
- Customer data and customer names from incident or support material.
- Unpatched vulnerability details in your own products, including proof of concept code, before a fix ships. Your disclosure policy may also restrict sharing.
- Contract and audit material under confidentiality terms.
- Internal network detail such as hostnames, topology, and firewall rules, unless needed and approved.
Redact before you paste
A quick routine for logs and configs:
- Search for the usual suspects: "key", "token", "secret", "password", "authorization", "cookie", "bearer".
- Replace values with placeholders that keep the shape, such as REDACTED_TOKEN, so the model can still see where a secret sat.
- Replace identifiers with consistent fake ones (user_1, host_a) so relationships survive.
- Trim to the relevant lines. Ten lines around an error are often enough.
If a real secret does end up in a prompt, treat it as exposed and rotate it. Deleting the chat does not undo the disclosure.
Check the tool, not just the data
Three questions to settle before approving any assistant for security work:
- Is prompt content retained, for how long, and who can read it?
- Is it used for training by default, and can that be turned off for your account type?
- Can administrators see and control usage across the team?
Read the vendor's current terms. They change, and this post does not state any vendor's policy.
Prefer designs that need less pasting
A local or self-hosted model changes the data flow, though it adds its own operations work. Another option is to give an approved assistant narrow, read-only access to specific files instead of pasting, so access is logged and scoped.
Quick check
Is it fine to paste code if I remove the secrets?
Often, yes, if your policy allows the tool for source code. Source can itself be confidential, so check the policy, not just the secrets.
Sources
Last reviewed: 19 October 2026.
