Vector Database Security Guide: Access, tenancy and encryption controls for vector stores

Vector databases now hold the most sensitive text an organisation owns, chunked and embedded for retrieval, yet many are deployed with the security defaults of a developer prototype. Open source Qdrant accepts requests from anyone who can reach it until an API key is set, Milvus creates a root user with a published default password, and a pgvector table in a shared Postgres schema inherits whatever row level security (RLS) the team remembered to switch on. This guide covers how authentication, roles, tenancy, encryption, network exposure and logging work across Pinecone, Weaviate, Qdrant, Milvus and pgvector, and what a hardening baseline looks like. It is written for platform engineers, AppSec teams and security architects who own the retrieval layer behind RAG applications and AI agents. Retrieval pipeline design and prompt injection are covered in the RAG Security Guide; this page stays with the store itself.

Key takeaways

• Treat embeddings as the source data. OWASP LLM08:2025 lists embedding inversion as a real risk: an embedding of a contract or a patient note deserves the same classification as the document.
• Check the defaults before anything else. Self-hosted Qdrant ships with authentication off, Milvus ships with root:Milvus, and Weaviate permits anonymous access if it is enabled; change these on day one.
• Tenancy is an authorisation decision, not a query filter. Separate namespaces, tenants, collections or RLS policies enforced by the store beat a metadata filter that the application must never forget.
• The application's key is the crown jewel. Most vector stores are reached through one service credential with read and write rights to every collection; scope it, vault it and rotate it like any other privileged NHI.
• Audit logging is usually off or a paid tier. Qdrant's audit.enabled defaults to false and Pinecone audit logs need the Enterprise plan or HIPAA add-on, so plan detection before an incident, not after.

How identity and access work in vector databases

Vector stores grew out of search engines and research projects, so their access models differ widely. The table summarises the mechanisms each product documents. Versions matter: several features below arrived recently, so check the release you actually run.

Three design points follow from this. First, API keys in Weaviate and Qdrant are static shared secrets configured in environment variables or config files, so whoever can read the deployment manifest can read the key. Second, only some products bind access to an external identity provider: Weaviate supports OIDC directly, Pinecone supports SSO for console users, and pgvector inherits whatever Postgres authentication you configure. Third, the authorisation unit differs (namespace, tenant, collection, row), and your tenancy design must match the unit the store can enforce.

Tenancy and isolation options

Decision guidance: for customer-facing SaaS with contractual isolation duties, use a server-enforced boundary (namespace, tenant, collection or RLS) and treat metadata filtering as a relevance tool only. For an internal knowledge assistant where everyone may read the corpus, a shared collection is acceptable, but document-level permissions from the source system (SharePoint, Confluence, a ticketing system) still need to be carried into the index and enforced at query time. Small teams usually do best with a managed service and one namespace or collection per tenant; large organisations with many business units often run one store per data classification, so that a regulated corpus never shares a key with a general one. The Multi-Tenant SaaS Authorisation Guide covers tenant context propagation in the application tier.

pgvector specifics: enable RLS with ALTER TABLE ... ENABLE ROW LEVEL SECURITY, then add FORCE ROW LEVEL SECURITY so the table owner is also bound. PostgreSQL documents that superusers and roles with BYPASSRLS always bypass policies, so the application must not connect as either. Note a relevance side effect: pgvector applies WHERE conditions after the approximate index scan, so with HNSW and the default hnsw.ef_search of 40, a policy that matches a small share of rows can return very few results. Teams that "fix" this by disabling RLS have traded security for recall; use iterative index scans (hnsw.iterative_scan) or partitioning instead. See the PostgreSQL Security Guide.

Admin roles and privileged access

