OWASP LLM Top 10 (2026): what LLM02 and LLM09 ask of your AI retrieval

The short answer. If your AI pilot is waiting for security sign-off, two entries in the 2026 OWASP Top 10 for LLM Applications cover what the reviewer will ask about retrieval: LLM09:2026, Vector and Embedding Weaknesses, and the retrieval side of LLM02:2026, Sensitive Information Disclosure. Both make the same point about access. Similarity search finds what is relevant; it doesn't know who is allowed to see it. OWASP says it in one line: "Cosine similarity does not respect ACLs. Authorize before retrieval, because post-generation filtering cannot undo a chunk already supplied to the model."

First, check which edition your reviewer is using

OWASP published the 2026 edition on 4 August 2026, and the numbers moved. Vector and embedding weaknesses, LLM08 in the 2025 list, is now LLM09:2026. LLM08:2026 is Hidden Context Exposure, a different risk that this post doesn't cover. LLM02:2026, Sensitive Information Disclosure, kept its number. If a questionnaire or a vendor deck says "LLM08" about embeddings, it is using 2025 numbering, so read it as LLM08:2025.

What LLM09:2026 covers

LLM09:2026 is about the layer that turns your documents into vectors and uses similarity search to decide what the model sees. OWASP's own summary is a good one to keep in your head during a review: "poisoning makes the system wrong, inversion makes it leak, jamming makes it silent, and access-control failure makes it indiscriminate."

The entry lists seven risks:

1. Cross-tenant leakage through a shared index. If the search runs across everything before access control is applied, result counts, scores and timing can reveal that other people's documents exist, even when nobody sees them.
2. Embedding inversion. Stored vectors can be turned back into much of the source text, so a leaked vector backup should be treated like a leak of the documents.
3. Retrieval-time poisoning. Someone who can write to the corpus can plant content that lands next to a target question.
4. Retrieval jamming. One planted "blocker" document can make the system refuse to answer a specific question.
5. Membership inference. An attacker learns whether a document exists in the index, which can be sensitive on its own.
6. Semantic cache and deduplication poisoning. Similarity thresholds can be gamed to serve attacker text or silently drop real content.
7. Multimodal poisoning. An image can be crafted to sit next to a sensitive text query.

Only some of these are about who can see what. That's the part this post is about.

What LLM09:2026 asks for on access

OWASP's first mitigation is about permissions, and it is specific: "Enforce tenant scoping inside the index query, not as a post-retrieval filter, and validate it server-side." The same paragraph adds the line most enterprise pilots trip over: "Apply access control at the chunk level: a mostly-public document can contain a confidential paragraph."

In a review, that turns into a short list of questions:

1. Where does the scope come from? If the application passes in the user or tenant it likes, the check is only as strong as the application. OWASP's point is that the scope is validated server-side.
2. Is access checked per chunk, not only per document? A document that is mostly public can still carry one paragraph that isn't.
3. Can the response reveal what the user can't see? OWASP treats raw similarity scores returned to the client as a membership oracle, and lists result counts and timing as the same kind of channel.
4. Which data is sensitive enough for its own index? For high-sensitivity workloads OWASP recommends physically separate indexes per tenant or trust zone, and keeping mixed-trust content out of a shared index.
5. Is retrieval logged? OWASP asks for immutable logs of retrieval activity, including the scope, the query and the returned IDs.
6. When a source document is deleted, when do its embeddings go? OWASP asks for deletion within a bounded time, checked by reconciliation.

What LLM02:2026 adds about retrieval

LLM02:2026 is the broader disclosure entry, and most of it is about training data, side channels and logs. Three parts matter for retrieval:

• Retrieved chunks are a disclosure channel, alongside the final answer, tool arguments, traces and logs.
• Oversharing upstream is one of the two structural failures OWASP names: unscoped drives, legacy permissions and knowledge bases feeding RAG with data the model then retrieves exactly as designed.
• Its third mitigation is: "Authorize before retrieval: enforce document- and chunk-level authorization inside the index query, not at the application layer after retrieval."

LLM02:2026 also names a problem that per-document authorization doesn't solve: individually permitted sources combining into a conclusion the policy prohibits (OWASP asks for an enforced join policy across sources). If your reviewer raises it, that is a data-governance question as much as a retrieval one.

The evidence that closes these items

Where Gateco fits

OWASP's mitigations (LLM09:2026 mitigation 1 and LLM02:2026 mitigation 3) ask for authorization inside the index query.

Gateco takes a different route to the same goal: it checks every candidate the index returns against the requesting user's permissions, withholds what is denied and, when denials leave the result set short, re-runs the search deeper to refill it, all before anything reaches the application or the model. So no unauthorized chunk becomes model context, and nothing relies on post-generation filtering. The permission check is one code path shared by all twelve vector and search backends Gateco supports, and it is deny-by-default. The permissions are the ones your organization already defines: groups and attributes from your identity provider, policies you write against them, and access lists imported from Google Drive, SharePoint, Confluence and Notion (Notion at workspace level). Every decision is recorded: what was allowed, what was denied, and the chunks each decision covered.

What Gateco does not cover. An authorization layer doesn't stop corpus poisoning, retrieval jamming or inversion of a leaked vector backup; those need the ingest, provenance and storage controls in LLM09:2026's other mitigations. And where your threat model includes inference from a shared index, OWASP's advice to use separate indexes per tenant or trust zone still applies.

Common questions

What is LLM09:2026 in the OWASP Top 10 for LLM Applications?

Vector and Embedding Weaknesses: risks that come from turning content into vectors and using similarity search to decide what the model sees, including access-control failures, embedding inversion, poisoning, jamming and membership inference.

Is OWASP LLM08 still vector and embedding weaknesses?

Only in the 2025 list. In the 2026 edition, published 4 August 2026, vector and embedding weaknesses is LLM09:2026, and LLM08:2026 is Hidden Context Exposure.

Does a metadata filter in the vector database meet LLM09:2026 mitigation 1?

It can, if the filter value is set server-side from the verified user, matches the source permissions after people change roles, and works at chunk level. Expect the reviewer to ask about all three, and about what happens when the filter errors.

Is filtering the model's answer enough for LLM02:2026?

No. OWASP says post-generation filtering cannot undo a chunk already supplied to the model, so the check has to happen before retrieved content becomes context.

If your pilot is heading into a security review, the twelve questions we'd want answered first go further on retrieval.

Sources

• OWASP Top 10 for LLM Applications 2026: LLM09:2026 Vector and Embedding Weaknesses, GenAI-Security-Project/GenAI-LLM-Top10 on GitHub.
• OWASP Top 10 for LLM Applications 2026: LLM02:2026 Sensitive Information Disclosure, same repository.