TRUST-IT Content reviewed
DECISION BRIEF
What you will be able to decide
For: Enterprise AI architects, security teams and owners of confidential knowledge collections.
Approve a RAG release only when retrieval, citations, cache and history follow an explicit access policy.
- Enforce identity and document permissions outside the language model.
- Test access changes across indexes, caches and citation endpoints.
- Use synthetic markers and both authorised and denied test cases.
Treat permission-aware retrieval as an end-to-end property
Retrieval-augmented generation, or RAG, adds retrieved material to a model’s context. This can improve the usefulness of an answer, but a fluent response does not establish that the underlying documents were authorised for the requester. Define the protected objects: full documents, chunks, metadata, citations, images, conversation history and cached answers.
Draw the route from source connector to index, retrieval service, model, response store and interface. At each boundary, record which identity is acting and which policy permits the operation. A broad ingestion account may need to read multiple collections; that authority must not automatically become the authority of every user asking a question.
Carry access metadata through ingestion and transformation
Assign stable source and document identifiers, tenant or organisation context, classification, ownership and the permissions required for retrieval. Record the source version and the time at which permissions were evaluated. When splitting a document into chunks, preserve the link between every chunk and its governing access policy. Derived summaries and extracted tables also need a defined policy.
Plan for document moves, deletions, changed group membership, shared links, guest expiry and inherited permissions. Define how updates reach the index and how obsolete chunks are removed. An index built correctly on Monday can expose information on Tuesday if permission changes are not propagated or checked again at retrieval.
Related primary guidance: Microsoft — Document-level access control
Resolve identity and authorisation on the trusted server path
Derive the requester’s identity and organisation from the authenticated session and a trusted identity source. Do not accept a tenant identifier, group list or document entitlement supplied only in a chat message or editable browser field. Construct mandatory access filters on the server and apply them to every retrieval path.
Check semantic search, keyword fallback, hybrid retrieval, reranking, document previews and direct citation downloads. A filter on the main vector query cannot protect a second endpoint that fetches the same document by identifier without authorisation. Search ranking should select useful material from the permitted set, not determine which material the user is entitled to see.
Set a measurable revocation rule
Define how quickly a source permission change must prevent a new disclosure, and which systems enforce that rule. Permission synchronisation, group caches, access tokens and application caches can each introduce delay. Choose a design that meets the agreed requirement; time-to-live values alone may not be sufficient when access must end immediately.
Test a sequence: grant access, retrieve a synthetic marker, revoke access, then repeat through normal search, paraphrased questions, citations and a warm cache. Record the observed delay and the configuration involved. Removing access cannot retract an answer already delivered. Define separately whether retained conversations may continue to display earlier authorised material, and who can access that history.
An access boundary through the complete RAG path
Apply the same effective permissions to retrieval, source links and reused answers.
- AuthenticateTrusted user and tenant context
- AuthoriseCurrent document permissions
- RetrievePermitted chunks and metadata
- GenerateAuthorised context only
- DeliverProtected citations, cache and history
When entitlement checks are unavailable, restricted content must follow the agreed fail-closed policy. A fluent model answer cannot grant access.
Keep caches, memory and exports inside the same boundary
A shared cache keyed only by question can return one user’s privileged answer to another user. Key or partition cached material by the relevant security context, including tenant and effective permissions, and invalidate it when that context changes. Apply a deliberate policy to semantic caches, conversation memory, saved summaries, downloads and background jobs.
Protect the objects around the answer as well. A document title, snippet, filename or citation may reveal sensitive information even when the body is withheld. A signed download link also needs appropriate audience and lifetime restrictions. Verify that logs, traces and support tools do not create a more widely accessible copy of protected prompts or retrieved passages.
Keep document instructions separate from execution authority
Retrieved documents can contain instructions intended to manipulate an assistant. Test whether such content can broaden a search, change an output destination or trigger a tool. The model should receive only authorised material, and tool handlers must enforce their own permissions independently of text generated from that material.
Use synthetic documents and harmless markers to assess cross-boundary disclosure and unintended actions. Treat instructions from an external source as untrusted content. Model refusals and prompt wording can support the user experience, but the enforceable boundary belongs in identity, retrieval, policy and execution controls.
Related primary guidance: OWASP — Vector and embedding weaknesses
Build a test matrix with both allowed and denied cases
Create test users representing different departments, organisations, guests and administrators. Seed controlled documents with unique synthetic markers and known access rules. For every denied case, include a legitimate case that should succeed; a system that returns nothing to everyone has not demonstrated a usable solution.
Test exact titles, broad questions, related concepts, absent documents, duplicate chunks, revoked groups, expired guests, broken connectors and missing permission metadata. Repeat relevant cases through all retrieval and download routes. Record requested identity, effective policy, candidate and returned source identifiers, configuration version and outcome. Minimise logged content while retaining enough evidence to reproduce the result.
Make the release decision specific and repeatable
Before release, agree unacceptable failures, permitted restrictions and the evidence required from the development team. A single successful synthetic cross-tenant disclosure is a boundary failure in that tested path; an average answer-quality score cannot offset it. If the authorisation service or permission metadata is unavailable, decide which requests must fail closed and how the user is informed.
The review package should include a data-flow diagram, identity and permission map, revocation requirement, test catalogue, results, known limitations and recovery procedure. Re-run affected tests after connector, index, model, policy or caching changes. Report readiness only within the tested configuration and scope, with a named owner for outstanding risks.
WORKED EXAMPLE
A revoked entitlement meets a warm answer cache
Illustrative scenario, not a client case. A test user can initially access a synthetic acquisition document. After removal from the deal group, the normal search endpoint denies access, but a previously cached answer still contains the document’s unique test marker.
- Evidence and checks
- The assessment records the group change, policy version, retrieval decision and cache path. It repeats the question using a paraphrase, a direct citation and a second test user. The team verifies that cached answers were shared without the relevant permission context.
- Supported conclusion and next action
- The result is a demonstrated disclosure in the tested cache path. The team partitions or invalidates cached material and retests revocation, citation access and legitimate retrieval. The release decision records the tested revocation interval and the separate policy for already-delivered conversation history.
What to request from your provider
Use these criteria to compare the proposed work and review the result. The scope and acceptance checks should be agreed before delivery.
Swipe across the table to see all columns.
| Deliverable | What it includes | Acceptance check |
|---|---|---|
| Identity and data-flow map | Connectors, document policies, chunks, caches and endpoints. | Every route to protected content has an identified authorisation check. |
| Revocation contract | Required delay, update mechanism and cache invalidation. | A removed entitlement prevents new disclosure within the agreed boundary. |
| Test catalogue | Users, synthetic markers, allow/deny expectations and configuration. | Cross-user and cross-tenant cases include legitimate controls. |
| Release evidence | Results, traces, gaps, restrictions and re-test triggers. | A named owner accepts only the recorded scope and configuration. |
TAKE THIS INTO YOUR NEXT MEETING
Your preparation checklist
- Map source documents, chunks, metadata, citations, cache and history.
- Resolve users and tenants from trusted authentication, not chat inputs.
- Define permission propagation and the required revocation interval.
- Test exact queries, paraphrases, direct links and warm-cache responses.
- Use synthetic markers with both authorised and denied users.
- Record release versions, failures, restrictions and re-test triggers.
Use the bilingual workbook for notes or the editable CSV to assign owners and evidence references. These are preparation templates, not a completed assessment.
Further reading
Put the guidance to work
Permission-aware knowledge assistants for policies, technical documentation and internal knowledge, with source references and measurable evaluation.
Enterprise knowledge AI