• Qdrant: the api_key grants full access and also signs every JWT. Anyone holding it can mint tokens with any claim. Keep it out of application pods where possible: give applications short-lived JWTs with an exp claim and per-collection access, and reserve the master key for an issuing service. Use alt_api_key (v1.17.0+) to rotate without downtime, remembering that the documentation warns that changing api_key invalidates all existing tokens.
• Milvus: change the root password with update_password() immediately after enabling authentication, create named administrator users, and keep common.security.superUsers empty unless you need a recovery path, because listed users can reset passwords without the old one.
• Weaviate: assign the root role only through AUTHORIZATION_RBAC_ROOT_USERS to named administrators, give analysts the viewer role, and build custom roles for applications that cover only the collections, tenants and data object actions they need. Backup permissions deserve separate attention: a backup role can copy the whole corpus.
• Pinecone: organisation owners can enable audit logs and manage SSO; project roles govern who can create indexes and keys. Require SSO for your domain, set a low default role for new teammates, and review organisation owner membership quarterly.
• pgvector: separate the schema owner (migrations), the application role (DML only, no BYPASSRLS) and the human DBA role. The Database Credential and Access Security Guide covers the Postgres side in depth.

Human administrator access to a vector store is privileged access to every document in it. Put it behind your PAM workflow with just-in-time elevation and session recording where the product supports it.

Integrations, API tokens and service accounts

A typical RAG deployment has at least three non-human identities touching the store: the ingestion pipeline that writes embeddings, the retrieval service or agent that queries, and a backup or replication job. Each needs a different scope.

• Vault the keys: inject vector store keys from a secrets manager at runtime instead of baking them into container images or .env files committed to Git. See the Secrets Management Guide and the API Key Management Guide.
• Do not let the agent hold the write key: an AI agent that can upsert into its own knowledge base can be steered by prompt injection into poisoning it (ATLAS AML.T0070 RAG Poisoning). Keep ingestion as a separate, reviewed pipeline.
• Watch for keys stored inside the corpus: ATLAS AML.T0082 RAG Credential Harvesting describes adversaries querying a RAG store for credentials that were ingested with source documents. Scan documents for secrets before embedding them.
• Enforce user context end to end: when the retrieval service queries on behalf of a user, pass the user or tenant identity and enforce it in the store (tenant filter in a JWT, RLS session variable, namespace selection) rather than trusting the model to ignore results. The AI Agent Authorisation Guide covers delegated access patterns.

Logging and detection

Retrieval logs are the only way to answer "which documents did the assistant see for this user?" after an incident. OWASP LLM08 recommends detailed immutable logs of retrieval activity. Support varies:

• Pinecone: audit logs record user and API actions, captured every 30 minutes as JSON; organisation owners enable them, and they require the Enterprise plan or HIPAA add-on.
• Weaviate: when RBAC is enabled, authorisation decisions are logged for audit.
• Qdrant: an audit log exists but audit.enabled defaults to false. Set audit.trust_forwarded_headers to true only behind a trusted proxy, or client IPs can be spoofed.
• Milvus and pgvector: rely on platform logging; for Postgres use log_connections, role-level statement logging or the pgAudit extension, and log at the application tier which document IDs were returned.

Detections worth building:

1. A read-only identity attempting writes or deletes (scope drift or a stolen key used for poisoning).
2. Queries from a retrieval key outside its normal source network or workload identity.
3. High-volume sequential scrolling or export of a collection, consistent with ATLAS AML.T0085.000 Data from AI Services: RAG Databases.
4. Ingestion of documents outside the approved pipeline, or sudden growth in a collection.
5. Collection, tenant or role changes outside a change window.
6. Requests carrying expired or unknown JWTs against Qdrant, which indicate key rotation gaps or forging attempts.

Metrics: percentage of vector stores with authentication enforced and anonymous access disabled; percentage of application identities that are least-privilege (read-only or collection-scoped); mean age of vector store API keys; percentage of collections with retrieval logging retained for at least your incident lookback period; number of tenants sharing a store without a server-enforced boundary (target zero for customer data).

Hardening baseline

