Securing the
Embedding Pipeline

Most RAG security thinking focuses on the vector database itself. That is the wrong place to start. By the time data reaches the vector store, it has already passed through four or five steps where an attacker could have introduced malicious content, corrupted the embedding, or caused sensitive data to be exposed.

The embedding pipeline is the full sequence from raw document to stored vector. Each step is a distinct control point. If any step lacks proper controls, everything downstream inherits that weakness. A document that was not sanitised at ingestion becomes a poisoning vector. An embedding model that was not verified becomes a supply chain risk. A vector generated from plaintext that is never encrypted is vulnerable at every step between generation and storage.

The Cisco 2024 white paper on securing vector databases states this directly: a secure embedding pipeline ensures that data is sanitised, classified, and monitored before it becomes part of the retrieval system. That principle governs every section in this module.

Document ingestion is where external content enters your system. Everything that happens here affects every component downstream. A malicious document that passes ingestion without scrutiny becomes an embedded vector in your database and a potential retrieval result for your users.

The three things ingestion controls must do: validate that the document is what it claims to be, sanitise it to remove dangerous content, and classify it so access controls can be applied correctly at retrieval time.

Every document that enters the ingestion pipeline should be assigned a classification level before embedding. This classification label becomes part of the metadata attached to each vector at storage time. At retrieval time, the label is used to enforce access controls so that only users with the appropriate clearance see documents from each classification level.

Classification must happen at ingestion, not as an afterthought. If a document is embedded without a classification label, the metadata cannot be retroactively added reliably because you would need to re-embed and re-index every chunk. Set up classification as part of the ingestion pipeline from day one.

Chunking splits source documents into smaller segments that each become a separate embedding. The purpose is retrievability: a 50-page contract should not become a single vector that gets retrieved in its entirety for a narrow question. You want to retrieve only the relevant paragraph.

But chunking creates security problems that teams rarely think about. The way you split a document determines what information can be retrieved separately, what context gets lost at chunk boundaries, and how an attacker can position poisoned content to be retrieved for specific queries.

Chunking strategy recommendations: Use semantic chunking (splitting on paragraph and section boundaries) rather than fixed-size character chunking. Fixed-size chunking often splits sentences mid-thought, creating chunks that lack enough context to be meaningful and increasing the chance of boundary leakage. Add overlapping context windows where each chunk includes the last sentence of the previous chunk and the first sentence of the next, so retrieval provides coherent context.

For documents with mixed classification content (a contract with both standard terms and confidential pricing), chunk at section boundaries and apply per-chunk classification labels rather than document-level labels. This is more work to implement but prevents high-sensitivity chunks from being retrieved in low-sensitivity contexts.

The embedding model is the component that determines what every vector in your database actually represents. If this model is backdoored, substituted, or manipulated, an attacker can control how documents map to the embedding space without ever touching your database. Every vector you have ever stored becomes compromised from the moment the bad model was used.

This is not theoretical. Backdoored machine learning models have been published on public repositories. The Hugging Face MTEB leaderboard lists hundreds of embedding models, many from organisations with no verifiable security posture. Using any of these without verification is a supply chain risk.

Standard encryption at rest protects vectors stored on disk. It does not protect vectors that are in memory during indexing, in transit between the application and the database, being processed by the orchestration layer, or visible to any service with database query access.

Encrypt-at-embed means the vector is encrypted immediately after it is generated, before it is passed to any other system. The encrypted vector is what gets stored, indexed, and queried. The plaintext vector never leaves the embedding step.

Vector embeddings are the main data in a vector database, but metadata is often more sensitive in practice. Metadata fields like document IDs, customer references, employee numbers, and classification labels directly identify what a vector represents. An attacker who reads metadata does not need to invert the embedding. The metadata already tells them what the document is about.

Standard encryption of metadata creates a problem: many retrieval workflows filter results by metadata values. If a customer service application needs to retrieve only documents relevant to customer ID 84721, it passes that filter to the vector database. If the customer ID field is encrypted with standard AES, the filter no longer works because the encrypted value of 84721 does not match the stored encrypted value unless the query uses exactly the same key and nonce, which requires a more complex query structure.

Format-preserving encryption (FPE) solves this. FPE encrypts a value while preserving its format. A 10-digit number stays a 10-digit number. A string in a specific pattern stays in that pattern. The encrypted value is different from the original but looks identical in format, so existing filter logic continues to work.

VectaX includes FPE for metadata fields as part of the SDK. You define which fields require FPE during the policy configuration step, and the SDK handles encryption and decryption transparently when reading and writing metadata. The key is held separately from the database, so a compromised database does not expose the metadata values.

Input validation sits at the boundary between the ingestion controls and the embedding step. Its job is to reject anything that does not conform to what the pipeline expects. The Cisco 2024 white paper on securing vector databases specifically names input validation and sanitisation as mitigations for malicious vector injection. The principle is simple: if you only accept inputs you understand, you have a much smaller attack surface than if you accept everything and try to neutralise bad content after the fact.

Input validation rejects known-bad inputs. Anomaly detection catches patterns that are not obviously wrong but are statistically unusual. The Cisco white paper recommends both together: validate individual inputs, and separately monitor the aggregate pattern of insertions over time.

Anomaly detection on write events is the closest thing to an intrusion detection system for your embedding pipeline. Here are the signals that matter most.

Graph embeddings are used in enterprise RAG systems that query structured relational data: knowledge graphs, org charts, social networks, supply chain relationships, or any domain where connections between entities matter as much as the entities themselves. Instead of embedding flat documents, graph embedding encodes the structure of a graph into vectors.

The security concerns for graph embeddings overlap with those for document embeddings but add one important additional risk: inverse lookup attacks on graph structure. If an attacker can extract graph embeddings, they may be able to reconstruct not just the content of individual nodes but the relationships between them. This is often more sensitive than the content itself. Knowing that person A reported to person B and was connected to project C tells an attacker something about organisational structure that individual documents would not reveal.

The Cisco white paper recommends using graph attention networks (GATs) to encode graphs because they apply selective attention to neighbouring nodes and edges, meaning the embedding focuses on the most structurally important connections rather than encoding the full graph topology. This reduces the information available to an inversion attack.

The cross-matrix fusion method mentioned in the Cisco paper applies an additional transformation to the encoded feature vectors before storage. This transformation is designed to make it harder to recover the original graph structure from the stored vectors, even with knowledge of the GAT architecture. Combined with VectaX encryption, it creates two separate barriers against graph structure reconstruction.

Individual pipeline controls protect individual steps. The VectaX secure agents pipeline is the architectural pattern that connects all of these controls into a coherent system where data is encrypted from the point it enters the pipeline through to model serving, with no plaintext windows in between.

This matters for agentic RAG systems in particular. An AI agent that can ingest new documents, retrieve existing ones, generate responses, and take actions based on retrieved content needs security that spans all of those operations. A control that only protects the vector database does not cover the agent's tool calls, its context window, or the documents it generates as outputs.

The MongoDB integration described in Mirror Security's technical blog demonstrates this pattern in production. MongoDB handles TLS, encryption at rest, queryable encryption, and CSFLE for scalar data. VectaX adds vector-specific encryption, AI-centric RBAC, and encrypted similarity search on top. The AgentIQ policy engine governs what the agent can do with retrieved data. Together the three layers cover scalar data, vector data, and agent behaviour.

Use this as a review checklist before deploying a RAG embedding pipeline to production. Each item corresponds to a section in this module.