How are recurring controls different from a RAG security checklist?

The checklist decides whether one defined release can enter production. Recurring controls test the changing corpus and entitlements, along with caches and routes. They also test policies and evidence after launch. A passed release pack supplies the baseline. Daily, weekly, monthly, and quarterly records show whether production still matches it.

Does a gateway run every RAG security control?

A gateway can inspect managed HTTP requests after the application assembles retrieved context. It can classify content, apply destination policy, inspect responses, and record decisions. Ingestion provenance and vector-store permissions remain with the systems that own those functions. Those systems also own tenant namespaces and source deletion, along with cache design and sink authorization.

Which event should reopen the release review?

Reopen it after a new corpus class or connector. An index or embedding design change also qualifies. The same applies to altered tenant isolation or a new model destination. Reopen the review for a changed prompt assembly path or a new response sink. A revised retention design, serious incident, or repeated control failure should also trigger a new review.

RAG Security Controls for Recurring Production Operations

A RAG service can pass its release review on Friday and retrieve a newly synced payroll file on Monday. RAG security controls become useful after launch only when named owners run them on a schedule and preserve objective evidence. They also need to escalate failed thresholds. The RAG security checklist defines the pre-release evidence pack. This article defines the recurring operating record for the production service.

TL;DR

Review every corpus and connector change before its content enters the active index, with provenance and classification attached to each batch.
Run retrieval authorization canaries and assembled-prompt policy tests on a fixed cadence. Keep the results by tenant and route, along with the policy version.
Verify deletion across the active index and caches. Track expiring exceptions and rehearse incident reconstruction against a timed objective.
Sign a monthly control attestation that names failed controls, affected requests, owners, and the next decision.

RAG security controls need an operating register

Start with one register per production RAG service. Record the corpus snapshot and index version. Add connector versions and the retrieval policy. Include the prompt template and model routes, then document response sinks and retention rules. The register should also name the owners. Every recurring test should point back to that baseline and identify the period it covered.

NIST's Generative AI Profile recommends inventory entries that include data provenance and source signatures or versions. The entries also cover known issues and foundation models. Access modes complete the inventory. Its GOVERN 1.5 actions also call for periodic review of content provenance and incident monitoring. The register turns those outcomes into a dated production artifact rather than a diagram that went stale after launch.

Evidence: keep a versioned register export and approved owner list. Add a change log that resolves every active component to a reviewed state.

Daily corpus changes require admission evidence

The ingestion owner should review each sync batch before activation. Record the source and connector identity, followed by the collection time and document count. Add the classification outcome and rejected items. Finish with the transformation version and the principal used to read the source. New sources and changed permissions deserve separate approval.

Search the batch for untraceable documents and unexpected regulated data. Check separately for instruction-like content that could become indirect prompt injection. Quarantine failures rather than allowing the connector to finish with a green sync icon. The RAG poisoning prevention guide covers malicious source content in detail.

Escalation: stop activation when provenance is missing or the source permission model cannot be reproduced. The same action applies when the rejected-content rate crosses the service's approved threshold. Preserve the batch manifest and quarantine decision.

Retrieval authorization canaries run every week

The retrieval owner should maintain test identities with different tenant and document entitlements. Place a visible canary in a restricted document and query the same topic as each identity. Save the candidate set before ranking, along with the final retrieved chunks. Repeat after any entitlement, namespace, metadata-filter, or cache-key change.

A passing model answer is weak evidence because the model may omit content it received. The test passes when the unauthorized identity's candidate set excludes the restricted document before prompt assembly. The RAG security architecture places this control at the retrieval boundary, outside the model gateway.

Evidence: save the authenticated principal and tenant for every run. Keep the query and filter expression. Add candidate identifiers and ranked results, then record the cache state and retrieval-policy version.

Prompt and response controls need sampled proof

Security operations should sample managed requests each week and retain all blocks and redactions. Policy errors also need to be retained. The sample needs the complete assembled request after retrieval and conversation history have been added. It should also record the destination and active policy version. On the return path, record response treatment and sink.

NIST AI 600-1 describes indirect prompt injection through remotely retrieved content. A recurring test should place a synthetic instruction and a regulated-data marker in approved test documents, then confirm the outbound HTTP request receives the expected block or redaction before provider transmission. A second test should verify response inspection with a synthetic marker.

Escalation: any bypass, unknown destination, missing identity, or policy-evaluation failure opens an incident. A screenshot of a block page cannot replace the request identifier and signed decision record.

Deletion and retention need timed verification

The data owner should select one test document each month and follow it through source deletion and index removal. The check should continue through cache expiry and evaluation stores. It must also cover prompt traces and response records. Record the deletion request time and the completion time for every active store. Backups need a documented expiry and restoration treatment.

Query the canary before deletion and after each stage. The active service should stop retrieving the content within its stated objective. If a cache remains callable after index deletion, the control failed even though the connector reports success.

Evidence: keep the source event and affected chunk identifiers. Add the index operation and cache test. Preserve the post-deletion query results and completion timestamps. State any approved retention basis.

Exceptions expire and incidents get rehearsed

The control owner should review open exceptions weekly. Each exception needs its scope and affected tenant or route. Record the compensating measure and approver. Add the start time and expiry, then define the closure test. An expired exception should close the affected path or return to approval. I would treat a permanent prompt-policy bypass as an undocumented product feature, not an exception.

Quarterly, run a timed reconstruction exercise using one allowed request and one denied request. NIST SP 800-53 Revision 5 defines audit-record content in AU-3, including what occurred and when. It also records where the event occurred and its source. The remaining fields cover the outcome and associated identity. The RAG timeline should identify retrieved sources and assembled-prompt classification. It should also show the model destination and policy version. Record the response treatment as well.

Picture the incident review screen at 09:10. One timeline has eight linked events. A blank space between retrieval and provider transmission identifies the exact evidence gap the exercise was meant to find.

Monthly attestation drives the next decision

The service owner should sign a monthly attestation covering corpus admission and authorization canaries. It should address prompt and response tests, followed by deletion and open exceptions. Reconstruction readiness completes the record. Show the denominator for each control. Three successful tests say little when 400 index changes occurred.

List every failure with its affected scope and first observed time. Record containment and owner. Add the due date and closure evidence. The signer chooses continue, restrict, suspend, or reopen formal review. Material changes should return to the pre-release checklist rather than being absorbed into the monthly report.

DeepInspect

DeepInspect covers the managed HTTP boundary between a RAG application and its LLM endpoints. It uses application-supplied identity and context, classifies the complete assembled request, applies versioned content and destination policy, inspects the response, and records permit, redaction, reroute, or block decisions before traffic proceeds.

Those signed records support weekly sampling and exception review. They also support incident reconstruction for managed traffic. Corpus provenance, retrieval authorization, index deletion, caches, and application sinks remain outside that boundary. Book a technical deep dive at deepinspect.ai.