Chapter 8: Security & Sensitive Data: Sanitize, Don't Paste Secrets

Series: LLM Development Guide

Chapter 8 of 15

Previous: Chapter 7: Choosing the Right Model: Capability Tiers, Not Hype

Next: Chapter 9: Stop Rules + Pitfalls: When to Upgrade, Bail, or Go Manual

What you’ll be able to do

You’ll be able to use LLMs without doing something reckless:

• Apply a concrete “never paste” list.
• Sanitize code, config, and logs into safe examples.
• Add a verification step so you don’t ship secrets.

TL;DR

• Assume anything you paste could be logged or retained.
• If you wouldn’t publish it publicly, don’t paste it.
• Replace real values with placeholders.
• Sanitize logs aggressively.
• Verify your workspace for leaked secrets before you commit.

Table of contents

• The core principle
• Never paste list
• Sanitization patterns
• Verification
• Failure modes

The core principle

Assume anything you send to an LLM could be stored.

Even with enterprise offerings, policies change. Check vendor policy as of 2026-02-14 (and your organization’s approved tools list) before using any tool with internal data.

Never paste list

Do not paste:

• Credentials: API keys, tokens, passwords, private keys.
• PII: customer names, emails, addresses, health data.
• Production data: real records, full dumps, support tickets.
• Security configs: firewall rules, IAM policies, internal IPs.
• Proprietary secrets: unreleased product details, trade secrets.

Use the “Would I post this publicly?” test.

Sanitization patterns

Replace sensitive values with descriptive placeholders.

Go example:

// Before (do not paste)
// db, err := sql.Open("postgres", "host=prod-db.internal user=admin password=SuperSecret123 dbname=customers")

// After (safe to paste)
db, err := sql.Open("postgres", "host=DATABASE_HOST user=DATABASE_USER password=DATABASE_PASSWORD dbname=DATABASE_NAME")
if err != nil {
	return err
}

YAML example:

# Before (do not paste)
# data:
#   api-key: YWN0dWFsLWFwaS1rZXktaGVyZQ==

# After (safe to paste)
data:
  api-key: <BASE64_ENCODED_API_KEY>
  webhook-secret: <BASE64_ENCODED_WEBHOOK_SECRET>

Logs:

• Remove emails.
• Replace internal hostnames.
• Replace IPs with documentation ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24).

Verification

Before you paste or commit, search your workspace for obvious secret patterns.

These commands are noisy, but useful:

# High-signal patterns.
rg -n "(AKIA[0-9A-Z]{16}|BEGIN (RSA|OPENSSH) PRIVATE KEY|xox[baprs]-|ghp_[A-Za-z0-9]{36})" . || true

# Common key/value names.
rg -n "(?i)(api[_-]?key|secret|token|password)\s*[:=]" . || true

# Emails (often indicates logs or real data got copied).
rg -n "[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}" . || true

# Check staged changes specifically.
git diff --cached

Expected results:

• No obvious credentials or private keys appear in diffs.
• If matches exist, sanitize and regenerate the example.

Failure modes

• Sharing real logs that contain tokens in URLs.
• Copying a Kubernetes Secret verbatim.
• Letting an IDE plugin send your whole file without noticing.
• Assuming “enterprise” means “no risk” without verifying current policy.

Continue -> Chapter 9: Stop Rules + Pitfalls: When to Upgrade, Bail, or Go Manual