What is RAG?
Retrieval-Augmented Generation (RAG) is an application architecture in which the application looks up content relevant to a task and places selected parts of it into the model's context before the model answers. The model is not changed; its input is.
RAG is a pattern, not a model primitive and not a security boundary. Products differ widely in how they ingest, index, retrieve and assemble content. This article describes common architectural roles, not one universal implementation.
It builds on Trust Boundaries and Model Context and AI Agents and Tool Calling: model-visible content can influence the output, but trust, authority and security-relevant facts are established by application-side state and evidence.
Why applications use retrieval
Applications retrieve content to answer from current or organization-specific material, to cite where an answer came from, and to avoid putting whole corpora into every request. Retrieval improves relevance and traceability.
Retrieval means selecting content for a task. It does not authenticate that content, certify it as correct, or give it any authority over the application or the model.
The RAG pipeline
| Stage | What it does | Trust character |
|---|---|---|
| Source | Document, page, record or message that may later be retrieved | Variable content plus application-recorded source identity and provenance |
| Ingestion | A connector fetches and registers the source | Trusted processing component; does not certify content |
| Parse, normalize, chunk | Extracts text, splits it and attaches metadata | Transformation; lineage must stay attached |
| Embedding and index | Creates retrieval representations and stores them | Retrieval representation; not trust or permission |
| User query | User request is variable input; principal, tenant and task scope are application-owned metadata | Mixed: query text is variable input; scope metadata is application-owned |
| Query rewrite (optional) | Rephrases or expands the query | Variable or generated text under unchanged authorization scope |
| Candidate retrieval | Finds items similar or matching the query | Relevance selection |
| Security trimming | Removes items the current principal may not read | Deterministic eligibility under current principal, tenant and ACL |
| Ranking and reranking | Orders the remaining candidates | Orders already eligible candidates |
| Context assembly | Places selected content into model context | Variable selected content becomes model-visible; application-side provenance remains attached |
| Model answer or proposal | Text, citations or a proposed next step | Variable output |
| Application policy | Decides what may be returned, relied on, disclosed or acted upon | Application decision |
The order varies. Some systems filter by permission inside the index query, others trim after candidate retrieval. What matters is that eligibility is decided before content becomes model-visible.
What actually becomes model-visible
In common designs the model receives selected text, or another rendered or reconstructed representation, together with whatever metadata the application chooses to show. Everything placed there can influence the output, including sentences that look like instructions.
Application-owned facts such as the caller's identity, tenant, ACL decisions and version state should be held and enforced outside the model. Showing a label to the model can help it phrase answers; it does not make the label enforceable.
Relevance is not trust
A trusted retriever, connector, parser, vector database or index can faithfully carry untrusted or attacker-influenced content. Trusted infrastructure does not transfer trust to the content it transports, in the same way that a trusted browser can display an untrusted page.
Provenance and purpose-specific authority
| Question | Decided by |
|---|---|
| Source trust and provenance: where did this come from and was it changed? | Recorded source identity, version and lineage |
| Source authority: is this source designated for this purpose? | A source-of-truth rule or registry for the topic |
| User and tenant authorization: may this caller read it? | ACL or policy under the current principal |
| Instruction authority: may this content direct the application? | Application design; retrieved content normally has none |
| Answer and action authorization: may this be returned or acted upon? | Downstream application policy |
An authentic source can still be the wrong authority for the current question. A genuine team note is authentic but may not be the designated policy for a customer answer. Authority is often purpose-specific.
Keep authoritative metadata outside attacker-editable document text. A sentence saying "approved", "public", "current" or "belongs to tenant X" is content, not policy. See Data Provenance.
Retrieval authorization and security trimming
Security trimming means removing content the current principal may not read before it reaches model-visible context. Filtering only after generation is too late: the model has already seen the protected content and may have used it in wording, summaries or proposals.
Ranking should order only candidates that are eligible under current authorization. A high rank must never repair or override an authorization failure.
User, tenant and query scope
The initiating principal, tenant, session and task scope are application-owned state, established by authentication and session handling. Query text is variable input. Authorization is never inferred from what the query says or from model output.
A query that names another tenant, a restricted collection or a role does not change the caller's scope. The scope travels with the request as metadata the model cannot edit.
Query rewriting and follow-up retrieval
Many systems rewrite or expand queries, sometimes with a model, to improve recall. The rewritten query is variable or generated text. It may broaden wording, but it must not expand the caller's tenant, resource, collection, field or permission scope.
Follow-up retrieval proposed during a conversation or by an agent is also a proposal. Each retrieval runs under the same authorization envelope as the original request.
Embeddings, ranking and reranking
An embedding is a numeric representation used to compare meaning. In ordinary RAG designs embeddings and other vector representations are used for candidate selection and ranking; the model typically receives selected text or another rendered representation, not "the embedding itself". Implementations vary, especially in multimodal systems.
Reranking re-orders candidates with a further scoring step. Scores express estimated relevance to the query. They say nothing about whether the content is true, current, permitted or authoritative.
Chunking, parsing, summaries and derived artifacts
Parsing, OCR, chunking, summarization and query rewriting transform content. They can drop context, split a qualifier from the claim it limits, repeat text or create new derived artifacts. They do not sanitize instruction-like semantics.
Lineage worth preserving through transformations
- Source, document and version identifiers
- Contributor or owner
- Tenant and ACL or security label
- Chunk lineage back to the source span
- Transformation and index version where useful
These fields are architecture guidance, not a field list from a standard.
Citations and traceability
A citation links an answer to the retrieved item it relied on. That is valuable for review. It does not show that the item is correct, current or that the reader was permitted to see it; those are separate checks.
A grounded or cited answer remains model output and variable data. It is not application-authoritative because it points to a source.
Knowledge poisoning, RAG prompt injection and vector weaknesses
| Term | Core concern |
|---|---|
| Knowledge or corpus poisoning | Corrupted facts in the corpus harm knowledge integrity; no instruction-like content is needed |
| RAG prompt injection | Retrieved instruction-like content influences model behavior |
| Vector and embedding weaknesses | Broader failures in vector generation, storage, metadata, access or retrieval, including unauthorized access or retrieval manipulation |
One artifact can involve more than one, but they are not synonyms and need separate findings. OWASP lists prompt injection (LLM01:2026) and vector and embedding weaknesses (LLM09:2026) as separate risks. The attack mechanics are covered in RAG Prompt Injection.
Revocation, stale indexes, caches and derived state
Removing or correcting a source does not necessarily remove its derived chunks, older index generations, caches, summaries or memory entries. Content can stay retrievable after its source is gone.
Lineage-aware invalidation means using recorded lineage to find and revoke every artifact derived from a source or version, and to confirm that retrieval no longer returns it. This is architecture guidance.
Agentic RAG and downstream actions
In agentic RAG, retrieved content can influence later retrieval requests or tool proposals. Those remain proposals. Tool and action authorization stays independent and deterministic, as described in AI Agents and Tool Calling.
Output validation is a downstream shape and contract check. It is separate from source trust, retrieval authorization and sink-specific encoding, escaping or parameterization. See Output Validation.
Synthetic examples
Rank 1 matches the question about the fictional return window closely, but the application has no recorded source identity or approval for it.
The application does not present the item as official fact.
A team note ranks first; the registry marks policy-doc-A v4 (rank 3) as the current designated source for this topic, and the user may read it.
The answer relies on policy-doc-A v4 despite its lower similarity score.
The answer cites guide-B v2 exactly; the version registry marks v2 as superseded by v3.
The citation stays traceable, but the application does not present its content as current.
A restricted document in collection-R would answer the question perfectly; the current user has no read access.
Security trimming excludes it before context assembly; it never becomes model-visible.
A generated rewrite broadens the wording of the question; the request stays bound to tenant-1 and the collections the user may read.
Unauthorized collections remain ineligible regardless of the rewrite.
A corpus entry states a wrong fictional opening date. It contains no instruction-like text.
A knowledge-integrity problem, not prompt injection; provenance and source-of-truth rules address it.
Logging, telemetry and audit evidence
Useful evidence per request
- Principal, tenant and session scope used for retrieval
- Original and rewritten queries, kept distinct
- Candidate IDs with source, version and lineage
- Trimming decisions and the policy version applied
- Items placed into context, in order
- Citations returned and downstream decisions taken
Keep this evidence outside the model and protect it like the data it describes. This is architecture guidance.
Common misconceptions
Statements that do not hold
- "RAG makes answers trustworthy."
- "The top-ranked result is the authoritative one."
- "Our retriever is trusted, so retrieved content is trusted."
- "We can filter restricted content after the model answers."
- "A citation proves the answer is correct."
- "Deleting the source deletes everything derived from it."
- "Chunking or embedding removes instructions from text."
Sources and practice
How this article uses sources
- OWASP
- LLM01:2026 Prompt Injection, LLM09:2026 Vector and Embedding Weaknesses
- NIST
- AI 100-2e2025 and glossary - indirect prompt injection terminology
- Microsoft
- Input, Context, and Retrieval Hygiene, Defend against indirect prompt injection attacks
- Research
- PoisonedRAG - USENIX Security 2025, knowledge corruption research, Overcoming the Retrieval Barrier - USENIX Security 2026, corpus presence vs retrieval reachability vs influence
PoisonedRAG is cited as knowledge-corruption research, not automatically as prompt injection. Source-of-truth registries, lineage fields, invalidation and audit evidence are architecture guidance, not requirements quoted from a standard.
Practice the concepts in the Retrieval Relevance vs Trust, RAG Prompt Injection and Poisoned Knowledge Base labs.
Frequently asked questions
Is RAG a security control?
Does a high similarity score mean a source is reliable?
Where should permission checks happen?
Can query rewriting widen access?
Does the model see embeddings?
Is knowledge poisoning the same as RAG prompt injection?
What happens when a source is removed?
References
- LLM01:2026 Prompt InjectionOWASP GenAI Security Project · GuidanceReviewed 2026-09-26
- LLM09:2026 Vector and Embedding WeaknessesOWASP GenAI Security Project · GuidanceReviewed 2026-09-26
- Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2e2025NIST · Standard · 2025-03Reviewed 2026-09-26
- indirect prompt injectionNIST Glossary · Technical documentationReviewed 2026-09-26
- Input, Context, and Retrieval HygieneMicrosoft Learn · GuidanceReviewed 2026-09-26
- Defend against indirect prompt injection attacksMicrosoft Learn · GuidanceReviewed 2026-09-26
- PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language ModelsUSENIX Association · Research publication · USENIX Security 2025Reviewed 2026-09-26
- Overcoming the Retrieval Barrier: Indirect Prompt Injection in the Wild for LLM SystemsHongyan Chang et al. · Research publication · USENIX Security 2026Reviewed 2026-09-26