OWASP Top 10 for LLMs and PII boundaries

Q: What is the OWASP Top 10 for LLMs?

The OWASP Top 10 for LLM Applications is a community list from the OWASP GenAI Security Project of the most critical risks in apps built on large language models. The 2025 list covers LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses, LLM09 Misinformation, and LLM10 Unbounded Consumption.

Q: What is sensitive information disclosure in LLMs?

Sensitive information disclosure (LLM02) is when an LLM application exposes PII, secrets, credentials, or confidential business data. It happens when sensitive values get into prompts, system prompts, training data, embeddings, logs, or model outputs, and then reach a party that should not see them. Examples include a model echoing a user's data to another user, secrets leaking through logs, or confidential context surfacing in a response.

Q: Does redacting PII stop prompt injection?

No. Redacting PII before the model reduces sensitive information disclosure (LLM02), but it does not stop prompt injection (LLM01) by itself. An injection attack manipulates the model's behavior with malicious instructions; it can still succeed against tokenized text. A PII boundary lowers the blast radius by limiting what an injection can exfiltrate, but you still need input and output controls, least privilege, and human review for high-risk actions.

Q: How do you prevent PII leakage to an LLM?

Keep PII out of the prompt in the first place. A PII boundary detects personal data and secrets and replaces them with stable placeholder tokens before the text reaches the model, then reveals the real values only inside your trust boundary on return. Combine that with data minimization, scoped logging, access control on the vault, and output handling so the model and provider only ever see placeholders.

·TL;DR

The OWASP Top 10 for LLMs (2025) is the standard list of the most critical risks in LLM apps, published by the OWASP GenAI Security Project.
A PII boundary like Anonde primarily addresses LLM02 Sensitive Information Disclosure: it keeps PII and secrets out of prompts, logs, embeddings, and outputs.
It also reduces the blast radius of LLM01 Prompt Injection and LLM07 System Prompt Leakage, because there is less real data to steal.
Be clear: a PII boundary does not stop prompt injection by itself. Injection manipulates model behavior, which works fine on tokenized text.
Treat a PII boundary as one control in a layered LLM security stack, alongside input and output handling, least privilege, and human review.

01The OWASP Top 10 for LLMs (2025)

The OWASP GenAI Security Project maintains the Top 10 for LLM Applications. The 2025 list:

LLM01 Prompt Injection: attacker input changes the model's behavior, directly or through content the model reads.
LLM02 Sensitive Information Disclosure: the app exposes PII, secrets, or confidential data.
LLM03 Supply Chain: risks in models, datasets, plugins, and dependencies you did not build.
LLM04 Data and Model Poisoning: tampered training or fine-tuning data corrupts behavior.
LLM05 Improper Output Handling: downstream systems trust model output without validation.
LLM06 Excessive Agency: the model has too much permission, autonomy, or tool access.
LLM07 System Prompt Leakage: the system prompt and any secrets in it get exposed.
LLM08 Vector and Embedding Weaknesses: risks in how embeddings are generated, stored, and retrieved.
LLM09 Misinformation: confident but wrong output that users act on.
LLM10 Unbounded Consumption: uncontrolled resource use, cost, or denial of service.

For the canonical definitions, see the OWASP GenAI Security Project. The rest of this post goes deep on LLM02 and its links to LLM01 and LLM07, because that is exactly where a PII boundary earns its place.

02LLM02: Sensitive Information Disclosure, up close

Sensitive information disclosure is the leak of data that should have stayed private: customer PII, employee records, API keys, tokens, internal documents, source code. In an LLM app, that data can leak through several paths at once.

Prompts. You paste a support ticket or a database row into context. The full name, email, and card number now sit in the request to a third-party model.
System prompts. Teams hardcode keys, internal URLs, or business rules into the system prompt. That is both LLM02 and LLM07.
Logs and traces. Request and response logging is on by default in most stacks. Raw PII lands in log stores, observability tools, and prompt-debugging dashboards.
Embeddings. RAG indexes the raw text. PII is now searchable in a vector store, and embeddings can leak attributes of their source text.
Outputs. The model echoes data from one user's context into another session, or surfaces confidential context it was given.

The common thread: real values travel further than they should. Once they are in a provider's request log, an embedding store, or your own observability stack, you have lost control of the blast radius.

03Where a redact-before-the-model PII boundary helps

A PII boundary moves the redaction step to the front. Before any text reaches a model, it detects PII and secrets and replaces them with stable placeholder tokens like <PERSON_1> or <EMAIL_2>. The real values are stored in a vault inside your trust boundary. On return, the tokens in the model's response are mapped back to the originals, but only inside your network.

This directly cuts LLM02 across every path above:

Prompts carry tokens, so the provider never sees the real values.
Logs and traces downstream of the boundary contain tokens, not PII.
Embeddings built from tokenized text do not encode the original identifiers.
Outputs from the model reference tokens; reveal happens only in your boundary, so a response that leaks to the wrong session leaks placeholders.

