AskDocs threat table: entry points and controls
A threat model fits in a table you can print. The controls named here are the topics 10.2 to 10.7.
A threat model lists what is worth protecting, who might attack it, and every place where text enters the system. For RAG the key line to draw is a trust boundary around everything that is retrieved: it is data to read, never orders to follow.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Add ("ticket attachment", "a customer", "untrusted") and a threat "a ticket attachment contains a customer's card number" with control "redact before indexing". Print the count of untrusted entry points.
Write risky(entry_points) that returns the names of entry points that are not trusted and not reviewed. Print the list for the table in this topic.
Explain it without notes
What is a threat model, and what four things should it list for a RAG system?
Which entry points does RAG add compared with a plain chat app?
Explain the trust boundary and the rule that follows from it.
Why should a wrong access label be modelled as a threat even if nobody is attacking?
Expected output
Where text enters:
system prompt written by the developers trusted may change the rules: yes
access labels written by the ingestion code trusted may change the rules: yes
handbook passage written by a reviewed editor reviewed may change the rules: no
uploaded file written by a customer untrusted may change the rules: no
crawled web page written by anyone online untrusted may change the rules: no
user question written by any signed-in user untrusted may change the rules: no
Untrusted entry points: 3 of 6
What to protect:
another team's documents: a user reads a chunk they should not see -> labels checked inside retrieve
the model's behaviour: a passage gives the model orders -> sources are data and output is checked
customers' personal data: an email address lands in an index or a log -> redact before indexing
the truth of the answers: a bad document is added on purpose -> provenance and trust levels
the right to be forgotten: a deleted document lives on in a cache -> delete everywhere, then audit