A Technical blog series on where sensitive data moves in an AI workflow, what decisions Protecto makes at each point, and what enterprises get from enforcing policy once instead of everywhere.
Contents
Introduction The Six Places Enterprise AI Touches Sensitive Data
Pattern 4 · MCP Gateway Your Agents’ Tools See More Than Your Agents Do: Protecto as the MCP Gateway
Pattern 5 · Agent Gateway When One Agent Hands a Case to Another: Protecto as the Agent Gateway
Pattern 6 · RAG PipelineThe Archive That Answers Back: Protecto in the RAG Pipeline ← You are here
PATTERN 6 · RAG PIPELINE
The Archive That Answers Back: Protecto in the RAG Pipeline
Every company is turning its document archive into a knowledge base for AI: chunk the documents, embed them, let agents retrieve what’s relevant. It works, and that’s the problem. Retrieval doesn’t know the difference between a useful precedent and another customer’s private story, and it serves both with equal enthusiasm. This article shows where Protecto fits in data policy in the RAG pipeline, why there are two enforcement points rather than one, and what each one buys.
Part of a series on the six places Protecto fits into an AI workflow. Each article stands alone: a real-world style use case, where Protecto sits, what changes, and what the business gets out of it.
The situation
Atlas Insurance built a claims-history knowledge base so its AI agents could reason from precedent: thirty years of claims, medical reports, and settlement records, chunked and embedded into a vector database. Ask about a rear-end collision with a soft tissue injury, and the system retrieves how similar claims were evaluated and settled. Adjusters love it. The story is an insurer’s, but a bank’s dispute archive, a hospital’s case summaries, or a SaaS company’s support history behave the same way once embedded.
Here’s what makes RAG different from every other integration point in this series: the data is at rest before any AI ever runs. The exposure was created months ago, at ingestion, when documents were embedded exactly as written. In this article’s setup, the vector database stores the embeddings alongside the source text chunks and metadata, which is a common configuration; some deployments store embeddings and metadata only and fetch text from elsewhere, which moves where enforcement must sit but not whether it’s needed.
So when an agent queries for “rear-end collision, soft tissue injury,” similarity search does its job faithfully: it returns the most similar past cases, complete with other policyholders’ names, identifiers, and medical narratives, straight into the agent’s context. The query was legitimate. The retrieval was accurate. The exposure happened anyway.
Why the usual fixes miss
Access control on the index doesn’t solve it, because the agents querying the index are all authorized. The problem isn’t who can query; it’s what comes back and what happens to it.
Scrubbing documents before ingestion with blunt redaction creates the familiar double failure. Strip too much and the chunks lose the meaning retrieval depends on; a case narrative with the injuries, treatments, and outcomes removed no longer matches the queries it should answer. Strip too little and the sensitive content is embedded permanently, because whatever went into the index is served again on every similar query, to every agent, indefinitely. An index is not a log you can rotate. It’s a memory you keep consulting.
What changes with Protecto
Protecto fits a RAG pipeline at two points, and they protect against different things.
At ingestion, before chunking and embedding, Protecto detects sensitive values and protects the identifiers while preserving the descriptive content the embedding needs to be useful. What lands in the vector database is a chunk that still means what it meant, minus who it was about.
At retrieval, after the search but before context assembly, Protecto applies policy to what was retrieved, based on the verified user, agent, and task making the request. The same retrieved precedent can legitimately look different to different requesters.
The decisions, concretely
A past claim document arrives at ingestion:
Claim CL-1088 (2022). Robert Chen, SSN 543-90-2277, policy P-40887. Rear-end collision on I-80. Soft tissue injury, 14 physical therapy sessions, treatment completed. Settled $23,500 after invoice review. Attorney involved after initial denial.
What gets embedded and stored:
Claim CL-1088 (2022). [NAME_8d12], SSN [SSN_e330], policy [POL_51c9]. Rear-end collision on I-80. Soft tissue injury, 14 physical therapy sessions, treatment completed. Settled $23,500 after invoice review. Attorney involved after initial denial.
The identifiers are protected; the substance, the injury, the treatment arc, the settlement path, is intact, because that substance is exactly what future queries need to match against.
Be precise about what this does and doesn’t cover, because “the index is protected” is easy to over-read. What changes is the text that goes into chunking and embedding, so the stored chunks carry placeholders. What does not change on its own: the embeddings themselves, which are derived from content and are not a privacy control; the metadata you attach to each chunk, which frequently carries the very identifiers you just protected in the text and needs its own policy; the source repository the documents came from, which still holds the originals; backups and snapshots of the index; and retrieval logs, which can reconstruct sensitive content query by query.
Everything a vector store needed before, access control, encryption at rest and in transit, retention and deletion paths including the ability to remove a person’s data, and a plan for re-indexing when policy changes, it still needs. This pattern reduces what the index reveals; it doesn’t retire the controls around it. One honest engineering note belongs here: protection choices can affect retrieval quality. Protecting identifiers usually has limited effect, but transforming meaning-bearing content like injury descriptions can change what similarity search returns, so the right practice is to evaluate retrieval quality after transformation rather than assume it, and tune the policy with that evidence.
Now retrieval. Two different requesters trigger the same search and get the same chunk back from the index, and then policy renders it differently.
The adjuster’s agent, working an active claim valuation for a verified senior adjuster:
Precedent CL-1088 (2022): rear-end collision, soft tissue injury, 14 PT sessions. Settled $23,500 after invoice review. Attorney involved after initial denial.
The customer-facing chatbot, answering a policyholder’s “how do claims like mine usually go?”:
Similar past claims involved soft tissue injuries with completed physical therapy and were resolved after invoice review. Typical timelines run 6 to 10 weeks.
The adjuster gets the settlement figure and the litigation signal, because valuing claims is that role’s job. The customer-facing rendering keeps the pattern and drops the numbers, because publishing settlement anchors to claimants is a business decision Atlas gets to make once, as policy, rather than hoping every prompt engineer remembers it. And if a task ever requires reaching the actual claimant of a precedent case, unmasking isn’t a privilege the agent owns. It is controlled by policies defined for the user and the task, and Protecto applies the appropriate policy, ensuring that each agent receives only the level of access to sensitive data it needs.
What customers get
| Advantage | What it means in practice |
| Reduced exposure in the stored chunks | Where source text is stored alongside embeddings, that text holds placeholders instead of direct identifiers, so an over-shared index reveals less. It reduces blast radius; it does not replace access control, encryption, retention limits, or backup hygiene |
| Retrieval that respects roles | The same knowledge base serves adjusters, chatbots, and analysts, each seeing what their policy allows. One corpus, many audiences, no forked indexes |
| Precedent value survives protection | Identifiers are protected while descriptive content keeps its meaning, so the knowledge base stays useful for the searches it was built for |
| Protection that predates the question | Ingestion-time enforcement means the data was already protected before any agent, prompt, or model existed to mishandle it |
| One policy for a growing corpus | New documents inherit ingestion rules automatically; new requesters inherit retrieval rules. The archive grows without the review burden growing with it |
What this doesn’t do
Retrieval-time policy governs what enters context from the index; it doesn’t govern what the agent then does with it, which is the in-agent pattern’s job, and the model call itself is the AI gateway’s. A corpus embedded raw before Protecto arrived stays raw until re-indexed, and re-indexing thirty years of documents is a real project with a real budget; the practical sequence for existing corpora is retrieval-time enforcement first, re-indexing on a schedule. Retrieval-quality impact is measurable and usually manageable, but it is not zero, which is why the evaluation step above is part of the pattern rather than an optional extra.
When this pattern is the right one
Reach for RAG-pipeline enforcement whenever a knowledge base is built from documents that mention real people or confidential outcomes, which in practice is nearly every enterprise corpus worth retrieving from. It’s the only pattern in this series that protects data at rest, before any workflow runs, and it’s the natural companion to gateway patterns rather than a competitor: the gateway governs the road, this governs the warehouse.
Look elsewhere when the sensitive flow isn’t retrieval: model traffic points to the AI gateway, tool calls to the MCP gateway, and agent handoffs to the agent gateway.