AI Security
Model Layer and Agent Layer
This page covers the model and application layer: what can be done to a model through its inputs, its training data, its weights and its outputs. The agent layer, where the system also takes autonomous action, has a threat surface these controls were never designed for. That shift is now visible in the ranking itself, with Excessive Agency the largest riser of the 2026 edition, and is covered separately in Agentic Zero Trust and Sandboxing and Isolation.
OWASP GenAI LLM Top 10 (2026)
Published 4 August 2026, replacing the 2025 edition. This is the first edition weighted by real incident data rather than practitioner voting alone, at roughly 75% community consensus to 25% incident analysis, and the ordering below the top two moved more than in any previous revision.
| Rank | Vulnerability | Description | Mitigation | vs 2025 | In Depth |
|---|---|---|---|---|---|
| LLM01 | Prompt Injection | Instructions reach the model through a channel intended to carry data, overriding or manipulating its behaviour | Provenance on all retrieved content, policy enforced outside the prompt, output filtering | Unchanged | Guardrails |
| LLM02 | Sensitive Information Disclosure | The model reveals training data, PII, or confidential information, affecting both model and application | Data filtering, PII detection, output monitoring, redaction | Unchanged | Privacy-Preserving ML |
| LLM03 | Excessive Agency | Systems granted autonomy or permissions beyond intended scope. The largest riser in the 2026 edition, reflecting agentic deployment reaching production | Least privilege, per-action gating, delegated identity, human in the loop | Up 3 | Agentic Zero Trust |
| LLM04 | Supply Chain | Vulnerabilities from compromised models, datasets, tools or dependencies anywhere in the chain | Model verification, dependency scanning, provenance tracking, version pinning | Down 1 | Rug-pull threats |
| LLM05 | Data and Model Poisoning | Manipulation of pre-training, fine-tuning or embedding data to introduce vulnerabilities, backdoors or bias. Now absorbs fine-tuning subversion | Data provenance, validation, anomaly detection, trigger-aware evaluation | Down 1 | ML Quality Assurance |
| LLM06 | Unbounded Consumption | Processes consume excessive resources, causing denial of service, cost overruns or degradation. Rose four places on practitioner concern | Rate limiting, input length limits, cost monitoring, hard loop budgets | Up 4 | Loop control |
| LLM07 | Misinformation | The model generates false, misleading or fabricated information. Ranked higher by incident data than by practitioner vote | Grounding, source citations, verification, human review | Up 2 | Hallucinations |
| LLM08 | Hidden Context Exposure | Renamed and broadened from System Prompt Leakage. Covers exposure of any context the user was not meant to see, including tool definitions, retrieved content and memory, not just the system prompt | Keep secrets out of context entirely, access controls, monitoring for extraction patterns | Renamed | Prompt Engineering |
| LLM09 | Vector and Embedding Weaknesses | Vulnerabilities in vector stores and embeddings, including cross-tenant retrieval and embedding inversion in RAG systems | Tenant-scoped retrieval, vector validation, access controls | Down 1 | RAG Architecture |
| LLM10 | Improper Output Handling | Insufficient validation of model output before downstream use. The largest faller, dropping five places from fifth | Sanitise before rendering, validate before execution, sandbox anything executable | Down 5 | Sandboxing |
Concentric Threat Flow
The ranked list says nothing about how the risks relate. Grouping them into entry vectors, the machinery that amplifies them, and the impacts an organisation actually suffers shows why controls at one radius cannot cover another. Four of the ten sit in more than one ring.
Dashed risks sit in more than one layer.
Attack Vectors
Defence: Adversarial training, input validation, robustness testing, and rate limits on the query patterns these attacks require.
Defence: Treat retrieved content as data for its whole lifetime, enforce policy outside the prompt, and never let output act without independent authorisation.
Defence: Data provenance and signing, anomaly detection over training sets, and evaluation suites designed to catch trigger behaviour rather than average accuracy.
Defence: Query monitoring and rate limiting, watermarking, plus signing, encryption and access control on the weights themselves.
What Agents Change
Every control above assumes a request and a response, with a human deciding what happens next. An agent removes that boundary, and each assumption fails in a specific way.
| Assumption at the Model Layer | How Agents Break It | Handled In |
|---|---|---|
| Output is read, not executed | Agent output becomes tool calls, shell commands and code that run without a human reading them first | Sandboxing |
| Input comes from the user | Most input arrives from tools, documents and other agents, so input filtering never sees the payload | Threat routes |
| A session is one exchange | Actions accumulate over long horizons, and a benign sequence can end somewhere no single step would be blocked | Agentic Errors |
| The model has no identity | The agent authenticates, holds credentials and acts, so authorisation and attribution both become live problems | Identity and delegation |
| State resets each turn | Memory persists, so an injected instruction can survive the session and fire against unrelated later work | Agent Memory |
Defence in Depth
No single layer is sufficient, and each one has a class of attack it structurally cannot see. Knowing what a layer misses matters more than knowing what it catches.
| Layer | Stops | Cannot Stop | Cost of Omitting |
|---|---|---|---|
| Input filtering | Known jailbreak phrasing and obvious injection attempts in user messages | Anything arriving through retrieval or tool results, which is where most injection now lives | Low |
| Instruction hierarchy | Casual attempts to override the system prompt | Determined attacks, because it depends on the model behaviour under attack | Medium |
| Output filtering | PII, secrets and disallowed content leaving in the response | Harmful actions already taken before anything was rendered | High |
| Action authorisation | Unauthorised tool calls regardless of how the model was persuaded | Permitted actions used for an unintended purpose | Severe |
| Execution isolation | A permitted action reaching beyond its blast radius | Damage entirely within the granted scope | Severe |
| Monitoring and audit | Nothing in the moment; it is how you find out and reconstruct | Everything, until someone looks | High |
Tooling
Probing a deployed model or application for exploitable behaviour before someone else does.
Models that sit around the primary model to classify input and output. Compared in depth on the Guardrails page.
Establishing that the weights you load are the weights you expected.
Limiting what the model can memorise and what the application can emit.
Platform guardrail products are compared in more detail on AI Guardrails. For certification evidence, see AIUC-1, and for governance frameworks see AI Governance and Compliance.