What does the evaluation permit us to release?
Separate observed results, inference and release authority, so an attractive score cannot quietly approve a different product.
A permitted answer for Alice is not a permitted cache hit for Ben. Revocation also reaches search indexes, old conversation context and links, where a retrieval-only check can be bypassed.
Alice asks a question and receives an answer from D7, a document she may read. Ben asks the same question and receives the cached answer. He may not read D7, but the cache never asks: its key is just the question. The original search filter can be entirely correct while this shortcut discloses the same material. The speed improvement came from skipping a stage that was doing more than finding relevant text.
D7 is a synthetic teaching note, followed here through the answer, cache, transcript and download link. Each can return its information without running the original search again. Turning a document into a paragraph does not make its access conditions disappear. Keep the source and requester relationships available so those later paths can make their own appropriate decision, rather than inherit permission from whoever happened to ask first.
OWASP recommends deny-by-default authorisation and permission validation on every request. [1] For retrieval, that means more than checking that the person can open the chat interface. It means establishing which content this person may use in this tenant and task, then preserving that decision through every shortcut which can return an answer without the original search.
Derive the requester and tenant from the authenticated application context. Do not accept “I am Alice” in the prompt as the authority to search Alice’s documents. Resolve the relevant groups, relationships and task scope through trusted application controls. A model can help formulate a query; it should not manufacture the permission set which makes its preferred result available.
Apply appropriate scope to retrieval before content is exposed to the model. Where an index supports security metadata and filters, populate and use them through the supported pattern. Microsoft’s current security-filter documentation makes an important distinction: a principal string in a filter is not authentication by itself. [2] The application must establish the principal and apply the correct filter. This is a current technical illustration, not a claim about a particular historical API version.
Retain document identities with candidates so the application can check the relevant authority before assembling context. A text fragment without its document or tenant relationship is harder to validate later. Conversely, a document title or citation URL is not a permission grant. A familiar-looking source may be highly relevant and still lie outside this person’s authorised scope.
Alice can lose group membership while an old index entry still lists her as eligible for D7. Check her current allowed set before putting that text into a new model context. The teaching model excludes it at that point. A real deployment also needs to state how quickly its permission changes reach this check; an index refresh tomorrow is not equivalent to a promise that Alice loses new access now.
The fixture deliberately contains a bad cache keyed by question alone. It can return D7’s text without asking who is requesting it. The safer context function accepts candidate identifiers and filters them through the current user’s allowed set. Initially Alice receives D7 and Ben receives nothing. After Alice’s permission is removed, the same stale candidate list produces no new context for her either.
The downloadable model keeps Alice’s stored transcript after removing D7 from her allowed set. A new retrieval then supplies no D7 context, but reopening the earlier words is another delivery path. This is why the transcript result belongs beside the denied fresh read: a test of retrieval alone could pass while a resumed conversation still carries the material forward. The program uses synthetic documents and no live search service; the product must apply its chosen future-use policy to those retained relationships.
Putting Alice’s name in the cache key can keep her answer away from Ben. It does not decide what Alice may read tomorrow. A private cache may need the tenant, requester and relevant policy revision attached to each entry, with rules for invalidation. Keeping the D7 source identity lets the application recheck it after Alice’s access changes. A cache of approved public material makes a different promise and can use a different scope.
Ben might later gain legitimate access to D7. An old cached denial should not keep telling him the answer is unavailable after the source becomes permitted. Refresh positive and negative entries according to their meaning and the access policy, rather than freezing the first answer forever. The cache should follow Ben’s current eligibility in both directions.
Original document D7 is initially available to Alice but not Ben. Search and cache can retain old candidates after revocation; current authority decides what enters a new context.
Scroll sideways to see all columns.
| Path | Candidate evidence | Current permission | Required result |
|---|---|---|---|
| Alice first request | Search returns D7 | Alice allowed | D7 may enter context |
| Ben same question | Question-only cache has D7 text | Ben denied | Exclude D7 from cache and search |
| Alice after revocation | Stale index/cache still names D7 | Alice denied | Recheck; exclude D7 |
| New query after revocation | Old transcript contains D7 | No current permission | Do not reuse revoked context |
| Previously delivered text | Alice already received it | Permission now withdrawn | Cannot unsend; apply retention policy |
Alice’s earlier transcript still contains D7 after her access changes. A new retrieval check cannot erase delivered text, downloaded copies or information already read. Revocation therefore needs a defined promise about future access and context reuse, with separate retention rules for existing records. The old disclosure remains a fact even when the application correctly excludes D7 from all subsequent retrieval.
When Alice resumes her old conversation, its text is another route back to D7. If its text remains in model context, a new answer can repeat it without any fresh search. Rebuild context from permitted sources, remove affected material from future use or end that session according to the product’s policy; merely asking the model not to use text it still receives offers a different promise.
Alice might also lose access while an answer is being generated. A delivery-time recheck can support current access, while documented snapshot semantics may deliberately permit another treatment. Choose and enforce that behaviour rather than let a few seconds of generation time decide it accidentally.
Apply the relevant retention and access rules to stored transcripts and generated summaries too. Their source-derived information can remain sensitive even if the original file is no longer attached. A policy revision identifier can help identify affected entries, but only if the system preserves the relationships needed to find them. Document revocation and answer retention are related lifecycle questions, not automatically the same setting.
Ben can also click a citation without asking the assistant another question. That download must check whether he may read D7 now. A signed or cached link needs the lifetime and access controls appropriate to that route; the permission decision cannot stop at the answer that originally displayed it. Otherwise fixing Ben’s cache result still leaves him another way into the same document.
D7 can persist in stored information after Alice loses fresh retrieval access.
Scroll sideways to see all columns.
| Path | Why fresh search filtering is insufficient | Policy to define |
|---|---|---|
| Old conversation supplied to model | D7 text is already in context | Rebuild or remove affected future context |
| In-flight response | Permission can change between retrieval and delivery | Delivery recheck or documented snapshot semantics |
| Stored transcript or summary | Source-derived content remains sensitive | Separate retention and access lifecycle |
| Cached or signed link | Later download is another delivery path | Current access checks and appropriate lifetime |
A useful access test matrix includes Alice, Ben, another tenant, a permission change, a stale index result, a cache hit and a resumed conversation. Inspect which source content reaches the generated context and which links remain usable. Testing only the search endpoint can miss a correct filter bypassed by the application’s answer cache. Testing only the final wording can miss unauthorised content already supplied to the model.
Ben’s denial should help him continue without disclosing protected details. Explain that his available authorised sources do not establish an answer, or offer the supported access-request route. Naming a confidential document just to demonstrate that the check worked could reveal information the denial was meant to protect. Choose the message under the product’s disclosure rules for Ben’s task.
Rechecking sources, invalidating caches and keeping their relationships costs effort and time. Supported snapshots and scoped caches can make that manageable, but the shortcut still has to keep the access promise the product makes. If current authority cannot be determined, use the defined failure path. An old answer being ready to return is a performance fact, not a reason to disclose its source to somebody who can no longer read it.
The practical check is to repeat Ben’s question and Alice’s question after revocation through every route that can answer: cache, resumed conversation and later link as well as search. Keep the D7 relationship long enough to make those decisions. Nothing can unsend the text Alice already received, but the application can control its supported future uses. That is the promise worth testing when a cache makes the answer arrive faster.
Working on a workflow like this? Hamsa helps finance and operations teams connect their tools and handle the exceptions, starting with one workflow.
See the Payment Operations PilotPrimary sources behind this article. Living documentation may change.

Practical engineering. A human perspective.
More about Hamsa Software and the person behind it. Editorial notes.