Carry access control through the retrieval system
A well-sourced answer can still disclose information to someone without permission to see it. Carry entitlement through ingestion, retrieval, caching and revocation, and test access separately from answer quality.
Keep development and test groups separate before comparing performance. No measured results are shown.
Consider a document assistant that answers an employee’s question using a restricted board paper. The answer may be accurate and well sourced while exposing information that employee is not entitled to read. This is an illustrative failure, not a report of an Institute client incident.
The source store, retrieval engine and language model may each behave as configured. The missing requirement lies between them: the service must apply the requester’s entitlement to the evidence it supplies. Component accuracy cannot compensate for that omitted access rule.
Assess retrieval quality and access control together, while testing each separately. An index can preserve permissions when the design carries and enforces them. The review must establish how that works for the actual source systems and requesting identities.
Where the permissions go missing
Enterprise documents carry permissions in their source systems. Ingestion must preserve the information needed to enforce those permissions or obtain a current decision from an authoritative access service. Check the connector’s actual behaviour. Reading content does not establish that the downstream index has retained the source entitlement.
Extraction, chunking and embedding create derived copies whose access controls need explicit design. Database capabilities vary, and a shared service credential does not by itself express each employee’s permission. OWASP identifies vector and embedding weaknesses in its 2025 Top 10 for LLM Applications, including access-control failures in shared vector stores. This establishes a recognised risk category, rather than its prevalence in enterprise systems.
- 01 Ingestion Read the access control alongside the content, or it is gone.
- 02 Chunking Every chunk inherits the permission of its source document.
- 03 Retrieval Filter by the requester’s entitlement before ranking, not after.
- 04 Answering The model only ever sees material this requester could have opened.
Test both the confidentiality and retrieval-quality consequences of filtering. Removing disallowed passages after selecting the highest-ranked candidates can leave useful permitted material outside the candidate set. It must also happen before any restricted content reaches the model, cache or user. An empty result can reveal information in some contexts, but that possibility needs a threat assessment rather than a universal leakage claim.
Where the retrieval store supports it, constrain the search to permitted material before ranking. Where it does not, establish an alternative that enforces access before disclosure and measure its retrieval limitations. Resolve entitlement at query time against an agreed freshness requirement.
Test the access boundary
Permission changes and source deletions require propagation or current access checks. Test both. A document withdrawn at source can remain in a derived index if the service has no effective removal mechanism. Define the allowed delay and the owner who confirms that withdrawal has reached the relevant copies.
Caching introduces a further access boundary. A question-only key can reuse an answer across users with different permissions. Include the relevant entitlement scope in the cache design, and invalidate or revalidate entries when permissions or source material change. Equivalent question text does not establish equivalent authority.
Aggregation can reveal sensitive conclusions even when each source document is individually permitted. Per-document controls alone may be insufficient. Assess the sensitivity of combined material, consider restricted corpora and output controls, and retain an appropriate trace of the evidence used. These controls need evaluation against the specific disclosure scenario.
What to require in the design review
The design questions are short and they are answerable in a design review.
Where does the entitlement come from at query time — is it the requesting user’s own token, or a service identity? Is the filter applied before ranking or after? What happens when a source document’s permissions change? What is the maximum staleness of the permission data, and who agreed to it? Is the entitlement scope part of any cache key? And does the trace record which permission set was applied, so that a disputed answer can be reconstructed?
Ask the delivery team to demonstrate those rules with allowed and denied requests, changed permissions and cached answers. Record the results and unresolved cases in the design decision. The useful distinction is between an asserted access policy and evidence that the service enforces it.
Carry entitlement through the answer path
Illustrative employee request for internal policy evidence.
Swipe or scroll for the full diagram →
Trace retained
Retain appropriate source revisions and permission context for an authorised review.
- Requesting identity
- Resolve the employee and the relevant permission context.
- Permitted candidates
- Constrain evidence before disclosure and evaluate the retrieval method.
- Evidence supplied
- Only permitted passages enter the model context.
- Cache checked
- Reused answers respect current entitlement, source changes and freshness.
- Trace retained
- Retain appropriate source revisions and permission context for an authorised review.
Representative method for this article, not a measured deployment result.
Operational sequence: Requesting identity, Permitted candidates, Evidence supplied, Cache checked, Trace retained. Each step has an accompanying explanation.
Reviewed 2026-10-02
What this does not tell you
Entitlement-aware retrieval does not make an index safe to build over everything. Some material should not be in a general index at any permission level, and the decision about what goes in is a data classification decision that precedes the architecture. A system that filters correctly over a corpus that should never have been assembled is still the wrong system.
It also does not address the model layer. Everything above concerns what the model is given. What it does with that material — how faithfully it attributes, whether it reveals the existence of documents it declined to use — is a separate problem with separate controls.
The retrieval owner should settle entitlement, revocation and permitted corpus scope before selecting the model and store. These requirements influence downstream choices and migration costs. Accept the design only after the team has shown how access remains effective across the complete answer path.