Vector Database Security for LLM Applications

Vector databases power semantic retrieval in LLM applications — but security does not live inside the embedding index alone. Vector database security for LLM apps is primarily application-layer: tenant isolation, authorization filters, sensitive data handling, poisoned source detection, and access logging around every query and upsert.

Treating the vector store as a passive cache invites cross-tenant leakage, unauthorized retrieval, and persistent injection payloads that similarity search returns for benign queries.

What the vector DB actually stores

A typical RAG record:

Embeddings are not encryption. Anyone with database access can often reconstruct approximate content or join back to stored text. Protect the store like any datastore holding customer documents.

Hub context: RAG Security.

Threat model for vector stores in LLM apps

Tenant isolation patterns

Choose one primary strategy (can combine):

1. Separate collections per tenant

• Strongest isolation boundary
• Higher operational overhead at scale
• Natural fit for enterprise "dedicated index" tiers

2. Shared collection + mandatory metadata filter

{
  "filter": {
    "tenant_id": { "$eq": "tenant_abc" },
    "visibility": { "$in": ["public", "authenticated"] }
  }
}

• Every query must include tenant filter — enforce in code, test for bypass
• Single missing filter in one code path = critical vulnerability

3. Sensitivity-tiered indexes

• public_kb, internal_kb, restricted_kb per tenant
• Query router selects index based on user clearance

Multi-tenant SaaS: AI SaaS guardrails.

Authorization is not similarity

Vector search returns semantically similar chunks, not permitted chunks.

Required pattern:

1. Resolve user/tenant/session server-side
2. Build authorization filter from your identity system
3. Execute similarity search with filter
4. Optionally re-verify each doc_id against source-of-truth ACL service
5. Scan surviving chunks before LLM (prevent RAG injection)

Never accept tenant_id or user_id from client JSON without authentication.

Securing upsert and ingest paths

Attackers target write paths:

• Authenticate all ingest APIs
• Rate limit uploads per tenant
• Scan full document before embedding (POST /api/v1/security/prompt-injection, POST /api/v1/security/pii-secrets)
• Reject or quarantine unsafe findings
• Store provenance: uploader, content_hash, ingested_at
• Validate metadata schema — prevent privilege escalation via crafted tenant_id in metadata

Ingest compromise is data poisoning — see RAG Data Poisoning Explained.

Sensitive embeddings and text retention

Options to reduce exposure:

Run PII/secrets detection before persistence (PII leakage checklist).

Network and credential security

Infrastructure practices (cloud-specific details vary):

• Private networking between app and vector service
• IAM roles with least privilege — separate read vs write credentials
• No vector admin keys in application containers or LLM prompts
• Audit admin console access
• Backup encryption and restore testing

These do not replace application authorization but limit blast radius of infra compromise.

Poisoned and compromised sources

Defensive controls:

• Monitor new unsafe findings per source_uri
• Alert when one doc_id dominates retrieval for diverse queries
• Ability to delete embeddings by doc_id without full reindex downtime
• Version corpus snapshots for rollback

Do not rely on "our documents are internal" — document injection and supply-chain PDFs happen.

Query logging and privacy

Log:

• Query id, tenant, user (hashed if required), filter applied
• Retrieved doc_ids and scores
• Guardrail request_id if chunks scanned post-fetch

Avoid logging full query text in production if queries contain PII. Balance forensics with minimization (LLM data leakage).

Retention and deletion

When users delete documents or leave a tenant:

• Delete vectors by doc_id or tenant_id
• Delete object storage blobs
• Propagate deletion to backups per policy
• Document lag if async deletion

Stale vectors are both a privacy issue and an injection reservoir.

Security checks around retrieval

Vector DB security complements content scanning:

POST /api/v1/guard

{
  "text": "<concatenated retrieved chunks>",
  "checks": ["prompt_injection", "pii_secrets"]
}

Run after authorized fetch, before LLM. Unified Guard orchestrates multi-check paths; Prompt Injection Shield for injection-only.

Testing vector security

• Tenant A cannot retrieve Tenant B's planted chunk (automated test)
• Missing filter in test harness fails CI
• Revoked document not returned after deletion job
• Ingest with unsafe injection rejected
• Admin credentials not in repo or prompts (prevent API key leak)

Checklist summary

• Tenant isolation strategy documented and enforced in code
• Authorization filter on every query
• Ingest authentication and scanning
• Retrieve-time chunk screening
• Provenance and deletion workflows
• Poisoning monitoring
• Infrastructure least privilege
• Privacy-safe logging

Full RAG guardrails: LLM Guardrails Checklist. Vector-adjacent injection: Indirect Prompt Injection in RAG.

Summary

Vector database security for LLM applications means enforcing tenant and document ACLs on every query, securing ingest paths against poisoned content, minimizing sensitive text retention, and pairing storage controls with retrieve-time guardrails — not assuming embeddings are safe because they are numerical.

Lock down isolation and authorization first, then layer Unified Guard checks on chunks before they reach the model.