1. Inventory first: find every vector store, including Chroma or Qdrant containers started by data scientists, pgvector extensions (CREATE EXTENSION vector is per database), and managed indexes. Record owner, data classification and network exposure.
2. Close exposure: bind self-hosted services to private interfaces (Qdrant service.host), never expose Qdrant's internal port 6335, keep 6333/6334 and Milvus 19530 behind a private network or gateway, and use Pinecone Private Endpoints (AWS PrivateLink or Azure Private Link) for production indexes.
3. Enable authentication and change defaults: set Qdrant api_key; set Milvus authorizationEnabled and rotate the root password; set Weaviate AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED=false and do not use AUTHENTICATION_OIDC_SKIP_CLIENT_ID_CHECK.
4. Encrypt in transit: Qdrant service.enable_tls with tls.cert and tls.key, plus cluster.p2p.enable_tls for peers. Qdrant's documentation states that sending an API key over an unencrypted channel is insecure. Pinecone uses TLS 1.2 for HTTPS and gRPC.
5. Encrypt at rest with keys you control where required: Pinecone encrypts with AES-256 and offers customer-managed keys through AWS KMS; for self-hosted stores, encrypt volumes and snapshot storage. See the Database and Storage Encryption Guide.
6. Introduce least privilege: enable Weaviate RBAC or Qdrant JWT RBAC or Milvus roles, issue separate identities for ingestion, retrieval and backup, and enforce tenancy server-side.
7. Turn on logging and ship it to the SIEM before go-live.
8. Test, then roll out: enable authentication in a staging cluster first, run the application's retrieval test suite, then roll to production with both old and new keys valid (Qdrant alt_api_key) so you can roll back by reverting configuration rather than reopening the store.

Common misconfigurations

• Development container promoted to production: a Qdrant or Weaviate instance started without a key, reachable on a cloud IP. Open AI data stores are a recurring breach pattern: the DeepSeek database exposure leaked chat logs and secrets from an unauthenticated ClickHouse database.
• RLS never enabled on a Postgres-backed store: in the Moltbook database exposure, a publishable Supabase key in client JavaScript gave full database access because row level security was off, exposing about 1.5 million agent API tokens. A pgvector table without RLS behind the same pattern exposes every embedding and source chunk.
• Tenant isolation by metadata filter only: a single code path that omits the tenant filter returns another customer's chunks.
• One admin key everywhere: ingestion, retrieval, notebooks and CI share the Qdrant master key, so any leak allows writes and token minting.
• Unreviewed backups: snapshots copied to object storage with broad read access, outside the store's RBAC entirely.
• Deletion that does not delete: a data subject or customer is offboarded in the source system but their chunks remain in the index because no deletion job maps source IDs to vector IDs.

Framework mapping

Practitioner checklist

• Inventory every vector store and pgvector database with owner, classification and exposure.
• Confirm authentication is enforced and anonymous access is off on every instance; rotate any default credential.
• Remove public exposure: private networking or private endpoints, no public internal cluster ports.
• Enforce tenancy in the store (namespace, tenant, collection or RLS with FORCE), not only in query filters.
• Issue separate least-privilege identities for ingestion, retrieval and backup; keep master keys out of applications.
• Store vector store keys in a secrets manager and rotate them on a schedule, using dual-key rotation where supported.
• Scan documents for secrets and sensitive data before embedding them.
• Enable audit or retrieval logging, forward it to the SIEM and alert on scope drift and bulk export.
• Build a deletion path from source document IDs to vector IDs and test it.

Standards and references

• OWASP: Top 10 for LLM Applications 2025 (LLM08 Vector and Embedding Weaknesses)
• MITRE ATLAS: Data from AI Services
• Qdrant: Security
• Weaviate: Role-based access control
• Milvus: Authenticate user access
• Pinecone: Security overview
• PostgreSQL: Row security policies
• pgvector: Open-source vector similarity search for Postgres

Related NHI Mgmt Group resources: RAG Security Guide · OWASP LLM Top 10 LLM08 Vector and Embedding Weaknesses Guide · AI Agent Memory Security Guide · Secrets Management Guide