LLM02 sensitive information disclosure: what should you log and alert on?

For OWASP LLM02, log who asked, which data sources were retrieved, what filters fired and the size and shape of the answer. Alert when outputs match sensitive patterns, when one user touches unusual data, or when someone repeats near identical probing. Protect the logs themselves, because they can hold the secrets.

What does OWASP say LLM02 covers?

The OWASP Top 10 for LLM Applications 2025 describes sensitive information as personal data, financial details, health records, confidential business data, security credentials, legal documents and, for proprietary models, training methods and source code. It warns that LLMs can reveal such data in their output, and that users need to understand the risk of typing sensitive data into a model.

The examples listed are personal data leakage, exposure of proprietary algorithms or data, and disclosure of confidential business information. The mitigations include sanitization, least privilege access, limiting access to external data sources, clear retention and deletion policies, hiding the system preamble, and redaction using pattern matching.

OWASP's page lists mitigations, not a logging spec. What follows is our own practical reading of how to make those mitigations observable.

What should you record?

Per request, store a record you could use in an investigation without being able to read the user's secrets.

• Identity and context. Who the user was, which application, which tenant, which session.
• Inputs, with care. Either a redacted copy of the prompt or a hash plus length. Decide this on purpose, because raw prompts can hold the very data you are trying to protect.
• Retrieval. Which documents or records were pulled in for context, by ID, not content.
• Tool calls. Which tools or external data sources the model touched, with parameters redacted.
• Filter results. Every time an input or output filter matched, what rule fired and what action followed.
• Output shape. Length, language, and whether any detector flagged it.
• Model and configuration version. So you can tie a leak to a prompt change.

What should raise an alert?

Alerts should be few and specific, or they will be muted.

1. Output pattern hits. A detector finds something that looks like a credential, a national ID number or a card number in a response.
2. Access mismatch. A response drew on documents the user is not allowed to see. This is an access control failure, not just a model problem.
3. Unusual retrieval volume. One session pulls far more records than a normal one.
4. Preamble probing. Repeated attempts to make the model repeat its instructions. OWASP lists hiding the system preamble as a mitigation, so attempts to extract it are a signal.
5. Rising filter rate. A sudden climb in blocked outputs after a model or prompt change.
6. Bulk output. Very long responses to short questions from one account.

How do you protect the logs?

Logs of prompts can become your largest store of sensitive data. Apply the same rules as for the data itself: least privilege access, redaction before storage, a retention period and deletion on request where policy requires it. OWASP lists clear policies on retention and deletion as a mitigation, and that applies to your own logs too.

A rollout order

1. List the sensitive data classes your application can reach.
2. Add detectors for the two or three highest risk classes first.
3. Log retrieval IDs and filter hits before anything else.
4. Send alerts to a named owner with a runbook.
5. Review a sample of flagged and unflagged outputs monthly.
6. Test by planting harmless canary records and confirming they trigger alerts when retrieved improperly.

What are the limits?

Pattern detectors miss paraphrased or partial data and flag harmless matches. Logging cannot prevent a leak, only shorten the time to notice and explain it. Prevention still comes from keeping sensitive data out of the model's reach and enforcing access control before retrieval.

Quick check

Sources

• OWASP GenAI: LLM02:2025 Sensitive Information Disclosure

Last reviewed: 18 October 2026.