Retrieval Security4 min read
Your vector store doesn't know who's asking
Document permissions often disappear when content enters a vector store. Why RAG access controls, tenant isolation and least privilege need evidence, not assumptions.
Read →Open-source security tooling for RAG and vector stores.
Inspect the data, access controls and retrieval behavior behind RAG applications.
VecShield helps identify:
Self-hosted · No telemetry · Safe mode by default
Content reaches the model through ingestion, storage and retrieval. Each step can introduce attacker-controlled text, leak data across tenants, or expose a collection. VecShield examines the vector store and the retrieval path.
Sources
Documents, tickets, wikis
Ingestion
Chunk · embed · write
Vector store
Chunks, metadata, embeddings
Retrieval
Similarity search, filters
LLM
Answer generation
$ git clone https://github.com/Vecshield/vecshield $ cd vecshield/demo $ docker compose up --build
The demo includes a synthetic estate and the full console at 127.0.0.1:8088. A generated admin password is printed on first boot.
VecShield runs alongside the vector infrastructure you already use. Scans and findings stay inside your environment.
Stored prompt-injection indicators, suspicious chunks, provenance gaps and anomalous embeddings.
Personal, health, payment and credential data stored in chunks and associated metadata.
Checks whether one tenant or namespace can retrieve data belonging to another.
Network exposure, TLS, encryption settings, known vulnerable dependencies and configuration issues.
API keys, excessive permissions, stale credentials and access-control mismatches.
Bulk reads, enumeration attempts and unusual collection-wide retrieval patterns.
Research, experiments and practical notes on securing retrieval-augmented systems.
View all research →Retrieval Security4 min read
Document permissions often disappear when content enters a vector store. Why RAG access controls, tenant isolation and least privilege need evidence, not assumptions.
Read →RAG Poisoning6 min read
Indirect prompt injection and RAG poisoning turn the knowledge base itself into an attack surface. Why provenance and retrieval-layer visibility are security controls.
Read →Data Privacy5 min read
Vector stores often hold original text, metadata and personal data. Why embeddings do not take a RAG system outside GDPR, CCPA and other data regulation.
Read →VecShield focuses on attacks and failures around the retrieval layer: poisoned knowledge, data leakage across tenants, and extraction of a whole collection through queries.
Attacker-controlled content
RAG ingestion
Poisoned knowledge base
Malicious / incorrect retrieval
LLM
Tenant A query
One tenant's request
Vector store
Shared collection
Tenant B chunk
Cross-tenant data exposure
Repeated semantic queries
Progressive recovery
Content collected across queries
Stored knowledge
Collection contents extracted
VecShield focuses on the retrieval and vector-store layer. It is not a generic LLM jailbreak detector.
Read the threat model →Connectors read from your vector stores. Optional monitoring records retrieval events. Detectors turn both into findings for data exposure, RAG integrity and access posture.
VecShield runs in your environment and does not require sending vector-store contents to a VecShield-hosted service. Scans run against the store on their own schedule, not between your application and its queries.
Read the architecture →Vector stores
Connectors
Read-only inspection
Retrieval events
Monitoring
Optional event capture
Detectors
Data exposure · RAG integrity · access posture
Findings & evidence
Coverage, masked previews and audit records
A result states what was scanned, what was sampled, what was skipped, what evidence supports a finding, what evidence argues against it, and what the detector cannot conclude. When a check samples a collection instead of reading all of it, the result is marked partial. There is no overall score.
Detection is not a legal determination. VecShield produces evidence; humans make the final decision.