LLM security risks

LLM security is the work of stopping a language model application from leaking data, taking harmful actions or being abused. The reference list is the OWASP Top 10 for LLM Applications, whose 2026 edition was published August 4, 2026. Its preface gives the goal: “Stop trying to build a model that cannot be fooled. Build the system around it, so that when the model is fooled, and it will be, nothing important breaks.”

The ten risks, grouped by where they live

Each entry is explained on its own in OWASP Top 10 for LLM applications. A flat list hides where to act. The table below keeps OWASP’s 2026 order and adds the part of your system where each risk shows up. The “where” column is our own grouping. The definitions come from OWASP’s entries.

Rank	Risk	Where it lives	What it is
LLM01	Prompt Injection	Input	Input of any kind, including retrieved content and tool output, that changes model behavior in ways the developer did not intend. See prompt injection.
LLM02	Sensitive Information Disclosure	Data	Confidential data exposed through a channel its owner did not authorize, not only the final answer.
LLM03	Excessive Agency	Actions	Damaging actions taken on unexpected, ambiguous or manipulated model output.
LLM04	Supply Chain	Build	Tampered or substituted models, datasets, adapters, conversion pipelines and deployment platforms.
LLM05	Data and Model Poisoning	Build	Manipulated data or model artifacts that embed harmful behavior.
LLM06	Unbounded Consumption	Runtime cost	Excessive, uncontrolled inference that causes outages, runaway cost or model cloning.
LLM07	Misinformation	Output	Incorrect or unsupported output that is trusted and acted on.
LLM08	Hidden Context Exposure	Data	Extraction of the system prompt, retrieved policy text, tool schemas and other context users should not see.
LLM09	Vector and Embedding Weaknesses	Data	Risks in any app using embeddings and similarity search, such as RAG, agent memory and semantic caches.
LLM10	Improper Output Handling	Output	Model output passed downstream without validation or sanitization.

Source for the ranks and names: OWASP README. Entry text: LLM04, LLM05, LLM07, LLM08, LLM09, LLM10.

What changed in 2026

The preface says the team tested the practitioner vote against incident data for the first time. It collected 7,714 real incidents and sorted the 6,639 with enough detail. The vote carries three-quarters of the weight and the incidents one quarter (OWASP preface).

Three moves matter for builders:

• Excessive Agency climbed to third, which OWASP calls the most consequential move on the list.
• Unbounded Consumption rose four places.
• Improper Output Handling fell furthest, from fifth to tenth.

OWASP’s reason for the Excessive Agency move is that the vote and the incident record both point to agentic deployments as where damage is occurring.

Risks that start in the input

Prompt injection ranks first. Defenses are layered and none is complete; the prompt injection page covers them. Hidden Context Exposure sits next to it. OWASP’s guidance is to assume hidden context is discoverable and keep credentials out of it, so a leaked system prompt costs you nothing secret.

Risks that come from what the model can do

OWASP’s excessive agency entry names three root causes: excessive functionality, excessive permissions and excessive autonomy. Its main controls:

• Offer only the tools needed and avoid open-ended ones such as shell execution.
• Give tools the minimum access, for example read-only database roles or read-only OAuth scopes.
• Run actions in the user’s context, not a broad service identity. See AI agent identity.
• Require human approval for high-impact or irreversible actions.
• Enforce authorization in code. OWASP: “Implement authorization in logic rather than relying on an LLM to decide if an action is allowed or not.”

It adds that monitoring, logging, rate limits and circuit breakers limit damage but do not prevent excessive agency. For the output side, Improper Output Handling can lead to XSS, CSRF, SSRF, privilege escalation or remote code execution when output reaches a downstream system unchecked. Treat model output as untrusted input to that system. Runtime checks of this kind are covered in AI guardrails.

Risks in the data

Sensitive information disclosure is wider than a chatty answer. OWASP lists tool-call arguments, reasoning traces, retrieved chunks, logs and telemetry, embeddings and measurable properties such as timing and token length as channels, across four phases: training, inference, pipeline and observation.

Two consequences follow. Your own telemetry is a disclosure surface, so OWASP’s mitigations include “restrict and scrub logs and traces before APM ingestion” and “Never log raw traces to unrestricted observability.” And retrieval systems need the same access control as the source documents, because vector and embedding weaknesses include cross-tenant leakage through shared similarity search. See RAG pipeline.

Risks in what you build and run

Supply chain and poisoning cannot be caught at request time. They concern the integrity of models, datasets, adapters and pipelines you pull in, including third-party models and LoRA adapters shared on platforms such as Hugging Face (OWASP LLM04). Vet and pin what you depend on, and revalidate when an artifact changes.

Unbounded consumption is a cost and availability risk. OWASP says “traditional request-rate limiting alone is no longer sufficient”. It calls for token-aware cost controls, hard spending caps that stop inference once a budget is exceeded (not only alerts) and agent-level circuit breakers such as step, recursion depth and time limits.

Where LLM security stops and agent security starts

OWASP’s preface draws the line at the model’s role. The LLM list covers the model as a component. When it acts with tools, memory and downstream consequences, the risk moves to the OWASP Agentic Top 10. Tool servers are a case: OWASP’s supply chain entry sends MCP server and tool registry risks to the agentic list. See AI agent security, MCP security and AI agent guardrails.

Testing that the controls work

Controls fail quietly, so test them. AI red teaming probes the system with adversarial inputs before attackers do, and red teaming vs pentesting explains how the two differ.

Watching for these risks in HoneyHive

Several of the ten leave traces you can measure. HoneyHive’s client-side metrics guide says guardrail-style checks are ideal to compute with enrich_span(metrics=...), so you can log a flag such as pii_detected or injection_flagged on the span where it happened. Online evaluations score production traces after ingestion, and alerts can fire on quality and cost metrics, which covers runaway consumption. Because traces hold full prompts and tool calls, apply the log-scrubbing advice above to them too. See LLM observability.

FAQ

What are the main security risks of LLMs?

The OWASP Top 10 for LLM Applications, 2026 edition (published August 4, 2026), ranks them: prompt injection, sensitive information disclosure, excessive agency, supply chain, data and model poisoning, unbounded consumption, misinformation, hidden context exposure, vector and embedding weaknesses, and improper output handling.

Which LLM security risk is the most serious?

OWASP keeps prompt injection first, but calls the rise of excessive agency to third place the most consequential move on the 2026 list. Prompt injection decides whether an attacker can steer the model. Excessive agency decides how much damage that steering can do.

Is LLM security different from agent security?

The boundary is the model's role. OWASP's preface says the LLM list covers the model as a component in your application. Once the model acts with tools, memory and downstream consequences, the risk moves to the OWASP Agentic Top 10.