Why does restricting who can write to a RAG index not stop an attacker adding a poisoned document?

## The confusion this question corrects The instinct, when someone says a RAG corpus was poisoned, is to ask who has write access to the index and lock that set down. That instinct is aimed at the wrong object. An attacker adding a poisoned document is almost never writing to the index at all. ## What a retrieval corpus actually is A retrieval-augmented system answers by first fetching passages (chunks) from a store and placing them in the model's context. That store - the index - is not authored directly by end users. It is **built** from one or more upstream sources: a public standards page, a vendor-maintained FAQ, an intake or filing queue, a document repository, a feed. A build job reads each source, splits its content into chunks, embeds them, and writes them into the index. The index is downstream; the sources are where content originates. So there are two very different writer populations: - **Index writers**: the small, usually privileged set that can operate the index directly. - **Corpus writers**: everyone who can put text into any source the build ingests - the *union* of every source's writer population. The second set is the one that matters for poisoning, and it is typically far larger and far less controlled than the first. A source might accept public submissions, or be a wiki-style page, or be a queue that anyone can file into for review. ## Why the index lockdown misses Locking the index ACL controls the first set and does nothing to the second. The attacker's write lands at a source; the build - running with its own trusted credentials - copies it into the index. From the index's point of view nothing unusual happened: an authorised build wrote an ordinary chunk. The attacker never touched the index, never needed a credential to it, and often does not even know how many sources feed it or which one their write ended up in. This is why the *right* description of the exposure is: the write happened at whichever ingested source has the weakest pre-publication review. The choice was made at the source, not at the index. ## Naming the control that was bypassed An interview answer here is stronger when it names, precisely, what the attacker got past - because that is a per-source thing: - an errata page's editor, - a vendor doc owner's sign-off, - a submission queue's moderator. Each source has its own review, of its own strictness, and the attacker's job is to find the loosest one. What they did *not* get past is the index's permission list, because they never went near it. ## What this is not This is the difference between two doors, not a claim about how the write is disguised, how large it should be, or when it lands - those are separate concerns. It is also not the transitive point that write access to a corpus equals influence over the model's behaviour; here we are strictly on where the write physically enters. The single load-bearing fact is: the corpus's real writer population is the union of its sources' writers, and the index ACL is not that set. ## Why interviewers ask it Teams reliably guard the index and the retrieval prompt, and reliably under-inventory the sources feeding the index. A candidate who reaches immediately for the index ACL has revealed the exact blind spot the attack exploits. The correct move is to look upstream at every source and ask which one's review is weakest.