Logging LLM interactions without leaking sensitive data

Log enough to investigate abuse, and no more. Record metadata, tool calls and policy decisions by default, redact or tokenise sensitive fields before storage, restrict who can read raw prompts, and set a short retention period. OWASP recommends security logging that excludes sensitive data.

The tension

OWASP repeatedly recommends monitoring: detecting unusual output patterns, tracking resource use, and alerting on suspicious retrieval or tool activity. But prompts and responses can contain PII, credentials and confidential business data. A log store full of raw conversations becomes the most attractive target in your estate.

What to record by default

• Timestamp, user or key identifier, session identifier.
• Model and version, prompt template version.
• Token counts and latency, which support consumption monitoring.
• Tool calls: name, arguments in redacted form, result status.
• Policy and guardrail decisions: allowed, blocked, escalated, and why.
• Source labels for retrieved content, such as document identifiers.
• Flags: encoding attempts, markup in output, rate limit hits.

The OWASP cheat sheet lists tracking of encoding attempts, HTML injection and tool usage as useful signals.

What to redact or avoid storing

• Credentials, tokens and keys. Never log them, and scan logs for key patterns.
• Personal identifiers. Use tokenisation or pattern based redaction, which OWASP mentions as a way to handle sensitive content before processing.
• Full retrieved documents. Store identifiers, not content.

When you need raw text

Sometimes an investigation needs the exact prompt. Allow it, but gate it:

1. Raw capture is off by default, or sampled.
2. Access requires a named role and is itself logged.
3. Raw records expire quickly, on a schedule you can state to customers.
4. Encrypt them and keep them away from general analytics tools.

Make retrieval auditable

For RAG, OWASP recommends detailed, immutable logs of retrieval activity. Immutable matters: if an attacker can edit the log, they can hide the leak. Store which user queried, which chunks were returned and under which permission filter.

Align with your privacy commitments

Check that your retention and access rules match what your privacy notice and customer contracts say. If a user can opt out of training, make sure logs are not a back door into training data.

Safeguard's compliance and evidence automation can help document these controls for customer reviews.

Review the logs themselves. Treat the log store as a system in scope. Search it for credentials and personal data on a schedule, using patterns, and fix the code path that wrote them. Confirm that exports to analytics tools respect the same redaction. A logging design that is sound on paper often leaks through one debug statement left on in production.

Quick check

Sources

• OWASP LLM Prompt Injection Prevention Cheat Sheet
• OWASP GenAI: LLM08 Vector and Embedding Weaknesses
• OWASP GenAI: LLM02 Sensitive Information Disclosure

Last reviewed: 19 October 2026.