For the mechanics of doing this in front of an LLM call, see redact PII before the LLM. For the regulatory backdrop, see GDPR and LLMs.

04LLM01 Prompt Injection: what a PII boundary does and does not do

Be honest here. A PII boundary does not stop prompt injection. Injection works by feeding the model instructions that change its behavior, whether typed by a user or hidden in a document, web page, or tool result the model reads. Tokenizing PII does nothing to the instructions. The model will still follow ignore previous instructions whether the surrounding text says Jane Doe or <PERSON_1>.

What a PII boundary does change is the payoff. A classic injection goal is exfiltration: trick the model into dumping its context to an attacker. If that context is already tokenized, the attacker gets placeholders, not real names, emails, or keys. The injection may still succeed, but the data it can carry out is far less valuable. That is blast-radius reduction, not prevention.

So prompt injection still needs its own controls: input filtering, output handling (LLM05), least privilege and limited tool access (LLM06), and human review for high-risk actions. A PII boundary is a useful layer underneath those, not a replacement for them. This is why we describe Anonde as one control in a layered LLM security stack, not an LLM guard that does everything.

05LLM07 System Prompt Leakage

System prompt leakage is when the instructions that configure your app get exposed, often by an injection that asks the model to repeat them. The real harm is not the prose; it is the secrets teams put in system prompts: API keys, internal endpoints, database hints, and customer data baked into examples.

The OWASP guidance is clear that secrets should not live in the system prompt at all. A PII boundary supports that practice: if any sensitive value does end up in prompt context, it can be tokenized before the request, so a leak of the prompt reveals placeholders rather than live credentials. It does not stop the prompt from leaking, but it lowers what a leak is worth. Pair it with keeping real secrets in a secrets manager and out of prompts entirely.

06Does a PII boundary help? The honest map

OWASP LLM risk	PII boundary helps?	Why
LLM01 Prompt Injection	Partly	Does not prevent injection; reduces what an exfiltration injection can steal.
LLM02 Sensitive Information Disclosure	Yes	Keeps PII and secrets out of prompts, logs, embeddings, and outputs.
LLM03 Supply Chain	No	Different problem: vet models, datasets, and dependencies.
LLM04 Data and Model Poisoning	No	Concerns training data integrity, not inference-time data flow.
LLM05 Improper Output Handling	Partly	Reveal-on-return is a controlled output step, but you still must validate output.
LLM06 Excessive Agency	No	Permissions and tool scope need their own least-privilege controls.
LLM07 System Prompt Leakage	Partly	Tokenizes any sensitive values in prompts; does not stop the leak itself.
LLM08 Vector and Embedding Weaknesses	Partly	Indexing tokenized text keeps PII out of the vector store.
LLM09 Misinformation	No	Output accuracy is unrelated to data redaction.
LLM10 Unbounded Consumption	No	Rate limits and quotas are a separate control.

Risk names follow the OWASP GenAI Security Project Top 10 for LLM Applications (2025). The verdicts are our own honest read of where a PII boundary applies.

07One control in a layered stack

The map makes the role clear. A PII boundary is the right tool for LLM02, and it quietly improves LLM01, LLM05, LLM07, and LLM08 by limiting how much real data is in play. It does nothing for supply chain, poisoning, agency, misinformation, or consumption. Those need their own controls.

That is the point of layered LLM security. No single tool covers the Top 10. A PII boundary covers the data-exposure layer well, so you can put real effort into injection defenses, output handling, and least privilege without also carrying the risk that every prompt, log line, and embedding is full of live customer data.

08FAQ

What is the OWASP Top 10 for LLMs?

A community list from the OWASP GenAI Security Project of the most critical risks in LLM apps. The 2025 list runs from LLM01 Prompt Injection through LLM10 Unbounded Consumption, with LLM02 Sensitive Information Disclosure and LLM07 System Prompt Leakage in between.

What is sensitive information disclosure in LLMs?

LLM02: when an app exposes PII, secrets, or confidential data through prompts, system prompts, logs, embeddings, or outputs, and that data reaches a party that should not see it.

Does redacting PII stop prompt injection?

No. Redaction reduces sensitive information disclosure but does not stop prompt injection. Injection manipulates model behavior, which works on tokenized text too. A PII boundary lowers the blast radius by limiting what an injection can exfiltrate.

How do you prevent PII leakage to an LLM?

Keep PII out of the prompt. A PII boundary detects personal data and secrets and replaces them with placeholder tokens before the text reaches the model, then reveals real values only inside your trust boundary. Add data minimization, scoped logging, and vault access control.

·Try Anonde

See how it works, try the live demo, or read the quickstart to run Anonde on your own infrastructure.

OWASP Top 10 for LLMs: where a PII boundary fits