Skip to content
VecShield
← RAG Security Notes

Retrieval Security4 min read

Your vector store doesn't know who's asking

Your vector store doesn't know who's asking

Most companies that put a chatbot on top of internal documents did roughly the same thing. They took files from SharePoint, Confluence, Drive and the ticketing system, split them into chunks, embedded them, and loaded them into a vector database. The original documents had permissions on them. The chunks usually don't.

That's the problem in one sentence. In SharePoint, the HR folder was locked to five people. Once it's embedded, it sits in the same collection as the onboarding wiki. And the RAG app usually queries with a single service key that can read everything. Any user who asks a question close enough in meaning to a salary review can get that review back.

The security community has caught up with this. In the 2025 OWASP Top 10 for LLM applications, "Vector and Embedding Weaknesses" became its own entry (LLM08). It names weak access control and poor tenant isolation as core failure modes, and it maps them back to plain broken access control. IronCore Labs summed up the update simply: a vector store is a data store and needs the same authentication and authorization as any other database. A recent systematization paper on RAG privacy points out a less obvious gap. Most research effort goes into stopping PII from reaching end users, and very little goes into stopping confidential data from reaching the wrong internal users. That second case is exactly what RBAC is for.

The numbers on how often this goes wrong are early, but they aren't comforting. In April 2025 UpGuard scanned the internet for Chroma servers and found 1,170 exposed instances. Roughly a third of them (406) were returning actual data, including PII from customer support chat logs. Orca Security looked at exposed Weaviate, Milvus and Chroma instances and found credentials, medical records and biometric data. In one case the secrets they found in a vector store got them into customer accounts on a different platform. Defaults make this worse. Self-hosted Qdrant, Milvus and Chroma will all serve requests without a credential unless you configure one. CVEs have followed: a Milvus auth bypass via a single HTTP header (CVE-2025-64513), and this year a pre-auth RCE in Chroma's Python server.

All of that covers the no-auth-at-all case. The quieter problem is the store that does have auth but where every key is effectively admin. One shared key does reads, writes and deletes across every namespace, it was created two years ago, and nobody has rotated it.

Why regulators care

None of the frameworks mention vector databases. They don't have to, because the chunks contain the regulated data. HHS has said ePHI in AI training data and models is still protected, and the EDPB sets a high bar before it will call an AI artifact anonymous. So the access obligations you already have apply to the store as written:

  • HIPAA 164.308(a)(4) and 164.312(a): access limited to the minimum necessary, plus unique user identification. A shared "service" key works against both.
  • PCI DSS v4.0.1 Req. 7 and 8: least privilege, no shared or generic accounts, periodic access review, and credential rotation.
  • GDPR Art. 5(1)(f) and 32: confidentiality and appropriate technical measures.
  • SOC 2 CC6.1–CC6.3: logical access, provisioning and removal, and role-based access.
  • CCPA/CPRA: the new cybersecurity audit regulations require documented access controls over personal information.
  • EU AI Act Art. 15: robustness against manipulation. Keeping write access off the retrieval path is one of the cheapest anti-poisoning controls there is.

An auditor doesn't want to hear that you intend to do least privilege. They want a dated record of who could reach what, and what happened when that drifted.

Where VecShield fits

VecShield doesn't replace your vector database's permission model. It shows you what that model is actually doing.

It looks at your stores the way an attacker or an auditor would. Is the store open without a credential? Can one tenant's data leak into another tenant's results? Which keys are over-privileged, stale, or shared? And does any of that touch collections holding personal, health or payment data? The findings come with evidence and map to the frameworks above, so the security team and the compliance team are working from the same picture.

It runs in your environment, against your stores, with telemetry off by default. When a check can't be fully completed, the result says so instead of reporting a pass.

One caveat to state openly: detection is evidence, not a compliance certificate. What VecShield gives you is an accurate picture of your access controls to bring to the audit.

Sources