LLM Security Risks: The OWASP Top 10 and How to Defend

LLM security risks have moved from research curiosity to active operational concern. Large language models now sit inside corporate chat assistants, autonomous code reviewers, customer-facing support bots, and security operations tools, and the attack surface they introduce is poorly understood by defenders still calibrated to traditional application threats. Standard application security controls were never designed to catch prompt injection, data poisoning, or excessive agency.

Three authoritative references map this landscape: OWASP’s Top 10 for Large Language Model Applications, updated for 2025 by a community of more than 600 security experts; NIST AI 600-1, a generative AI risk profile published in July 2024; and MITRE ATLAS, which maps adversarial AI techniques into an ATT&CK-style taxonomy. Together they give security practitioners a structured vocabulary for what can go wrong and where to focus defenses. Tech Sentinel’s AI security threat intelligence hub indexes the incident coverage that sits behind each of these categories.

The OWASP Top 10 for LLMs: What Is on the List

OWASP’s working group, drawing on real-world deployment data, identified ten risk categories for LLM applications in 2025. The list reflects both novel AI-specific threats and familiar application security problems that manifest differently when a language model is in the chain:

1. Prompt Injection — Malicious or accidental user input alters LLM behavior, bypassing safety guidelines or extracting sensitive data.
2. Sensitive Information Disclosure — Models expose confidential data from training sets, context windows, or connected systems.
3. Supply Chain — Compromised pre-trained models, datasets, or third-party plugins introduce vulnerabilities before deployment.
4. Data and Model Poisoning — Tampered training or fine-tuning data shapes model outputs to serve attacker goals.
5. Improper Output Handling — LLM outputs passed downstream without sanitization enable injection attacks in connected systems (SQL injection, XSS, command injection).
6. Excessive Agency — Models granted broad tool access or autonomous action capabilities create high-impact blast radii when manipulated.
7. System Prompt Leakage — Confidential instructions embedded in system prompts are extracted through adversarial queries.
8. Vector and Embedding Weaknesses — Security gaps in retrieval-augmented generation (RAG) pipelines enable data poisoning through vector stores.
9. Misinformation — Models produce false or misleading content, including fabricated citations, with high apparent confidence.
10. Unbounded Consumption — Uncontrolled resource usage leads to denial-of-service conditions or financial exploitation through excessive API calls.

Prompt Injection: Still the Primary Attack Vector

Prompt injection holds the top position because it is structurally difficult to eliminate and because it is the mechanism through which nearly every other category of harm is triggered. The vulnerability is rooted in how LLMs process instructions: the model cannot reliably distinguish between legitimate operator directives and attacker-supplied instructions embedded in user input or external content. Published benchmark data puts attack success rates between 50 and 84 percent depending on system configuration.

Direct injection is the simpler variant, where an attacker crafts input that overrides the system prompt or manipulates the model into producing prohibited output. Indirect injection is more dangerous in production. Here, an LLM processing external content (web pages, documents, emails, API responses, metadata in an uploaded file) encounters hidden instructions embedded in that content and executes them as if they came from a trusted source. No user interaction is required.

Microsoft documented this class of attack in detail in July 2025, describing how an attacker with no direct system access can embed malicious instructions in a document or webpage that a corporate AI assistant will later process. In one documented scenario involving Microsoft 365 Copilot, a specially crafted email triggered the AI to autonomously exfiltrate corporate data without any user action. Microsoft’s response involves three defensive layers: system prompt hardening using “Spotlighting” (marking untrusted content with explicit delimiters), Prompt Shields (an AI classifier trained on injection patterns), and deterministic blocking of known data exfiltration methods.

In agentic deployments the consequences are proportionally worse, which is the pattern behind the 2026 incidents examined in how AI agents are rewriting the threat model. A prompt-injected agent with tool access can exfiltrate data, trigger API calls, send emails, or modify files before any human sees the output. The MITRE ATLAS framework, updated to 16 tactics and 84 techniques as of late 2025, now explicitly covers agentic AI technique chains, reflecting how quickly this attack surface has matured.

The primary mitigations are privilege separation (give agents the minimum tool access needed), contextual output inspection (validate what the model is about to do, not just what it says), and treating retrieved content as untrusted input from a potential adversary. The full taxonomy of injection techniques, including RAG poisoning, multimodal attacks, and base64-encoded obfuscation, is covered in depth at promptinjection.report, with offensive technique developments tracked at aisec.blog.

Data Poisoning and Supply Chain Risk

Data and model poisoning attacks (LLM04) target the model before it reaches production. An attacker who can influence training, fine-tuning, or embedding data can introduce subtle biases, degrade output reliability broadly, or plant targeted backdoors that activate on specific trigger phrases. The same attack class against non-generative models, along with the NIST and NCSC taxonomies that name it, is covered in the machine learning security breakdown.

The supply chain risk (LLM03) is closely related and increasingly targeted alongside it. Most organizations deploying LLMs rely on foundation models from third-party providers, fine-tuned on proprietary data and extended with third-party plugins or tool integrations. The OWASP 2025 guidance notes that supply chain risk extends beyond the base model to include plugins, fine-tuning datasets, vector database providers, prompt templates, and the inference infrastructure itself. An organization that carefully evaluates a base model but ingests fine-tuning data from an unvetted source has inherited an opaque risk.

