A vector store is usually secured like a database and used like a recollection. Why permissions applied at the document store do not travel into the index, why the embedding often outlives the file it came from, and what signing and re-embedding actually fix.
Filed wrong
A vector index appears on the architecture diagram as a datastore, next to the caches and the queues.
It is procured that way, secured that way, and backed up that way. But it is not used that way. It is used as the thing the system reaches into when it needs to recall something, and whatever comes back is treated as what is known.
That gap between how it is classified and how it functions is where the problems live. Write access to a cache degrades performance. Write access to memory changes conclusions.
Permissions do not travel
The most common defect, and the least exotic.
Access control is applied where the documents live — the drive, the wiki, the ticket system. Each of those has a permission model somebody thought about.
Then a pipeline reads everything it can see, chunks it, embeds it, and writes it to an index that has one permission model: whoever can query it gets what matches.
The permissions were not removed. They were simply never carried across. Retrieval does not bypass access control through any flaw; it operates in a place where access control was never expressed.
A user who cannot open a document can frequently be told what it says.
The embedding outlives the document
Deletion is applied to files, and an index is not a file.
Remove the source document and the vector generally remains, because the delete path was built for the document store and the index is downstream of it. The text of the chunk is often stored alongside the vector, for citation, so the content is still there in a readable form.
The organisation believes the document is gone. Retrieval disagrees, quietly, for as long as nobody reconciles the two.
This is worth checking rather than assuming, and it takes one query.
Crafted for retrieval
Chunks can be written to be found.
Retrieval is a similarity comparison, and text can be composed to sit close to a broad range of queries — padded with the vocabulary of whatever subject it wants to be consulted about. The result is a passage that surfaces for questions it has no business answering.
It does not need to be the best match. It only needs to be in the handful that get passed forward.
Combined with the previous two sections, this is the shape of the thing: a passage somebody else wrote, retrieved for a question they did not ask, carrying permissions that were never checked, sourced from a document that may no longer exist.
What helps
Mirror the source access controls into the index. The unambiguous one. If the document store says no, retrieval says no. It closes the bypass entirely and it is mostly plumbing.
Sign chunks against their source. A chunk should be verifiable as having come from a specific document at a specific revision. Then an entry written directly into the index, rather than through ingestion, is detectable.
Re-embed on a schedule rather than trusting the stored vector. Reconciling the index against the corpus catches both the deleted document still answering questions and the edited one still answering as its old self.
Treat a hit as a claim, not as a fact. A retrieved passage should arrive with its source attached and be presented to the reader that way. It is the difference between the system saying something and the system reporting that a document says something.
Close
Secure the index like a database and you protect its availability.
The thing worth protecting is what it will say when asked — and nothing about a backup schedule addresses that.