Vector Database
A vector database is a data store built to index and search high-dimensional vectors, the numeric embeddings that represent the meaning of text, images, or other content. Rather than matching exact keywords, it finds items whose vectors are nearest to a query vector, which makes it the retrieval engine behind most RAG systems. Pinecone, Weaviate, Milvus, and pgvector are common examples. In an AI application, the vector database holds the embedded knowledge base the model draws on, so its access controls determine which stored content can surface into a given user's prompt.
How a vector database supports AI applications
Documents are split into chunks, each chunk is converted into an embedding by a model, and the embeddings are stored in the vector database with references back to the source content. At query time, the user's question is embedded and the database returns the nearest chunks by similarity. Those chunks become the retrieved context in a RAG prompt. The database is ordinary infrastructure in the sense that it has its own authentication, authorization, and network exposure to secure.
Where the vector database sits relative to the AI boundary
Securing the vector database itself, who can read which namespaces, how tenants stay isolated, and what protects the embeddings at rest, is a data-infrastructure task that sits outside the AI request path. DeepInspect does not front the database. It governs the next step: the request that carries retrieved chunks into the model prompt. On that HTTP path it classifies the prompt content, enforces per-identity policy, and records the decision, so content that surfaced from the vector store is still subject to policy before it reaches the model. The two controls are complementary, database access control plus request-path enforcement.
Related reading
- LLM Vector Store Access Control: The Filters That Have to Run on Every RAG Query
The vector store holds embeddings the enterprise's users, tenants, and documents contributed. Every retrieval-augmented generation query has to run access-control filters against the store before the retrieval reaches the LLM context. This piece walks through the filter design that survives multi-tenant SaaS, cross-department access, and time-bounded document lifecycle: per-vector metadata, query-time filter injection, retrieval-response inspection, and the audit records that prove the filter held on every query.
- RAG Security Architecture: The Four Trust Boundaries in a Retrieval Pipeline
A RAG request crosses four trust boundaries before the answer comes back: what gets indexed, who can retrieve which chunks, what the assembled prompt carries into the model, and what the response returns. This article lays out the reference architecture for each boundary, marks which two are data-plane controls and which two sit on the HTTP path to the model, and shows where identity-bound policy and a per-decision audit record belong.