Threat modeling a RAG system works better with a structure specific to how retrieval pipelines actually fail, since a generic AI threat model applied without adapting it tends to treat retrieval as one single black box rather than examining the several distinct components, ingestion, indexing, retrieval, ranking, that each carry their own particular risk.
Start by mapping every source that feeds the pipeline
List every content source feeding the RAG pipeline: document repositories, wikis, databases, scraped web content, user uploads, support ticket systems, anything that ends up indexed for retrieval. For each source, note who can write to it, what access control the source itself already enforces, and whether that access control actually carries forward into the retrieval system's own filtering. This map is the foundation the rest of the threat model builds on, since most RAG-specific risks trace back to a gap between what a source's access control assumes and what the retrieval pipeline actually enforces.
Trace access control through every stage, not just at the entry point
For each source, trace what happens to its access metadata through ingestion, indexing, and retrieval. Confirm the metadata gets captured accurately at ingestion, survives correctly through any chunking or reprocessing step, and actually gets enforced as a filter at retrieval time, before ranking by relevance. A threat model that only checks whether access control exists at the source, without tracing whether it survives the full pipeline intact, misses exactly the point where the boundary actually breaks down.
Assume every source can be poisoned unless proven otherwise
For each writable content source, assume an attacker with plausible access to it, an employee with edit permissions, an external party able to submit content to a public-facing channel, could plant manipulative content there, and ask what the worst outcome would look like if they did. This framing surfaces both the sources needing stronger write-access restriction and the sources where downstream controls, tool scope, independent authorization, need to be strong enough to contain a poisoning attempt that ingestion-time review might have missed.
Map what a compromised or fully manipulated retrieval result could cause
Instead of only asking whether a specific retrieval scenario is likely, ask what happens if retrieval returns fully attacker-controlled content for a given query, the same "assume compromise" exercise used in broader AI threat modeling, applied specifically to the retrieval step. If the model's response only ever gets read by a human, the worst case is bounded. If the model can act on retrieved content through a tool, the worst case scales with whatever that tool allows, which is exactly where the RAG threat model connects directly to the broader tool authorization and action-risk analysis.
Consider the vector database as its own asset with its own boundary
Include the vector database itself as a distinct component in the threat model, with its own questions: what authentication protects it, what network exposure does it have, does it correctly enforce tenant or user isolation if it serves multiple audiences, and what could get inferred or reconstructed from its stored embeddings if it were compromised directly, independent of the application layer that normally mediates access to it.
Model the multi-document combination risk explicitly
Include a specific threat scenario for cross-document combination: document A and document B are each individually fine to access, but could a query retrieving both together produce a response revealing something more sensitive than either document alone would justify? This risk never shows up in a per-document access control review, since each document passes that review on its own, and it needs its own explicit slot in the threat model.
Prioritize findings by reachability and consequence
Once the threat model surfaces a list of scenarios, prioritize with the same logic used elsewhere in AI threat modeling: how easily can an attacker reach this scenario, and how bad is the worst outcome. A publicly writable content source feeding a customer-facing assistant with tool access deserves far more urgent attention than an internal, narrowly writable source feeding a read-only internal tool, even though both technically show up on the same threat model.
Revisit the model as sources and capabilities change
A RAG threat model reflects the pipeline as it existed the day the model got built. Adding a new content source, expanding retrieval to a new document type, or giving the agent consuming retrieved content new tool capabilities should each trigger a revisit of the relevant parts of the threat model, rather than treating the original assessment as permanently valid no matter how the system evolves underneath it.
Where TELEON fits
Where a RAG threat model identifies a tool call as a high-impact step following retrieval, TELEON's policy enforcement, applied through the gateway or supported middleware, gives teams a place to enforce the limits that scenario calls for, and its audit trail supports investigating whether a predicted scenario has actually occurred in production.
Mapping sources, tracing access control through the pipeline, and modeling poisoning and combination risk are analysis work that has to be done directly against the specific RAG architecture and its content sources.
A short RAG threat modeling checklist
- Map every content source feeding the pipeline and its write access.
- Trace access control metadata through ingestion, indexing, and
retrieval.
- Assume each writable source can be poisoned and model the worst
outcome.
- Assess consequence assuming fully compromised retrieval results,
especially where tool access follows.
- Treat the vector database as its own asset with its own threat
scenarios.
- Model cross-document combination risk explicitly.
- Prioritize findings by reachability and consequence.
- Revisit the model whenever sources or capabilities change.
A RAG-specific threat model catches risks that a generic AI threat model tends to gloss over, because it forces explicit attention on the pipeline stages, ingestion, indexing, retrieval, ranking, where access control most often breaks down silently.