# Enterprise RAG Security Checklist: Lock Down Your Retrieval Layer > Source: https://netray.co/tools/enterprise-rag-security-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A practical control checklist covering entitlement-aware retrieval, corpus data governance, query security, model integrity, and audit for enterprise RAG systems. ## Category on-prem-ai ## Tool **Kind:** checklist **Groups:** #### Corpus access control **Items:** **Text:** Retrieval is filtered by the requesting user's real entitlements before any content reaches the model, not after **Critical:** true **Text:** Document permissions are pulled live or synced regularly from the source system, not hardcoded at index time **Critical:** true No single index or corpus spans multiple confidentiality tiers without per-document entitlement filtering Group and role membership changes propagate to retrieval-layer permissions within a defined window Service accounts used for ingestion have read-only access scoped to the specific document sources they process A documented test suite verifies that a user cannot retrieve content outside their entitlements through query phrasing #### Data governance for the corpus **Items:** **Text:** Export-controlled, classified, and personally identifiable content is identified and handled per policy before embedding **Critical:** true Vector database and document store are encrypted at rest with keys managed outside the AI platform A documented deletion path removes a source document from the corpus, the vector index, and any derived caches Document versioning ensures superseded content is removed from the index, not left retrievable alongside the current version Sensitive fields are redacted or tokenized before text enters embeddings or long-term logs Data retention periods for indexed content and query logs are explicitly defined and enforced #### Query and prompt security **Items:** **Text:** The retrieval pipeline defends against prompt injection embedded inside retrieved documents, not just user input **Critical:** true Output filtering blocks known-sensitive patterns such as credentials, export-controlled identifiers, and personal data Rate limits and request size caps are enforced per identity to contain abuse and cost runaway Retrieved content is clearly delineated from system instructions in the prompt structure to reduce injection risk API access requires authenticated service identities with per-application credentials, never a shared key #### Model and retrieval integrity **Items:** **Text:** Embedding and reranking model weights are downloaded from verified sources with recorded checksums **Critical:** true A process exists for detecting corpus poisoning, where malicious documents are deliberately indexed to bias retrieval Citation verification confirms generated answers are actually supported by the passages the model was given Model and embedding versions are recorded per index so a quality regression can be traced to a specific change Third-party embedding and reranking model licenses are reviewed for commercial use restrictions #### Monitoring, audit, and incident response **Items:** **Text:** Every query is logged with identity, timestamp, retrieved document IDs, and a request correlation ID **Critical:** true Logs are shipped to a tamper-evident SIEM outside the AI platform and retained per your compliance framework Anomaly alerts fire on unusual query volume, bulk retrieval patterns, and repeated permission-boundary probing An incident response runbook specifically covers retrieval-layer data leakage and corpus poisoning scenarios Red-team testing for permission bypass and prompt injection through retrieved content runs before launch and at least annually **Scoring Note:** A production-ready enterprise RAG deployment is defensible when at least 90% of all items are complete and every critical item is closed. Any open critical item, especially unfiltered entitlement-aware retrieval, should block a production launch: an assistant that surfaces content a user could not see in the source system is both a security incident and a compliance finding waiting to happen. ## Content **Intro:** This free enterprise RAG security checklist covers the controls needed to run a retrieval-augmented generation system safely against a real enterprise document corpus, and it is written for security architects, IT directors, and AI platform leads at manufacturers with ITAR, CMMC, or customer flow-down obligations. It spans five domains: corpus access control, data governance, query and prompt security, model and retrieval integrity, and monitoring and audit. RAG introduces a security surface most enterprise security programs have never assessed, because a vector database is effectively a second copy of your document estate operating under a completely different, and often much weaker, permission model. **Sections:** #### Why RAG needs its own security review **Body:** A document management system enforces permissions at the file level, and users generally understand and expect that structure. A RAG system flattens that structure into chunks in a vector index and, unless deliberately engineered otherwise, serves the most relevant chunk to whoever asks, regardless of whether they could open the source file. This is not a hypothetical risk; it is the default outcome of indexing a corpus without building entitlement-aware retrieval, and it routinely surfaces restricted content to users who never had access to the original document. #### The controls that matter most **Body:** Roughly a quarter of the items here are marked critical because they close paths that are difficult or impossible to detect after the fact. Entitlement-aware retrieval failures are silent: nothing crashes, nothing alerts, a user simply receives an answer that should not have been possible. Prompt injection through retrieved documents is similarly quiet, since a malicious instruction embedded in an indexed document can manipulate model behavior without any obvious signature in the user's own query. Close these first. **Bullets:** - Entitlement-aware retrieval enforced at query time, not just at the document repository. - Live or regularly synced permission data so access changes actually propagate to the retrieval layer. - Defense against prompt injection embedded in retrieved documents, not just in user-typed input. - Complete query logging with retrieved document IDs, so an investigation has evidence to work with. #### How to work through the list **Body:** Run it as a gated review with named owners per domain: platform engineering for access control and integrity, security for query defenses and monitoring, and a data or compliance function for governance. Score honestly, since a partially implemented entitlement filter is still an open control. Close every critical item before production traffic reaches real users, then work the remainder on a dated plan. Re-run the checklist whenever a new document source is added to the corpus or a new user population is granted access, since either change can silently invalidate a permission-boundary assumption that was valid at initial launch. #### How Netray secures RAG deployments for regulated manufacturers **Body:** Netray builds retrieval-augmented generation systems for aerospace, defense, and electronics manufacturers where the security posture of the retrieval layer is a project requirement, not an afterthought. We build entitlement-aware retrieval that mirrors your ERP and PLM permission model directly, implement defenses against injection embedded in retrieved content, and produce audit evidence packages your assessors can actually use. Because we also build the SyteLine, LN, M3, and ServiceMax integration layer, entitlements stay consistent between the source system and the AI assistant rather than drifting apart over time. **Cta:** Get a control-by-control review of your RAG deployment with entitlement-aware retrieval verified against your ERP permission model. **Faq:** #### What is entitlement-aware retrieval and why does it matter more than model security? **Answer:** Entitlement-aware retrieval means the search layer filters candidate documents by the requesting user's actual permissions before anything reaches the model, so the model is never even shown content the user should not see. It matters more than most model-level defenses because it closes the most common and most severe real-world failure: an assistant confidently answering a question using a restricted document, with no indication to the user that anything unusual happened. Without it, every other security control in the pipeline is protecting the wrong layer. #### Can prompt injection come from inside my own documents? **Answer:** Yes, and this is a frequently underestimated risk. A document with an embedded instruction like ignoring prior guidance or revealing system prompts can manipulate the model when it is retrieved and included in context, entirely independent of what the user actually typed. This risk grows with any corpus that includes externally sourced or user-uploaded content. Defenses include clearly delineating retrieved content from system instructions in the prompt structure and treating retrieved text as untrusted data, not as trusted instructions. #### How do I test whether entitlement-aware retrieval actually works? **Answer:** Build a documented test suite with accounts representing different permission levels, then attempt to retrieve restricted content through varied query phrasing designed to route around obvious filters. Test both direct requests and indirect ones, such as asking for a summary of a topic that only appears in a restricted document. Run this suite before launch and after any change to the corpus, the retrieval logic, or the permission sync mechanism, since any of the three can silently break the filtering. #### Is corpus poisoning a realistic threat for an internal document set? **Answer:** It is realistic wherever the ingestion pipeline includes content from sources with weaker write controls than your core document management system: shared drives, wikis, ticketing systems, or any source where a broader population can create or edit content. A deliberately crafted document designed to bias retrieval toward incorrect information, or to embed an injection payload, can enter the corpus through any such source. Restricting ingestion sources and monitoring for anomalous new content are the practical mitigations. ## Search terms RAG security checklist, retrieval augmented generation security, entitlement aware retrieval, vector database security, RAG access control, enterprise AI corpus governance, prompt injection RAG defense --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json