Sensitive information disclosure (OWASP LLM02:2025) is when an LLM or the application around it exposes personal data, credentials, confidential business data or proprietary details. Control it by cleaning data before it reaches the model, limiting what the model can read, redacting outputs, and telling users what not to enter.
What counts as sensitive?
OWASP lists personal identifiable information, financial details, health records, confidential business data, security credentials and legal documents. Proprietary training methods and source code can also be sensitive. Disclosure can lead to unauthorized data access, privacy violations and intellectual property breaches.
Two points deserve attention. Sensitive information can exist in the model itself and in the application around it. And data users type in may later appear in model output, so the input path is part of the risk.
What does it look like in practice?
OWASP's examples are PII leakage during interactions, exposure of proprietary algorithms or training data through poorly configured outputs, and business data appearing in responses. It cites the Proof Pudding case (CVE-2019-20634), where disclosed training data enabled model extraction and inversion and helped attackers bypass email filters.
Its attack scenarios are plain: a user receives another user's personal data because input was not sanitized, an attacker bypasses input filters to extract sensitive data, or sensitive data included in training without care later surfaces in outputs.
Which controls does OWASP recommend?
- Sanitization. Scrub or mask sensitive content before it enters training data, and validate and filter inputs.
- Access controls. Apply least privilege so users and processes see only what they need, and restrict the model's reach into external data sources.
- Privacy techniques. Federated learning, differential privacy and homomorphic encryption are listed as options.
- Tokenization and redaction. Detect confidential content with pattern matching and redact it before processing.
- User education and transparency. Teach users not to enter sensitive data, publish retention and deletion policies, and let users opt out of training.
- Secure configuration. Limit overrides of system settings, and avoid leaking details through error messages and configuration.
- System prompt restrictions. Instructions about permissible data can help but can be bypassed, so they must not be the sole control.
What is the checklist?
Before the model
- Do you know which data classes can enter prompts, retrieval indexes and training sets?
- Is sensitive content masked or removed before it enters them?
- Is there a documented rule on what staff may paste into an assistant?
Around the model
- Does retrieval respect the asking user's permissions, not the app's?
- Is the model's access to external data sources limited to what the task needs?
- Are credentials kept out of prompts, indexes and logs?
After the model
- Do outputs pass a redaction check for patterns such as credentials and personal data?
- Do error messages avoid leaking configuration?
Policy
- Are retention, training use and deletion terms written down, and do you know the provider's terms?
- Is there an opt out path, and a way to answer a data subject request?
What to do
- Classify your data and decide which classes may reach an AI system at all.
- Fix retrieval permissions first. A shared index with no per user filtering is the likeliest cause of cross user exposure.
- Add automated secret and personal data detection on prompts, documents and outputs.
- Remove credentials from prompts and configuration files, and rotate any that were exposed.
- Write the staff rule in one page and train people on it.
- Review provider terms for retention and training use, and record the outcome.
- Test with realistic fake data: ask for another user's records and check the answer.
Where Safeguard fits
Secrets scanning checks repositories for credentials that could end up in prompts or agent configuration. Safeguard also supports running with Zero AI, with your own model, or with Full AI, so you can choose where data goes. These do not replace data classification and retrieval access control in your own applications.
Quick check
Can I rely on a system prompt that says never reveal personal data?
No. OWASP says such instructions can be bypassed through prompt injection, so use them only alongside access controls and redaction.
What is the most common cause of cross user leaks?
OWASP's scenarios include one user receiving another's data because input was not properly sanitized. In retrieval systems, missing per user permission filtering is the practical equivalent to check first.
Sources
Last reviewed: 18 October 2026.