Concrete controls for both: maintain a software bill of materials (SBOM) for all AI components; audit dataset provenance before any fine-tuning run; pin model versions and validate hashes on load; isolate inference environments from production databases; and apply code-level access controls to the vector store powering any RAG system. NIST AI 600-1 specifically flags supply chain provenance as a priority risk category and recommends attestations on training data sourcing. For teams building on open-source models, adversarialml.dev tracks active research on poisoning attacks and detection techniques.

Sensitive Information Disclosure and Improper Output Handling

LLM02 (Sensitive Information Disclosure) covers the failure mode where models disclose confidential content, whether training data, PII, or API credentials, through their responses. This is not theoretical: membership inference attacks have recovered verbatim training examples from production models, and the closely related system prompt extraction problem (tracked separately in 2025 as LLM07, System Prompt Leakage) remains persistent across commercial LLM APIs.

LLM05 (Improper Output Handling) is the adjacent problem. The model’s output is routed directly into a downstream component such as a SQL engine, a shell, or a web renderer without validation, and classic injection categories re-emerge when LLM output is treated as trusted data.

SentinelOne’s LLM security guidance recommends output scanning layers that block PII leakage and flag data exfiltration patterns before responses reach end users. For teams monitoring model behavior in production, sentryml.com covers drift detection and anomalous-output monitoring that can surface these disclosure patterns early.

Excessive Agency: The Expanding Blast Radius

OWASP expanded its coverage of excessive agency (LLM06) significantly for the 2025 list, reflecting agentic architectures that barely existed when the original 2023 list shipped. When a model is granted the ability to call APIs, read mailboxes, write to databases, execute code, or spawn subprocesses, a successful prompt injection escalates from data disclosure to full system compromise, at machine speed.

The risk is compounded by how agency is typically scoped. Development teams often grant broad permissions during prototyping and never tighten them for production. A model that can read any file in a directory, call any endpoint in a service, or send messages to any recipient is a high-value target for attackers who know how to issue the right instructions.

Least-privilege tool access is the primary mitigation. Each tool an LLM agent can invoke should be scoped to the minimum necessary permissions, high-impact actions should require explicit human confirmation, and every tool invocation should be logged to an immutable audit trail the model cannot modify. Teams deploying guardrail layers to enforce these controls can find comparative tooling coverage at guardml.io.

LLM09 (Misinformation) is the human-factors complement. The 2025 entry reworked the 2023 “Overreliance” category to center on confident, fabricated, or unverified model output. Security teams that accept LLM-generated analysis such as threat reports, vulnerability assessments, or code reviews at face value without independent verification are introducing a new class of decision-making risk into their workflow.

Defense in Depth: What Actually Reduces Exposure

No single control addresses the full LLM security risk surface. Effective deployments layer multiple controls:

• Input validation and output sanitization — treat LLM inputs as untrusted user data and LLM outputs as untrusted content before passing them to downstream systems. Apply layered pattern matching plus adversarial prompt classifiers on every channel through which data reaches an LLM, including retrieved documents in RAG pipelines.
• Privilege scoping — constrain what tools and data the model can access based on session context and user role.
• Architectural isolation — keep sensitive data out of contexts that process untrusted external content; maintain clear trust boundaries between system prompts and user-supplied data.
• Monitoring and anomaly detection — log all model interactions and flag unusual patterns such as unexpected tool calls, abnormal output formats, or high-volume API consumption. sentryml.com covers the MLOps observability layer that makes this practical at scale.
• Red-teaming and adversarial testing — run structured adversarial evaluations against deployed models before and after updates, using the frameworks catalogued at aisecbench.com.

The NIST AI 600-1 profile adds governance requirements on top of technical controls: documented risk assessments, content provenance tracking, incident disclosure procedures, and pre-deployment testing against defined threat models.

Five actionable priorities, ordered by impact

1. Audit LLM tool access now. Map every permission granted to each LLM-based application or agent. Remove anything not strictly required. Document what remains and who authorized it.
2. Treat LLM input as untrusted, always. Validate on every ingress channel, including autonomously retrieved content.
3. Scan outputs before they reach downstream systems. Block model output from flowing directly to SQL, shell, or HTML rendering without structured validation.
4. Inventory the AI supply chain. Enumerate base models, plugins, fine-tuning datasets, and vector database providers, then apply the same vendor risk management process used for software dependencies.
5. Log tool invocations in agentic systems. Ensure any autonomous action is recorded in a tamper-evident log with enough context to reconstruct the input that triggered it.

The common thread across all guidance is that LLMs require security controls that operate at the semantic level, not just the syntactic. Standard WAF rules and input length limits catch the easy cases. The harder cases, an indirect injection hidden in a PDF summary or a poisoned embedding quietly shaping retrieval results, require controls built to understand what the model is doing, not just what bytes it is receiving. For incident and vulnerability tracking as new LLM exploits emerge, ai-alert.org maintains a running tracker of disclosed AI security incidents.