12.4 Handling sensitive data responsibly

The core principle: minimize and protect

Sensitive data handling is mostly two habits:

• Minimize: send as little sensitive data as possible.
• Protect: what you must handle should be access-controlled, redacted, and retained carefully.

Classify what is sensitive

Examples of sensitive categories (varies by domain):

• API keys, tokens, credentials
• PII (emails, names, addresses, phone numbers)
• financial data
• health data
• proprietary company documents
• customer tickets with identifying details

You can’t protect what you don’t recognize, so classification is step one.

Minimize what enters prompts

Prefer to send:

• summaries instead of full documents,
• redacted content instead of raw content,
• metadata (counts, lengths, categories) instead of payloads,
• IDs that your system can resolve server-side instead of raw records.

Minimization reduces risk and reduces token cost.

Secrets hygiene (practical rules)

• Never paste secrets into prompts.
• Never commit secrets to git.
• Store secrets in environment variables or a secret manager.
• Rotate on leak. Assume leaks happen.
• Use least privilege. Keys should be scoped to minimal permissions.

Logging and redaction

Logs are one of the most common leak vectors. Rules that work:

• log metadata by default,
• redact by default (allowlist fields to log),
• never log raw prompts or raw user inputs in production unless required and controlled,
• treat debug logging as temporary and access-controlled.

Retention and access control

Have answers for:

• Who can access prompt logs and outputs?
• How long are they retained?
• How are they deleted?
• How are they encrypted and audited?

Even for small apps, basic retention discipline prevents long-term risk.

Where to go next

• 12.5 Audit trails
• Reference: tooling basics