About six months ago, questions began surfacing in our Slack channels as teams started deploying RAG pipelines to production. A security engineer discovered that their vector database contained customer support tickets with PII, API keys, and internal system details. Although their data loss prevention tools had scanned the original documents, once those documents were converted to embeddings, they became invisible to these tools.
Jascha Wanger at ThirdKey highlighted this issue with VectorSmuggle, a research framework showing how sensitive data remains in vector format without triggering traditional security controls. Here's what you need to know.
What Are Vector Embeddings?
Vector embeddings are numerical representations of text, images, or other data that machine learning models can process. When you input a document into an embedding model, it converts the semantic meaning into an array of floating-point numbers—typically 768 or 1536 dimensions, depending on the model.
Your RAG pipeline takes a customer email, converts it to vectors, stores those vectors in databases like Pinecone or Weaviate, and retrieves similar vectors when queried. The original text might be discarded, but the semantic content—including any sensitive information—remains in numerical form.
Traditional DLP tools scan text using regex patterns and keyword matching. Vector embeddings, however, are mathematically encoded representations that your DLP can't match against a 1536-dimensional array.
Is My DLP Missing This Data?
Yes. Your network DLP inspecting egress traffic sees binary blobs or JSON arrays of numbers. Your endpoint DLP scanning files sees numerical data without context. Your cloud DLP monitoring S3 buckets sees what looks like model artifacts.
None of these tools can reconstruct sensitive information, such as a credit card number, from [0.0234, -0.1123, 0.0856, ...]. The semantic meaning is preserved in the mathematical relationships between dimensions, but it's not detectable with pattern matching.
This creates a gap in your data classification program. You've tagged sensitive documents and configured DLP policies, but your AI pipeline converts everything to vectors and moves it to a new storage layer outside your security perimeter.
Can I Scan Data Before Embedding?
You should, but it's not enough. The issue is state and lifecycle management.
Scanning at ingestion catches obvious problems—like embedding sensitive data into a chatbot. However, vectors are long-lived artifacts that get reused, combined, and moved between systems. Your original document might be subject to PCI DSS v4.0.1 Requirement 3.2.1, but what about the embedding derived from it?
Timing is also a problem. Teams often embed entire document repositories in batch jobs, only to realize later that some documents contained data that shouldn't be in the vector store. Identifying which vectors came from which source documents is challenging, as most vector databases don't maintain that lineage by default.
Additionally, your RAG pipeline might concatenate multiple documents, chunk them differently, or augment them with metadata. The embedding isn't a 1:1 mapping to a source document your DLP already scanned.
Can Vectors Be Decoded Back to Text?
It's theoretically possible but practically expensive. You'd need to run an inverse operation through a language model, asking "what text would produce this embedding?" The computational cost is high, the results are approximate, and scaling this process is challenging.
VectorSmuggle shows that sensitive content persists in embeddings, but it doesn't offer a production-ready scanning solution. Decoding every vector in your database on every write operation to check for PII isn't feasible.
A better approach is to treat vector stores as sensitive data repositories from the start. Apply the same access controls, encryption, and audit logging you'd use for your primary database. If your vectors came from documents requiring SOC 2 Type II controls, your vector database needs those same controls.
How Can I Inventory Where Vectors Are Created?
Start with your AI infrastructure. Look for:
- Embedding API calls to OpenAI, Cohere, or hosted models
- Vector database deployments (Pinecone, Weaviate, Milvus, Qdrant, ChromaDB)
- RAG frameworks in your codebase (LangChain, LlamaIndex, Haystack)
- Jupyter notebooks that import sentence-transformers or similar libraries
Your service mesh or API gateway logs should show embedding service calls. Your infrastructure-as-code should declare vector database resources. Your dependency scanning should flag RAG framework imports.
The challenge is undocumented experimentation. Developers may spin up vector databases for prototypes, embed datasets for testing, and sometimes those experiments become production features without going through your standard review process. Make vector store deployment visible in your architecture review checklist.
What's the Risk? A Scenario
Imagine a team building an internal support chatbot. They embed your entire Confluence wiki, including pages about system architecture, API integration guides, and incident post-mortems. Those embeddings now contain:
- Internal service URLs and endpoint structures
- Database schema details
- Third-party API keys from troubleshooting docs
- Customer names from incident reports
- Details about unpatched vulnerabilities
Your DLP caught some of this in the original Confluence pages. But the vector database is running in a different AWS account, managed by the ML engineering team, without the same access controls or monitoring. An attacker or insider with over-provisioned access can query for semantically similar content to "API key" or "production credentials" and retrieve relevant vectors.
They can't read the vectors directly, but they can use them. Feed those vectors into a RAG pipeline with a language model, and you'll reconstruct the sensitive content. The data left your secured environment in a format your security tools couldn't inspect.
Where Should You Start?
First, map your vector data flows. Document which systems create embeddings, where they're stored, and what source data they contain. Treat this like a data flow diagram for GDPR Article 30 records of processing—you need to know what sensitive data exists in vector format.
Second, extend your data classification to cover vector stores. If the source requires encryption at rest per PCI DSS v4.0.1 Requirement 3.5.1, the derived vectors need the same protection. If the source has retention requirements, the vectors inherit those requirements.
Third, implement access controls and monitoring on vector databases with the same rigor as your production databases. Audit who can query embeddings, log retrieval operations, and alert on bulk exports.
The VectorSmuggle research demonstrates that this isn't a theoretical concern—it's a practical gap in how we secure AI pipelines. Your security architecture needs to account for data that exists in formats your current tools can't inspect.
