Safeguard
AI Security•

RAG security: poisoned documents and who can retrieve what

RAG apps fail in two ways: bad documents get in, and the wrong people get good ones out. Learn the OWASP controls for ingestion, permissions and logging.

Safeguard Security Team
4 min read

A retrieval augmented generation (RAG) system answers from your documents, so two things decide its security: what is allowed into the knowledge base, and who is allowed to retrieve it. OWASP's LLM08:2025 treats both as core weaknesses. Control the ingestion pipeline, enforce permissions at retrieval time, and keep logs of every retrieval.

What is the risk, in plain terms?

OWASP describes weaknesses in how vectors and embeddings are generated, stored or retrieved that can be exploited, on purpose or by accident, to inject harmful content, manipulate outputs or expose sensitive information. Its listed risks are unauthorised access and data leakage, cross-context leaks in multi-tenant stores, embedding inversion, data poisoning and behaviour alteration.

The page's own scenarios show how ordinary this is.

  • Poisoned document. A résumé contains hidden white-on-white text instructing a screening system to recommend the candidate, and the model follows it.
  • Cross-group leakage. In a shared vector database, one group's content is returned for another group's queries.
  • Behaviour change. After retrieval, an empathetic answer becomes purely factual.

No exotic attack is needed in the first two. A normal upload and a normal search do it.

How do poisoned documents get in?

OWASP names insiders, prompts, seeded data and unverified providers as sources. In practice, any pipeline that ingests files from email, shared drives, tickets, web pages or customer uploads inherits whatever those sources contain. Hidden text, odd encodings and instructions written for a model rather than a human are common in poisoned content.

The related OWASP page on data and model poisoning adds that poisoning is an integrity attack, and that risk is highest with unverified external data. It suggests tracking data origins, vetting vendors, sandboxing exposure to unverified data and using anomaly detection.

How do permissions go wrong?

Most RAG systems embed everything into one index, then filter later, or not at all. If the filter lives only in the prompt, such as a line telling the model not to reveal certain files, OWASP's page on sensitive information disclosure notes that system prompt restrictions may not be honoured and can be bypassed. The check has to happen in the retrieval layer, before text reaches the model.

What does OWASP recommend?

  • Access control. Use fine-grained, permission-aware vector stores and partition data logically by access level.
  • Data validation. Validate sources, audit the knowledge base for hidden content and poisoning, and accept data only from trusted, verified sources.
  • Review of combined data. Tag and classify data so access can be controlled when sources merge.
  • Monitoring and logging. Keep detailed, immutable logs of retrieval activity.

What to do

  1. Inventory your sources and rank them by how much you trust their authors.
  2. Normalise and scan on ingestion. Extract text in a way that surfaces hidden content, reject files that fail, and keep the original alongside.
  3. Carry the source permissions into the index. Each chunk keeps the access list of its document.
  4. Filter at query time by the asking user's identity, and test it with two accounts that must not see each other's data.
  5. Separate tenants and sensitivity levels into partitions or separate indexes.
  6. Log each retrieval: user, query, chunk IDs returned, source documents, and time. Store logs where the application cannot edit them.
  7. Show sources to users so a strange answer can be traced to a document.
  8. Review the index on a schedule and remove stale or unowned content.
  9. Treat retrieved text as untrusted when it is handed to tools or agents, and cap what the model can do with it.

How does this connect to supply chain work?

The documents and embedding models in a RAG system are supply chain components. Track them the way you track dependencies, with an inventory and a record of changes. Safeguard's MCP guardrail and SCA dependency inventory are aimed at the agent tool and package side of that, while the document pipeline above is a control you build in your own application.

Quick check

Can I rely on a system prompt to stop the model revealing restricted documents?

No. OWASP notes that prompt level restrictions may not be honoured and can be bypassed. Enforce permissions in the retrieval layer.

What is the simplest test for cross-user leakage?

Create two users with different document rights, ask each one questions that target the other's documents, and confirm nothing from the other set is retrieved.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.