What should you log and alert on for LLM08 vector weaknesses?

For OWASP LLM08, log every retrieval: who asked, which chunks came back, which source and access group each belongs to, and what ingestion added them. Alert when a result crosses an access boundary, when an unapproved source appears, or when retrieval volume departs from normal. OWASP asks for detailed, tamper-resistant retrieval logs.

What is LLM08?

LLM08:2025 covers vector and embedding weaknesses in systems that use retrieval augmented generation. Flaws in how embeddings are generated, stored or retrieved can be used, on purpose or by accident, to inject harmful content, manipulate output or expose sensitive information.

OWASP lists five common risks: unauthorized access and data leakage, cross-context leaks and knowledge conflicts in multi-tenant stores, embedding inversion, data poisoning, and behaviour alteration. Its mitigations include permission-aware vector stores, validated and authenticated data sources, classification of data, and monitoring and logging of retrieval activity.

What belongs in the retrieval log?

Treat a retrieval like a database query, because it is one. For each call record:

1. The caller, meaning the user or service identity and the tenant.
2. The query text or a hash of it, depending on your privacy rules.
3. The identifiers of returned chunks, with their source document and classification label.
4. The access group the caller held at that moment.
5. The model request that used the chunks, so you can connect a bad answer to its inputs.

Keep logs where the application cannot edit them. OWASP specifically asks for tamper-resistant logs.

What belongs in the ingestion log?

Poisoning happens at the front door. Record each document added: source, submitter, time, a content hash, and the result of any hidden-text or format checks. OWASP's example of a document with concealed instructions skewing a screening system is a reminder to check what the extraction step actually sees.

Which alerts are worth waking someone for?

Start with a short list tied to the risks.

• Boundary crossing. A returned chunk whose access group the caller does not hold. This should be zero, so any hit is an incident.
• Tenant mix. Results from more than one tenant in a single response in a multi-tenant store.
• New or unapproved source. A document ingested from outside the approved list.
• Retrieval spikes. One identity pulling far more chunks than its baseline, or a long run of near-duplicate queries, which can signal probing.
• Classification mismatch. A chunk labelled sensitive returned to a low-trust context.
• Knowledge conflict. Retrieved chunks that contradict each other or an authoritative source, flagged by an evaluation job.

What should you test beyond alerts?

Alerts catch what you thought of. Add tests that seed a canary document in one group and confirm another group never retrieves it. Rerun them after every change to indexing or permissions. OWASP also notes that retrieval can change the model's tone and behaviour, so keep a regular evaluation of answer quality, not only of leakage.

What to do

1. Write down your access groups and tag every chunk at ingestion.
2. Enforce permissions in the vector store query, not in the prompt.
3. Add the retrieval and ingestion log fields above, and send them to storage the app cannot modify.
4. Create the first three alerts (boundary crossing, tenant mix, unapproved source) and test them with a canary.
5. Review retrieval baselines monthly and tune spike thresholds.
6. Define who responds, and what happens to the affected index.

Quick check

Sources

• OWASP LLM08:2025 Vector and Embedding Weaknesses
• MITRE ATLAS

Last reviewed: 18 October 2026.