OWASP's LLM02 risk covers any case where a model or its application exposes data it should not: personal data, credentials, business secrets or proprietary code. The controls that hold up are upstream of the model: sanitize what goes in, restrict what the model can reach, and never rely on a prompt instruction as the only guard.
What does LLM02 actually cover?
OWASP's 2025 entry describes sensitive information as personal data, financial details, health records, confidential business data, security credentials and legal documents. For proprietary models it also includes training methods and source code. The leak can come from the model's output, from its training data, or from a user pasting something sensitive that later resurfaces.
OWASP lists three example scenarios: unintentional data exposure to the wrong user, targeted prompt injection, and leakage through training data. Notice that two of the three are about data plumbing, not clever attacks.
Which controls work?
OWASP's mitigation list is practical when you sort it by where it acts.
Before the model sees data. Sanitize and mask sensitive content so user data does not flow into training. Apply input validation to catch sensitive material. Pattern-based redaction and tokenization, which OWASP lists under advanced techniques, belong here too. A credit card number that never reaches the model cannot be repeated by it.
Around the model. Enforce least privilege on every data source the model can query. If a retrieval pipeline can read the whole document store, any user can eventually ask for any document. Scope retrieval to the caller's own permissions, not the application's.
In how you run it. Keep clear policies on retention, usage and deletion, let users opt out of training, and limit who can read or override the system preamble. OWASP also points to API security misconfiguration guidance, because verbose errors leak configuration details.
Which controls do not work alone?
OWASP says system prompt restrictions on data types may be bypassed through prompt injection, so they should not be the only control. A line saying "never reveal customer emails" is a request, not an enforcement point.
The same is true of user education on its own. Telling staff not to paste secrets helps, but it fails the first time someone is in a hurry. Pair it with redaction at the boundary.
Advanced techniques such as differential privacy and federated learning reduce what a trained model memorizes. They matter if you train or fine-tune. If you only call a hosted model, your levers are the input and access controls above.
A short example
Picture an internal support assistant that answers from a ticket archive. Tickets contain customer names, and some contain API keys that customers pasted. If the assistant retrieves from the whole archive, a junior agent can surface another customer's key by asking the right question.
The fix is not a better prompt. Redact keys and personal fields when tickets are indexed, filter retrieval by the agent's team, and log what was retrieved. The prompt then becomes a last layer, not the first.
What to do
- Inventory every data source your LLM application can read, and who can read it today.
- Redact credentials and personal data at ingestion, before indexing or training.
- Scope retrieval to the caller's permissions, not the service account's.
- Treat the system prompt as public. Keep no secrets in it.
- Trim error messages so they do not expose configuration.
- Write a retention and opt-out policy for prompts and outputs, and publish it to users.
- Test with your own red team prompts that try to extract data across user boundaries.
Quick check
Is a system prompt rule enough to stop data leaks?
No. OWASP notes that restrictions in the system prompt may be bypassed through prompt injection. Use it as one layer behind redaction and access control.
Do I need differential privacy if I only call a hosted model?
Usually not. Those techniques address training. For hosted use, focus on what you send in and what the model can retrieve.
Sources
Last reviewed: 18 October 2026.
