A document can be carefully redacted and still be the wrong document for a particular person to retrieve. Removing a customer’s name from a loan file, for example, does not necessarily make the remaining financial details appropriate for every employee. A retrieval-augmented generation (RAG) application must decide both what enters its index and which portions a particular user may access at the time of a request.
These are separate controls. Redaction changes content according to a policy. Authorization determines who may use a resource for a particular purpose. Neither control replaces the other, and neither alone makes a RAG system immune to malicious instructions embedded in documents.
The following is a proposed design and test approach for enterprise AI and security teams. It is not a claim that any single product supplies every control, nor a guarantee of legal compliance.
Start with a use and a recipient
Before indexing, document the intended task, the people or systems allowed to perform it, and the information they actually need. A support assistant answering product-policy questions may need the current policy document, but not the customer-specific case notes alongside it. A restricted case-review assistant may need those notes, but only for an authorized case team.
For each source collection, record:
- The business purpose and accountable owner.
- Permitted user groups and the source of their entitlements.
- The fields or passages to remove, retain or review.
- Whether external processing is permitted and under what conditions.
- The reviewer, retention period and process for correcting or withdrawing a source.
Treat this as a working decision record, not a generic promise that an entire file is safe. Some combinations of retained details can remain sensitive even after obvious identifiers are removed. The appropriate decision depends on the content, recipient and context.
Create a controlled derivative, not an unrestricted copy
Prepare a derivative within the approved environment. Apply the agreed content policy, then have an authorized reviewer inspect difficult material and the output. Checks should address the visible page and the exported artifact: a black rectangle is not, by itself, evidence that underlying content is gone. Search or text extraction can reveal some failures, but a successful search alone cannot prove complete removal. Images, hidden layers, attachments and metadata may need their own review.
Give the approved derivative its own identity and version. Preserve a link to the source in a protected audit record, not necessarily in the content visible to every downstream user. Record which policy was applied, who approved the release and what exceptions remain. The GritWorks redaction evaluation checklist offers a starting point for checking output and evidence.
The derivative still needs a classification and an access policy. If the source contains confidential commercial terms, an address redaction does not transform it into public information. Restrict the derivative to the purpose for which it was approved.
Carry the access boundary into retrieval
A RAG pipeline typically splits content into smaller chunks, indexes them and retrieves relevant chunks for a user’s question. The security decision must survive each transformation. If a chunk loses its source policy, a retrieval system cannot reliably tell whether the requesting user is permitted to receive it.
At minimum, design for these questions:
- Which source and approved derivative did each chunk come from?
- Which policy or entitlement applies to it, and who owns that policy?
- How will a user’s current identity and permissions be checked at retrieval time?
- What happens if permissions are missing, ambiguous or stale?
- How are updates, withdrawals and deleted documents propagated to derived chunks and caches?
- Who can access embeddings, indexes, logs and evaluation datasets, not only the original files?
The implementation varies. A team might partition indexes by sensitivity or enforce policy filters within a retrieval service. Either way, apply authorization in trusted application infrastructure; do not rely on a prompt telling the model not to reveal restricted content. Deny or escalate when the system cannot establish permission. The OWASP RAG Security Cheat Sheet discusses access-control metadata, permission-aware retrieval and document lifecycle risks.
Avoid putting sensitive values into labels or logs merely because metadata is convenient. Metadata itself can disclose information and needs its own access and retention controls. Also make sure changes to source permissions are reflected in the index: a user who was entitled yesterday may not be entitled today.
Walk through an illustrative example
Imagine a fictional bank preparing a RAG assistant for lending operations. Its source contains public product rules, internal procedures and customer-specific files. The assistant’s intended initial purpose is to answer questions about internal procedures, not retrieve customer case files.
First, the team excludes customer files from the initial collection. It reviews the remaining procedures, redacts unnecessary names and contact details, and approves a derivative for the relevant operations group. Each approved document receives an owner, version and policy identifier. The retrieval service checks the employee’s current entitlement before passing eligible chunks to the model.
Now consider a user who can access general guidance but not a restricted exception procedure. A question that closely matches the restricted procedure should not cause its text or citation to appear merely because it is semantically relevant. The expected behavior is an authorized answer from permitted material or a refusal/limited response. The test should inspect retrieved chunks, citations and logs as well as the final answer.
This example is illustrative. Actual permissions, retention obligations and acceptable use need to be determined by the organization responsible for the data.
Test denied paths as deliberately as allowed paths
A demonstration using an authorized account shows that retrieval works; it does not establish that restrictions work. Build a small test set with fictional or approved content and explicit expected outcomes:
- An authorized user asks an in-scope question. The system retrieves permitted, current content and cites it where appropriate.
- A user without the relevant entitlement asks the same question. Restricted chunks, summaries and citations must not be returned.
- A source is reclassified or permission is revoked. Check that the updated decision reaches indexes, caches and subsequent requests.
- A document is removed or corrected. Check whether the prior chunk, embedding, cached answer and evaluation copy remain and follow the organization’s deletion process.
- A source contains an instruction to ignore policy or disclose another document. Treat the instruction as untrusted content and check that it does not alter authorization or system behavior.
- A document has incomplete or conflicting metadata. Verify that it is withheld or escalated rather than assigned broad access by default.
Record the user identity or test role, source version, policy version, query, retrieved chunk identifiers and observed result. Protect the test logs themselves. Add regression cases whenever permissions, chunking, indexing or retrieval logic changes. A passing suite provides evidence for the cases tested, not proof that every possible path is secure.
Separate content preparation from the rest of the system
GritRedact is designed to detect and redact sensitive information in documents, images and audio, with human review and audit evidence. GritWorks describes offline on-premises and sales-assisted SaaS deployment options. Confirm the chosen deployment, data flow and required controls for your use case.
The surrounding RAG application still needs identity, authorization, permission-aware retrieval, source lifecycle management and testing. Do not assume that redacting a document changes permissions in a vector store or downstream application. Those integrations and controls must be designed and verified in the environment where the assistant runs.
For teams planning a controlled document workflow, start with a narrow collection, a named audience and a handful of allowed and denied test cases. Then expand only after the owner understands what content moves, who can retrieve it and how policy changes take effect. Discuss your workflow with GritWorks.
