OWASP LLM02, sensitive information disclosure, covers personal data, credentials, confidential business data and proprietary details that surface through an LLM application. For compliance, it touches privacy law, security management standards and AI governance. Each OWASP mitigation lines up with a control family auditors already know.
What does LLM02 cover?
OWASP defines it broadly: personal identifiable information, financial details, health records, confidential business data, security credentials and legal documents, plus proprietary training methods and source code. Its common vulnerabilities are PII leakage, exposure of proprietary algorithms, and disclosure of business data in generated responses.
One point deserves attention. OWASP notes that restrictions placed in a system prompt may be bypassed through prompt injection, so they should not be relied on alone.
How do the mitigations map?
This is a working aid, not an official crosswalk. Confirm exact clauses against the framework versions you use.
Sanitization, masking and input validation map to data protection by design and to data minimization in privacy law, and to data classification and handling controls in security standards. The evidence is a record of what is scrubbed before training or retrieval, and the tests that prove it.
Least privilege access to data maps to access control families. The evidence is the list of data sources the model can reach, and the permissions each connection holds. OWASP recommends limiting model access to external data and managing runtime data orchestration securely.
Privacy techniques such as differential privacy, federated learning, tokenization and redaction map to the technical measures privacy laws mention, like pseudonymisation and encryption. Evidence: design notes and test results showing the technique is active.
User education, retention policies and opt outs map to transparency, notice and consent duties. OWASP suggests telling users not to enter sensitive data, publishing clear retention and usage policies, and letting users opt out of training.
Secure configuration maps to configuration management. OWASP points to security misconfiguration guidance so that errors and settings do not leak details.
What would an auditor ask?
Expect questions like these. What sensitive data can the application see? How do you prevent it from reaching the model, or from leaving it? Who can read prompts and outputs in your logs? How long do you keep them? Can a user ask for deletion, and does it reach the places prompts are stored?
The log question surprises teams. Logs of prompts and answers often hold the very data you are protecting, so apply retention limits and access controls to them.
Where does software supply chain come in?
Credentials in code, prompts, or config are part of LLM02. Secrets scanning in your repositories and pipelines keeps keys out of places a model or a retrieval system can read. Our secrets scanning and compliance mapping can feed evidence for this. They do not decide your legal obligations.
What to do
- Inventory the data your LLM applications can see, by system and sensitivity.
- Mask or remove sensitive fields before they reach prompts, training sets or indexes.
- Give the application the narrowest data permissions it needs.
- Scan repositories, prompts and configs for credentials.
- Set retention and access rules for prompt and output logs.
- Publish a plain notice on what users should not enter, with an opt out where you can offer one.
- Test with synthetic sensitive data each release and keep the results.
Quick check
Can a system prompt stop disclosure?
Not on its own. OWASP notes that such restrictions can be bypassed through prompt injection, so use data controls as well.
Do logs count as part of the problem?
Yes. Prompt and output logs can contain sensitive data, so they need access limits and retention rules.
Sources
Last reviewed: 18 October 2026.
