TL;DR
Enterprise RAG security begins before the first question reaches the model. Decide which sources may enter the platform, which processing services may receive their contents, and which restrictions must survive extraction, chunking, embedding, and storage.
Treat derived artifacts as governed data, not disposable implementation details. Preserve source identity and policy references, prevent unapproved processing routes, and build revocation, quarantine, deletion, and restore validation into the operating model. A private model endpoint is useful, but it is not evidence that the complete information path is private.
The objective is to make enterprise knowledge more useful without making its boundaries less meaningful.
Introduction
Consider a hypothetical enterprise support assistant connected to general recovery procedures and customer-specific incident reports.
An engineer asks what the organization learned from a regional outage. The assistant returns a technically accurate explanation covering the affected customer, recovery sequence, and root cause. The answer is detailed, relevant, and supported by a real document.
The engineer, however, was authorized to read the general recovery guidance, not that customer’s incident report.
The model did not need to hallucinate. The application distributed accurate information to the wrong audience.
That is the architectural tension behind this series. Retrieval-augmented generation, or RAG, brings external information into the context used to generate an answer. The surrounding platform must preserve the restrictions that apply to that information as it moves and changes form.
I would therefore review a RAG deployment as a new information-distribution system, not simply a search feature attached to a language model.
This first article focuses on source admission, processing boundaries, derived data, and lifecycle controls. Part 2 addresses request-time retrieval permissions. Part 3 addresses citations, evidence, and disclosure. The design assumes an enterprise assistant using an indexed corpus, without training model weights on that corpus.
Separate Admission, Processing, and Disclosure
For this architecture, make three decisions explicit.
Admission determines whether a source may enter the RAG platform for an approved purpose. A connector’s ability to read a repository does not establish business approval to ingest everything it can reach.
Processing determines which services, identities, locations, and retention arrangements may handle the admitted content. That decision includes extraction and embedding, not only the final model.
Disclosure determines which information the platform may release to a particular recipient. Approval to operate an indexing service is not approval to disclose its entire corpus.
These decisions should constrain one another without collapsing into one permission flag. In the support scenario, the platform might be approved to ingest Customer A’s reports and process them through a designated service, while only Customer A’s support team may receive answers derived from them.
The following is a proposed control layout. Notice that admission happens before ordinary processing, while user authorization remains a separate requirement later in the path.
The diagram describes enforcement responsibilities, not necessarily separate products. A managed service may implement several stages. The review still needs to identify which component makes each decision and how its behavior is verified.
Map the Copies, Not Just the Main Pipeline
Start the data-boundary review with one representative restricted document. Trace what the deployed application actually creates from it.
Inspect temporary extraction files, queued job payloads, text chunks, vectors, reranker inputs, generated summaries, conversation history, diagnostic traces, evaluation datasets, and recovery copies. Not every implementation creates every artifact. The requirement is to account for the ones yours does.
For each artifact, record its owner, permitted readers, processing destination, retention rule, and removal mechanism. Include services that handle content only transiently, since persistent storage is not the only boundary worth reviewing.
A useful review question is: Where could an operator obtain this information without opening the original repository?
For example, suppose an engineer exports a failed production request into a development evaluation dataset. In this proposed model, that export is a new data movement requiring approval. Calling the destination a test environment does not exempt it from the source restrictions.
Use synthetic or specifically approved test content by default. Production-derived evaluation data needs an accountable owner and a lifecycle of its own.
Embeddings Do Not Make Sensitive Information Anonymous
An embedding represents content numerically. That transformation is not, by itself, evidence of anonymization.
The research paper Text Embeddings Reveal (Almost) As Much As Text, published at EMNLP 2023, demonstrated text reconstruction from embeddings under defined experimental conditions, including recovery of names from clinical-note data. It does not establish that every vector from every model can be perfectly reversed. It does establish that numerical representation is not a sufficient privacy argument.
My starting policy would be to protect embeddings according to their source sensitivity unless a documented assessment supports different treatment.
That policy should govern direct vector access as well as the text associated with the vector. Exporting a vector collection to a less controlled environment needs scrutiny even when the export omits the original document bodies.
Preserve the Security Context When Documents Become Chunks
A source document and its searchable fragments need a durable relationship.
OWASP’s Retrieval-Augmented Generation (RAG) Security Cheat Sheet identifies lost access-control metadata during chunking as a security risk. It also distinguishes ingestion-time permission checks from the checks required when content is retrieved.
For the support assistant, I would use the following metadata contract. These are proposed requirements, not a standard vendor schema.
| Metadata group | Information to retain | Operational purpose |
|---|---|---|
| Source identity | Repository, document identifier, source revision, owner | Locate the authoritative record and its accountable owner |
| Transformation lineage | Chunk identifier, parent identifier, content digest, transformation revision | Identify which processing produced the artifact |
| Access policy | Tenant boundary, policy reference, policy revision, classification | Preserve restrictions without asking the model to infer them |
| Processing policy | Approved use and processing-route reference | Determine where the artifact may be handled |
| Lifecycle state | Retention policy, serving status, deletion or quarantine marker | Withdraw or retire dependent artifacts consistently |
Some fields can travel with each chunk. Others can reference a trusted registry. Either approach needs a defined response when the registry is unavailable or the reference is invalid.
A field existing is not sufficient. The pipeline must validate its value and provenance. A document author should not be able to widen access by inserting a sentence that says the document is public.
Microsoft’s Azure AI Search index-projection documentation provides a concrete implementation example: parent content can be projected into child chunks, and parent fields can be repeated or placed in separate indexes. That mapping must be deliberate. Security metadata deserves the same attention as the title and document identifier.
Keep Content Revision and Permission Revision Separate
In this design, use separate revision identifiers for the document content and its policy state.
A permission change must trigger the necessary policy update and serving restrictions even when the document text has not changed. Do not make access changes wait for an embedding refresh merely because the current ingestion job couples those operations.
Whether the platform can update metadata independently is an implementation detail to verify. The requirement is that its actual mechanism meets the access-change objective.
Likewise, a content digest helps compare captured bytes with an expected version. It does not establish that the document is accurate, that its publisher is trustworthy, or that yesterday’s permissions still apply.
A Summary Must Not Broaden the Audience
Suppose a generated summary combines an internal recovery procedure with a restricted customer report.
For this proposed policy, a recipient must satisfy every applicable source restriction before receiving the combined artifact. Do not merge the source allow lists into a larger audience.
A reviewed redaction or aggregation workflow may produce an independently approved, less restricted artifact. Treat that as an explicit release process. Shorter wording is not evidence that sensitive information has disappeared.
Choose Isolation Around the Failure You Need to Contain
Decide what must remain protected if an application bug, credential compromise, or administrative mistake occurs.
OWASP’s Multi-Tenant Application Security Cheat Sheet describes isolation as conditional on credentials, policy enforcement, administrative access, and operational arrangements. A namespace is not a complete security boundary merely because it carries a customer’s name.
For this RAG design, compare the following options:
| Pattern | Where it may fit | Boundary to verify |
|---|---|---|
| Shared index with enforced policy | A common platform whose data classes permit shared processing | Every serving path applies the intended tenant and document restrictions |
| Separate indexes or collections | Workloads needing distinct corpus management or narrower service access | Credentials and administrative interfaces cannot bypass the intended separation |
| Dedicated processing and storage | Workloads requiring stronger separation of data, operators, or processing environments | The separation includes identities, keys, telemetry, and recovery, not only the vector store |
This is not a universal security ranking. A dedicated deployment with broadly shared administrator credentials may fail the specific boundary the organization intended to create.
Document the failure each isolation choice is meant to contain. Then test that failure using the deployed identities, including maintenance and recovery identities.
Approve the Complete Processing Route
A private index does not answer where an embedding service processes its input. A private generation endpoint does not answer where a separate reranker receives its candidate passages.
Microsoft’s documentation for Models sold by Azure in Microsoft Foundry illustrates why these questions must remain separate. It distinguishes stored data from inference processing, describes different processing boundaries for Global and DataZone deployments, and identifies features that persist application state.
A commitment not to train foundation models on customer inputs is therefore not equivalent to a commitment that no feature stores those inputs or that every operation stays in one selected region.
For the proposed architecture, register an approved processing route for each relevant data class. That route should identify permitted services, deployment types, locations, and retention settings, including any failover destination.
Check the route before sending content, not after generation.
If the approved embedding service is unavailable, do not silently switch to an unapproved endpoint to preserve ingestion throughput. Hold the affected work or use a separately approved alternative. Apply the same rule to parsers, document-analysis services, scanners, rerankers, and evaluation tools.
Ingestion Must Protect Both the Parser and the Model
There are two different problems at this boundary.
The first is conventional file processing. OWASP’s File Upload Cheat Sheet identifies parser exploitation, oversized or malicious inputs, and active content among the risks. Use maintained parsers, bounded resources, validated file types, and appropriate scanning or isolation. Any external scanning service also needs approval to receive the content.
The second is instruction handling. OWASP’s LLM Prompt Injection Prevention Cheat Sheet describes indirect prompt injection through external material, including retrieved documents.
An approved repository can establish where a document came from without giving its text authority over the application. In the support example, a runbook may explain a recovery procedure. It cannot grant the assistant permission to export incident records.
Use content screening and clear separation between retrieved material and application instructions as defensive layers. Keep access decisions, outbound restrictions, and tool authorization outside the model’s discretion. Passing a content scan should not promote document text into executable policy.
Turn the Boundary into a Source Admission Contract
The implementation artifact below describes a proposed contract for the Customer A incident corpus. It is illustrative YAML for a control service you would implement, not configuration accepted directly by Azure AI Search or a vector database.
The contract identifies the approved source and purpose, requires lineage and policy metadata, and prevents publication when a required decision cannot be established.
schema_version: "1.0"
source:
id: customer-a-incidents
owner: customer-a-service-owner
approved_scope: customer-a-incident-library
approved_use: support-assistance
processing:
route_profile: customer-a-approved-route-v3
unapproved_fallback: deny
required_metadata:
- document_id
- source_revision
- content_digest
- chunk_id
- parent_id
- transformation_revision
- tenant_id
- policy_ref
- policy_revision
- classification
- retention_policy_ref
admission:
initial_state: staged
unresolved_policy: hold
invalid_metadata: hold
unapproved_route: deny
publish_requires:
- source_scope_verified
- metadata_validated
- policy_resolved
- processing_route_approved
- current_revision_confirmed
- no_active_retirement_marker
recovery:
reconcile_current_policy_before_serving: true
reconcile_retirement_markers_before_serving: true
Replace the source, ownership, scope, and route identifiers with records controlled by your organization. Resolve classification and policy information from approved authorities, not from model-generated labels alone.
The source-scope and route checks must run before sending content to a processor. The publication checks then verify that the completed artifacts remain eligible to enter the serving index.
Define a strict schema and reject unknown or unsupported settings. A misspelled control that the application silently ignores is not an acceptable deployment outcome.
Success means that an eligible document becomes available through the authorized retrieval path with complete lineage. A missing policy reference leaves the document in a restricted holding state and produces an actionable reason for its owner. It does not become generally searchable.
Holding new content need not stop an independently authorized corpus from serving. Conversely, continuing to serve existing content still requires valid request-time authorization. Admission is not a permanent access grant.
Revocation, Quarantine, and Deletion Are Different Operations
Give these operations separate meanings in the platform contract.
Revocation removes a principal’s access or withdraws an approved use. The content may remain available for other authorized purposes and recipients.
Quarantine stops ordinary serving because the content or processing path is under investigation. Protected evidence may remain available to designated responders.
Deletion removes artifacts according to their governing retention and erasure requirements. It requires accounting for downstream copies, not just the original document.
Microsoft’s Azure Storage indexer documentation makes an important implementation distinction: change detection and deletion detection are separate. Its deletion guidance also describes configuration and timing requirements. A healthy content-refresh job is not evidence that removed source documents have disappeared from search.
Track Retirement Through the Dependent Artifacts
For this design, maintain a dependency record from each source revision to its chunks, vectors, generated summaries, and reusable answers.
Use an explicit retirement marker, often called a tombstone, to prevent withdrawn content from returning through delayed ingestion or recovery. A proposed lifecycle is:
Make processing idempotent, so repeating a retirement event does not reverse or corrupt the intended result. Prevent an older queued indexing job from overwriting newer retirement state. The exact implementation may use source generations, conditional writes, or a separately maintained serving registry.
Recovery Must Not Reauthorize Old Data
A restored index represents a previous data state. It should not determine the current security state.
Before a recovered index serves traffic, reconcile it with current permissions, quarantine decisions, and retirement markers. Protect those records through a recovery strategy that does not simply roll them back with the same snapshot.
Where immediate physical removal from a retained backup is unavailable, document the approved retention handling, access restrictions, and restore-time suppression. Do not report complete erasure merely because the live index no longer returns the document.
Prove the Boundary Before Expanding the Corpus
Start with a limited pilot containing synthetic internal and customer-restricted documents. Use distinctive, nonsecret markers to trace where their contents travel.
The following are proposed acceptance tests, not reported results:
| Test | Expected evidence |
|---|---|
| Remove a required policy reference | The document remains nonservable and its owner receives a specific failure reason |
| Attempt an unapproved processing fallback | The transfer is blocked before content reaches the alternative service |
| Quarantine a source revision | Its dependent content stops serving through ordinary application paths |
| Deliver an old indexing job after retirement | The job cannot reactivate the withdrawn content |
| Restore an index created before withdrawal | Reconciliation excludes the retired content before traffic is admitted |
Inspect the enforcing component and downstream artifacts. An absence of sensitive text in the final answer does not establish that the text never reached another processor.
Include successful authorized cases as well. The acceptance objective is a useful system with enforced boundaries, not a system that avoids disclosure by answering nothing.
Give the Operating Model an Owner
The data owner should approve source scope and permitted use. The platform team should own transformation, storage, and lifecycle propagation. Security should define the enforcement and evidence requirements. Assign one service owner responsibility for the complete path and unresolved exceptions.
Monitor held documents, stale policy state, orphaned artifacts, retirement propagation, and restored content awaiting reconciliation. Define alert ownership and acceptable delays before production rather than borrowing a convenient indexer schedule.
Keep observability from becoming an uncontrolled second corpus. OWASP’s Logging Cheat Sheet recommends excluding or protecting sensitive information and restricting access to logs. Prefer identifiers, revisions, decisions, and bounded diagnostic records over unrestricted copies of source text.
Conclusion
Secure enterprise RAG begins with a data contract, not a model-selection decision.
The platform needs to know which sources it may admit, where their contents may be processed, which restrictions accompany every derived artifact, and how those artifacts stop serving when policy or lifecycle state changes.
The next practical step is to trace one restricted document through the real application. Account for every processor and retained copy, establish the source admission contract, and test withdrawal and recovery before increasing the corpus.
The model can change how enterprise knowledge is expressed. It should not change who is entitled to receive it.
Part 2, Retrieval Permissions Must Follow the User, Not the Service Account, moves from governing the corpus to authorizing each request.
External References
- Microsoft: Data, privacy, and security for Models sold by Azure in Microsoft Foundry
Canonical URL: https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy - Microsoft: Define an index projection for parent-child indexing
Canonical URL: https://learn.microsoft.com/en-us/azure/search/search-how-to-define-index-projections - Microsoft: Change and delete detection using indexers for Azure Storage in Azure AI Search
Canonical URL: https://learn.microsoft.com/en-us/azure/search/search-how-to-index-azure-blob-changed-deleted - OWASP: Retrieval-Augmented Generation (RAG) Security Cheat Sheet
Canonical URL: https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html - OWASP: Multi-Tenant Application Security Cheat Sheet
Canonical URL: https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html - OWASP: File Upload Cheat Sheet
Canonical URL: https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html - OWASP: LLM Prompt Injection Prevention Cheat Sheet
Canonical URL: https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - OWASP: Logging Cheat Sheet
Canonical URL: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html - Association for Computational Linguistics: Text Embeddings Reveal (Almost) As Much As Text
Canonical URL: https://aclanthology.org/2023.emnlp-main.765/
TL;DR Enterprise AI decommissioning should remove a service’s ability to accept work, access information, execute actions, or return through deployment and recovery...