A Series B startup we worked with in August 2025 stored 47 million embedded customer support tickets in a single Pinecone index with no namespace segregation. Their new RAG assistant for Tier-1 agents was retrieving embeddings from every customer's history, including enterprise tenants who had signed BAAs requiring data isolation. The breach was not a breach in the classical sense — no unauthorized network access, no stolen credentials. It was a design decision. The team had assumed the metadata filter on tenant_id was sufficient isolation, which it was functionally but not architecturally. Under audit, they couldn't demonstrate that a misconfigured filter couldn't leak cross-tenant data, because the shared index made the question unanswerable. This pattern repeats across vector databases. The primitives are young, the defaults are permissive, and the security model people assume is not the one the product ships.
Why do metadata filters not equal isolation?
Because a metadata filter is an application-layer check, not a storage-layer boundary. In Pinecone, Weaviate, Qdrant, and Milvus, vectors from different tenants in a shared index sit in the same ANN graph and are indistinguishable to the similarity search until metadata is applied. A filter bug, a missing predicate in one of 50 query call sites, or a developer using a raw SDK call instead of the sanctioned wrapper all leak data. Pinecone's namespaces, Weaviate's multi-tenancy (GA in v1.25, April 2024), and Qdrant's per-collection payload isolation are storage-layer boundaries; they do the right thing by refusing to return cross-tenant results regardless of application code. Use them. A 2025 incident at a legal-tech vendor started with a metadata filter that served empty string as "no filter," returning everyone's contracts to one customer's query.
What is embedding inversion and does it matter?
Embedding inversion is the class of attacks that reconstruct source text from dense vectors. Cornell's Vec2Text, published at ICLR 2024, recovered 92% of 32-token inputs from GTE-base embeddings. Follow-up work through 2025 has pushed that to longer contexts and more modern embedding models, including OpenAI's text-embedding-3-large. The implication: embeddings are not pseudonymized. If an attacker exfiltrates your vector store, they can reconstruct a significant portion of the source content without touching your raw data. Treating vectors as "just numbers" and applying weaker access controls than you would to the underlying documents is a common mistake. We audit for this by checking whether the vector store and the source store have the same row-level access controls, and they almost never do.
How should production deployments handle access control?
Identity-aware and least-privileged, same as any other datastore. Pinecone's API keys in 2024 were notoriously coarse; their role-based access model rolled out in early 2025 and per-namespace permissions became generally available mid-year. Weaviate has had RBAC since v1.29. Qdrant's JWT-based authentication with payload restrictions landed in v1.9. Use these. The pattern we recommend: one service identity per application, scoped to the namespaces or collections it owns, with read and write separated. Avoid long-lived API keys; most vector DBs now support OIDC or IAM-federated auth. Log every query with the identity, the filter, and the top-k metadata. These logs are invaluable when answering "who saw what" during an incident.
What about integrity and tampering?
Vector stores are mutable by design, and writes rarely carry an integrity trail. An attacker who gains write access can poison retrieval (see our companion piece on indirect prompt injection) by inserting crafted documents or by overwriting existing ones. Detection is hard because the similarity search is exactly the mechanism that hides semantic drift. We recommend three controls: immutable audit logs of every upsert with source hash, per-document signing where the document hash is stored in metadata and verified at retrieval time, and periodic re-embedding spot checks that detect when a document's embedding drifted from what its content would produce. The third is computationally cheap and catches the class of attack where an attacker replaces content but leaves the embedding intact.
Is pgvector safer than a dedicated vector DB?
It's not inherently safer, but it inherits Postgres's maturity. Row-level security policies in Postgres work over pgvector columns exactly as they do over text, which is a real advantage. The ANN index types (ivfflat, hnsw) recall-trade the same way as dedicated DBs, but you get mature backup, PITR, transactional writes, and decades of access-control tooling. The trade is performance at scale — billion-vector workloads still favor Pinecone or Qdrant. For enterprises under 100M vectors, pgvector with an existing Postgres security posture is often the lower-risk choice, especially when the data is already in Postgres. Supabase's ANN benchmarks in March 2025 showed pgvector HNSW within 15% of Qdrant on recall-matched workloads up to 50M vectors.
How does this fit into an AI-BOM?
Vector stores are first-class components of an AI-BOM. Each index or collection is an artifact with a schema, an embedding model, a source corpus, and a set of consuming applications. When the embedding model changes version (OpenAI deprecated text-embedding-ada-002 in early 2025; anyone who cached embeddings had to re-embed), the AI-BOM tells you which indexes and applications are affected. When a source is deleted for GDPR, the AI-BOM tells you which vectors need to be purged. Without this mapping, teams end up doing incident-response archaeology every time something changes upstream.
How Safeguard Helps
Safeguard's AI-BOM captures vector stores as artifacts with their embedding model, source corpus lineage, tenant isolation model, and consuming applications. Griffin AI runs reachability across namespaces, metadata filters, and application identities to surface configurations where isolation relies on query-side checks rather than storage-side boundaries. The eval harness probes for cross-tenant leakage and embedding-inversion exposure on a schedule, and policy gates block deployments that connect applications to vector namespaces outside their declared scope — so isolation is enforced before the first query runs.