Retrieval-augmented generation is deceptively simple to prototype and deceptively hard to secure at enterprise scale. The pattern — retrieve relevant documents, hand them to a language model, return the synthesized answer — papers over a surprising amount of complexity that only becomes visible when the system is deployed against real corporate knowledge, real users, and real adversaries. After reviewing dozens of enterprise RAG rollouts in 2025, we can now catalog the antipatterns that keep showing up. This post describes them, with the hope that teams starting rollouts in 2026 will recognize the shape of their own plans and adjust.
Antipattern One: Permissions Collapse
The most common and most consequential antipattern is permission collapse. The RAG system is built on top of a corpus that was indexed without preserving the source-system permissions. The vector store contains embeddings of documents that, in their original systems, had fine-grained access controls. In the vector store, those controls are gone, and every user who can query the system can retrieve excerpts from every document that was indexed.
The symptoms of permission collapse include users discovering information in RAG responses that they would not have been able to find by direct search, chunks from high-sensitivity sources leaking into answers for general queries, and security reviews surfacing documents in the index that should never have been eligible for retrieval.
The remediation pattern is to treat the RAG pipeline as an access-controlled system from the ingestion stage forward. Permissions from source systems must be captured as metadata on chunks, and the retrieval step must filter based on the querying user's entitlements. This is more expensive than the permission-free pattern, but it is the only pattern that does not functionally exfiltrate the corporate knowledge base to every RAG user.
Antipattern Two: Embedding Everything
Teams commonly embed every document they can get their hands on, on the theory that more context is better. The result is an index full of outdated drafts, superseded policies, confidential material that was indexed by accident, personal notes that were never meant to be searchable, and duplicates of the same content in multiple versions.
The symptoms include RAG responses that cite superseded documents as if they were current, personal information appearing in general queries, and an index that grows faster than the organization's ability to reason about what is in it.
The remediation pattern is to curate the corpus deliberately. Each source system that feeds the index should have an explicit policy for what is eligible: document types, metadata requirements, freshness rules, exclusion patterns. The corpus should be reviewed periodically and pruned aggressively. A smaller, cleaner index produces better answers than a large, messy one, and it is easier to secure.
Antipattern Three: No Provenance in Responses
The RAG system returns an answer synthesized from retrieved chunks but does not surface which chunks were used, how they were weighted, or which portions of the answer came from which sources. Users have no way to verify claims. Reviewers have no way to audit. When the answer is wrong, there is no path to trace back to the source.
The symptoms include users citing RAG responses as if they were authoritative without being able to show where the information came from, stakeholders discovering that the system confidently asserts contradictory facts from different queries, and incident responses that cannot reconstruct why the system said what it said.
The remediation pattern is to treat citation as a first-class feature. Every factual claim in the response should be linked to the chunk that supported it. The UI should make citations visible and clickable. The logs should capture, for each response, the retrieved chunks, their relevance scores, and the prompt construction. Without this, the RAG system is not a knowledge tool. It is a confident guess machine.
Antipattern Four: No Handling of Conflicting Sources
Corporate knowledge bases are full of conflicts. The policy document says one thing, the wiki page says another, the old email thread says a third. The RAG system retrieves all three chunks and asks the model to synthesize an answer. The model produces one — often confidently — without surfacing that the sources disagreed.
The symptoms include users receiving different answers to the same question at different times as retrieval order varies, stakeholders discovering that the system is flattening real policy ambiguity into false certainty, and compliance issues when the system commits the organization to positions that were never actually the policy.
The remediation pattern is to detect conflicts at the retrieval stage and surface them in the response. When chunks contradict each other, the model should be instructed to identify the conflict rather than resolve it silently. The system should track which sources are authoritative for which domains, so that when the policy document and the wiki disagree, the policy wins. This requires more work than pretending conflicts do not exist, but the alternative is systematically eroding trust in the system's outputs.
Antipattern Five: Prompt Injection Via Retrieved Content
The RAG system pulls a chunk from a document that was written — accidentally or maliciously — to contain instructions. The model, helpfully, follows those instructions. The user receives an answer that reflects the injected content rather than the actual question. Or worse, the injected content causes the system to exfiltrate information through its answer.
The symptoms include unexplained deviations in agent behavior for certain queries, users reporting answers that seem to reflect content they did not ask about, and security reviews discovering documents in the corpus that contain language designed to manipulate language models.
The remediation pattern has several layers. Separate instructions from retrieved content in the prompt using clear delimiters. Instruct the model explicitly that retrieved content is data, not instructions. Scan ingested content for injection patterns, both at ingestion and at retrieval time. Monitor output for signs of instruction-following behavior that does not match the user query. None of these individually is sufficient. Together, they reduce the attack surface to something manageable.
Antipattern Six: No Query Logging, No Output Logging
The RAG system is deployed. It serves queries. Nobody is looking at what people are asking or what the system is answering. When a user reports that the system leaked something it should not have, there is no log to check.
The symptoms include inability to respond to incidents, inability to evaluate whether the system is improving over time, and inability to identify misuse patterns until they become publicly visible.
The remediation pattern is to log queries and responses from day one, with appropriate protections. Logs should include the query text, the retrieved chunks, the response, the user identity, and the timestamp. Logs should be retained according to policy, accessible for investigation, and protected against tampering. They should also be reviewed — automated analysis for anomalies, periodic human review for a sample. Logs that are written and never read are paperwork. Logs that are reviewed are the feedback loop by which the system improves and by which abuse is caught.
Antipattern Seven: Embedding Model Drift
The embedding model used to build the index was one version. The model used at query time is another version. The retrieval quality degrades in ways that are invisible until users notice that the system has gotten worse.
The remediation pattern is to treat the embedding model as part of the index's identity. When the model version changes, the index must be rebuilt. Teams should plan for this as a regular operational task, not as a surprise. They should also version their embeddings and track which version of the index any given deployment is using, so that when a regression is reported, the investigation can start with the right questions.
Closing the Gaps
The RAG pipeline is not a single system. It is a chain of systems, each of which has security implications. The antipatterns above do not require exotic controls to remediate. They require that the team treat each stage of the pipeline as something that needs design rather than something that will work out. The teams that approach RAG this way are shipping systems that serve users well. The teams that do not are spending 2026 explaining to auditors how their knowledge base became a liability.