Vector database security
Vector database security covers the controls on the store that holds the embeddings a retrieval augmented application searches. It matters because that store is a copy of the source content in a different representation, and it is routinely built without the access control, classification and retention rules that governed the original.
The failure that appears most often is authorisation at retrieval. Documents from every department are indexed into one collection, the application searches it on behalf of whoever is asking, and the model is then trusted to be discreet about what came back. It is not a boundary. The fix is to filter by the requesting user’s entitlements at query time, using metadata carried from the source system, so that content the user cannot open is never retrieved in the first place.
Three more items belong on the checklist. Embeddings are derived data, not a one way hash, and research has shown that meaningful text can be recovered from them, so the store inherits the classification of its sources. Deletion has to propagate: removing a document from the source system and leaving its vectors in the index means the content is still answerable, which is a direct problem for a data subject erasure request. And the index is an injection surface, because a poisoned document placed where the crawler will find it becomes instructions the model reads.
What we check on an assessment is whether the store is reachable directly and without authentication, since these services are frequently deployed inside a trusted network with none, and whether access control survives the hop from the application to the index. Testing retrieval augmented generation end to end rather than only at the chat window is the point of the AI testing that follows retrieval all the way to the store.