The OWASP Top 10 for LLM Applications (2025/2026) defines ten risk categories, from LLM01: Prompt Injection to LLM10: Model Theft. It is not a compliance standard, and there is no such thing as being “OWASP-certified.” For teams handling PHI or PII, LLM01, LLM02, and LLM06 usually pose the highest breach risk because they directly touch data leaving your control.
Key takeaways
- The OWASP LLM Top 10 is a design-risk framework; map it to your threat model, do not audit against it.
- Prompt injection and sensitive information disclosure are the most common failure points in regulated RAG deployments.
- Per-request PHI gating, region residency, and audit trails on every call reduce blast radius before you add model-level controls.
- If you use Azure routes, a BAA can cover the PHI pathway; do not claim “HIPAA-certified” for any LLM product.
What is the OWASP Top 10 for LLM Applications (2025/2026)?
The OWASP Top 10 for LLM Applications is a community-maintained list of the ten most critical security risks for LLM-powered applications. It runs from LLM01: Prompt Injection through LLM10: Model Theft. Public overviews from Cloudflare and Wiz describe how these risks appear in real model and RAG deployments.
For regulated teams, the list is useful as a threat-modeling checklist, not a legal audit. HIPAA, GDPR, and the Swiss nFADP do not reference OWASP categories. They regulate how personal and health data moves, where it is stored, and who can access it. Use the OWASP list to find where your LLM architecture might leak, then map each finding to your legal obligations. Ask your counsel about specific requirements; I am describing engineering posture, not giving legal advice.
How does prompt injection (LLM01) work, and how do you mitigate it?
Prompt injection happens when an attacker’s input overrides the system prompt and causes the model to ignore its instructions. In a direct attack, the user types the malicious instruction. In an indirect attack, the model reads poisoned content retrieved by a RAG pipeline and acts on it. Both can leak PHI or trigger unauthorized actions.
Mitigation starts with never trusting the model’s output as a command. Isolate system prompts from user input, validate inbound prompts, and scan retrieved documents before they reach the model. If your application lets users upload documents for summarization, assume those documents can contain instructions meant to hijack the model.
We handle this by treating the LLM as an untrusted intermediary. The gateway inspects the request before it reaches the model, and the response is checked before it reaches the user. That boundary matters more than the model’s internal alignment.
How does sensitive information disclosure (LLM02) expose PHI and PII?
Sensitive information disclosure occurs when an LLM returns PHI, PII, or other regulated data it saw in context, in training data, or through a retrieval pipeline. Under HIPAA and GDPR, that output can be a reportable disclosure even if the model generated it accidentally.
The risk is highest in RAG systems. If your vector database contains unredacted clinical notes and a user asks a question, the model may return a name, diagnosis, or record number in plain text. Training-data leakage is less common but still possible with fine-tuned models.
Our approach is a per-request PHI gate. The request header X-PHI-Gate: enforce tells the gateway to scan the prompt and the response for regulated identifiers before either side sees the full payload. Here is what that looks like in practice:
curl -X POST https://cloudsitus.com/api/v1/chat \
-H "Authorization: Bearer $TOKEN" \
-H "X-PHI-Gate: enforce" \
-H "X-Region: eu-west-1" \
-d '{"messages":[{"role":"user","content":"Summarize this patient note"}]}'
The response includes headers such as X-PHI-Sanitized: true and X-Audit-Id: <request-id>. We log the request ID and outcome, not the payload. For details on how the gate works, see Implementing Per-Request PHI Gates for LLM APIs: A How-To Guide. For broader leakage controls, see LLM Data Leakage Prevention in 2026: A Technical Guide to Protecting PHI and PII.
What are LLM supply chain and data poisoning risks (LLM03/LLM04)?
Supply chain and poisoning risks enter through the model weights, fine-tuning data, plugins, and the documents your RAG pipeline ingests. A compromised model or a malicious document in your knowledge base can create backdoors or leak data long after deployment.
Supply chain issues include pulling a base model from a public registry without verifying its provenance, or installing a plugin that calls external endpoints with your credentials. Data poisoning means an attacker controls part of the training or fine-tuning set and injects behavior that triggers on a specific keyword or patient ID.
Defenses are procedural as much as technical. Verify model hashes before deployment. Scan ingested documents for executable content or hidden instructions. Keep fine-tuning datasets under version control and review them for anomalous patterns. If you are fine-tuning on PHI, the data should never leave your region, and the training pipeline should not log raw payloads.
How do you stop insecure output handling and excessive agency (LLM05/LLM06)?
Insecure output handling means treating the model’s response as trusted code or data. If an LLM generates a SQL query, a URL, or HTML and your backend executes it without validation, you have an injection problem that originated in the model.
Excessive agency is when an LLM can call tools or write records without human approval. In regulated workflows, that means the model could send a patient record, submit a claim, or delete a file on its own initiative. This is where LLM security becomes an access-control problem.
Treat LLM output as untrusted user input: validate it against a schema, encode it before rendering, and never pass it directly to a database query or shell. For tool use, scope API tokens to the minimum required action and require human approval for any state-changing call. Every tool invocation should produce an audit entry. See Implementing Robust Audit Trails for LLM API Calls in Regulated Environments and Zero-Trust Architecture for LLM APIs: A 2026 Implementation Guide for Regulated Industries.
How do you implement a layered security strategy for LLM deployments?
A layered strategy assumes any single control can fail. You combine network boundaries, per-request PHI gating, input and output validation, scoped tool permissions, and immutable audit logs so that no one mistake exposes regulated data.
| Layer | Control | Example mechanism | Regulated benefit |
|---|---|---|---|
| Network | Private endpoints, VPC, region residency | Traffic stays in eu-west-1 or us-east-1 | GDPR / nFADP residency |
| Gateway | Per-request PHI gate | X-PHI-Gate: enforce header | HIPAA minimum necessary |
| Model | System prompt isolation, output validation | Reject responses containing PHI patterns | Prevent disclosure |
| Tool/agent | Human-in-the-loop, scoped tokens | Approval required for writes | Prevent excessive agency |
| Audit | Immutable logs, no payload logging | Log request ID and outcome only | HIPAA audit controls |
When to build versus buy: build your own layer if you already operate identity, API gateways, and audit infrastructure and need custom routing rules. Use a hyperscaler directly if you want a BAA on Azure routes and do not need an additional policy layer. We built CloudSitus for teams that want per-request PHI gates, region residency, and audit trails without managing the plumbing themselves. Stateless routing means we do not retain your prompts, and we do not train on your data.
FAQ
What is the OWASP Top 10 for LLM Applications in 2026?
It is OWASP’s list of the ten most critical security risks for LLM applications, updated for the 2025/2026 edition. It covers prompt injection, data disclosure, supply chain, poisoning, output handling, excessive agency, and related risks. Use it to prioritize threats, not as a compliance certificate.
How do you stop prompt injection in an LLM app?
Isolate system prompts from user input, validate and sanitize inbound prompts, and scan retrieved documents before they reach the model. Treat model output as untrusted, and never let the model execute commands based on retrieved content without checks.
Does the OWASP LLM Top 10 satisfy HIPAA or GDPR?
No. It is a security risk framework, not a legal standard. HIPAA requires a BAA for covered entities on supported routes, such as Azure, and GDPR/nFADP require region residency and lawful processing. Ask your counsel about your specific obligations.
What is excessive agency, and why does it matter for PHI?
Excessive agency is when an LLM can make tool calls or change data without human approval. In regulated workflows, the model could send a patient record or alter a claim automatically. Scope tool permissions and require human review for state-changing actions.
Should I build my own LLM security layer or use a hyperscaler?
Build if you already have identity, gateway, and audit infrastructure and need custom PHI routing. Use a hyperscaler directly if you want a BAA on Azure routes and do not need an additional policy layer. For teams that want per-request PHI gates, region residency, and audit trails without managing the plumbing, see CloudSitus.