Secure Prompting: Never Leak What You Analyze
Here is a trap that catches even experienced people: you use AI to analyze a security problem, and in doing so you paste sensitive data into a tool you don't control. The analysis was defensive, but the act of pasting became a leak. This lesson teaches you to use AI powerfully without ever creating a new incident. It's the most important professional habit in the whole course.
What You'll Learn
- Why pasting data into a chatbot can itself be a security risk
- What is safe to share and what must always be removed first
- How to "sanitize" real data so you keep the analysis but lose the secrets
- A simple pre-flight checklist to run before every security prompt
Why the Chatbot Window Is a Boundary
When you type into a public AI tool, your text leaves your computer and travels to a company's servers. Depending on the tool and its settings, that text may be stored, used to improve the model, or reviewed by staff. That's completely fine for "explain what a SIEM is." It is not fine for "here's our customer database and admin password."
Think of the chat box as an exit door from your organization. Anything you push through it has, in a sense, left the building. The question to ask before every prompt is simple: "Would I be comfortable if this exact text appeared on a public website?" If the answer is no, you must sanitize it first.
What Is Sensitive?
You don't need the analysis to include real secrets. The AI can reason about the shape of a problem without the actual values. Treat the following as sensitive and remove or fake it before pasting:
- Credentials: passwords, API keys, tokens, private keys, session cookies
- Personal data (PII): real names, emails, phone numbers, addresses, national ID numbers, dates of birth
- Financial data: card numbers, bank accounts, invoices tied to real people
- Internal identifiers: real internal hostnames, internal IP ranges, employee IDs, ticket numbers
- Health or legal records: anything covered by privacy law
The good news: none of these are usually needed for the AI to help. It cares about patterns, not the literal secret.
Sanitizing: Keep the Pattern, Drop the Secret
Sanitizing (also called redacting or anonymizing) means replacing sensitive values with harmless placeholders while preserving the structure. The AI still sees "a login from an internal IP by a user account," it just doesn't see the real one.
Here's a real before-and-after. Before (do not paste this):
User john.smith@acmebank.com (employee ID 48213) logged in from
203.0.113.44 using password Summer2024! to server DB-PROD-07
After (safe to paste):
User <USER_A>@<COMPANY> (employee ID <ID>) logged in from
<EXTERNAL_IP> using <REDACTED_PASSWORD> to server <SERVER_1>
The analysis you get ("a user logged in from an external IP to a production database, which is worth investigating") is identical, but you've leaked nothing. Notice the password was removed entirely. You never need to paste a real password to analyze an event, ever.
A quick tip: keep the same placeholder for the same value. If <USER_A> appears three times, the AI can still reason "the same user did all three things."
Try It Now: Practice Redacting
Take this fictional log line and rewrite it with placeholders before doing anything else. Then paste the sanitized version into an AI with this prompt:
Sample line (already fictional, but practice sanitizing it anyway):
Failed login for admin@example.com from 198.51.100.9,
then success 4 seconds later with token abc123XYZ.
Task: I've replaced any real values with placeholders. As a SOC
analyst, tell me what this pattern might indicate and whether it's
worth investigating. Explain your reasoning.
You just did the core secure-prompting move: analyze the pattern, not the secret.
Let AI Help You Sanitize
You can even ask the AI to do the redaction for you, using a fictional sample. A handy prompt:
Rewrite the text below by replacing any emails, IP addresses,
usernames, passwords, tokens, and ID numbers with clearly labeled
placeholders like <EMAIL_1>, <IP_1>. Keep the structure identical.
Then show only the redacted version.
Text: [paste a fictional sample]
Practice this on fake data until it's second nature, so that with real data you redact automatically.
Choose the Right Tool and Settings
Not all AI usage is equal:
- Free public chatbots are great for learning and for sanitized data.
- Turn off training/history where the tool allows it (many have a "don't use my data for training" setting or a temporary chat mode). This reduces, but does not eliminate, risk.
- Enterprise or business tiers (like ChatGPT Enterprise or a company-approved Claude/Gemini deployment) often promise not to train on your data. If your workplace provides one, use it for internal work and still follow your company's policy.
- When unsure, ask. Your organization's security policy always wins over anything in this course.
Your Pre-Flight Checklist
Run this in your head before hitting Enter on any security prompt:
- Does this text contain credentials, PII, or internal identifiers?
- If yes, have I replaced them with placeholders?
- Would I be okay if this appeared publicly?
- Am I using an approved tool with the right privacy settings?
- Does the analysis actually still work with placeholders? (It almost always does.)
Five seconds of checklist prevents a career-defining mistake.
Key Takeaways
- The chat box is an exit door from your organization; anything you paste may be stored or reviewed.
- Never paste real credentials, personal data, financial data, or internal identifiers.
- Sanitize by replacing secrets with consistent placeholders while keeping the pattern intact; the analysis stays just as useful.
- You never need a real password to analyze a login event.
- Run a five-point pre-flight checklist before every security prompt, and follow your company's policy above all.

