Retrieval is not permission

For engineers connecting private documents to an agent, and the reviewers asked whether its answers reach only the readers entitled to them.

An agent finds the perfect internal document, answers the question accurately and cites its source. That still leaves a basic question unanswered: was this reader entitled to see it?

Microsoft's Azure search demo provides a useful concrete starting point because its configuration distinguishes enabling login from enforcing document access. In the pinned implementation, the authentication helper obtains a search token on the user's behalf and forwards it when access control is enabled. Both ordinary and semantic search branches accept that token. These are code paths to inspect, not proof that a deployed copy has the right configuration. Authentication helper (opens in a new tab), search branches (opens in a new tab), configuration guide (opens in a new tab)

For an engineer connecting private knowledge to an agent, the important design task is preserving the intended audience through every copy: source, index, retrieved passage, answer, cache, citation and subsequent action.

One question, two legitimate answers

Consider a fictional support assistant. Amira and Ben both ask: “What is the migration plan for Example Customer?” Amira belongs to the account team. Ben belongs to general support.

The source collection contains a public migration guide and a restricted account plan. Amira may read both. Ben may read only the public guide. A useful system should give Ben the relevant public procedure and explain the limits of the available evidence. It should not invent an account-specific answer, disclose the restricted plan or refuse all migration questions.

Now add a cache keyed only by normalized question. Amira asks first, and the stored answer includes a private launch date. Ben asks the identical question later. If the application returns the cached answer without an access decision, the source search can be perfectly filtered and the overall workflow can still disclose the date.

This is a deliberately constructed failure case. We are not asserting that the Azure sample has that cache. It shows why reviewing the retrieval request alone cannot establish the confidentiality of the whole application.

Separate service access from reader access

A backend identity may need permission to query the index. That does not mean every person using the backend may read every indexed document. The application needs a trustworthy way to establish the reader and apply the intended document policy.

An alternative design uses application-supplied query filters. Microsoft's security-filter documentation explicitly distinguishes matching principal strings from authentication: the filter pattern does not authenticate those strings. It also warns that hiding a permissions field from returned results is not a substitute for applying the security filter to every query. Microsoft, updated August 24, 2026 (opens in a new tab)

For that pattern, the key review question is who constructs the principals. A user-supplied group=account-team parameter should not become evidence of group membership. Neither should a retrieved passage claiming the user has permission. The trusted application boundary must derive and constrain the filter.

For a service-enforced design, inspect the equivalent identity path and configuration. Do not assume that adopting a particular search provider settles the caller's identity, index setup or document metadata. Those are inputs to enforcement.

A copy needs an access policy

An index is a copy of content. A generated summary is another copy of information from that content. Neither automatically acquires a correct access boundary simply because its source had one.

Microsoft's current query-time ACL documentation labels the capability preview and describes permission metadata ingested alongside content. It explicitly discusses freshness: some source changes need a resync, while custom ingestion needs affected documents reingested. It also documents failure without partially filtered results when ACL evaluation fails. These are vendor-described conditions, not a universal statement that permissions follow every source change immediately. Microsoft, updated September 17, 2026 (opens in a new tab)

This preview illustrates an enforcement design; it is not a recommendation to depend on the preview for a production confidentiality boundary.

Apply that distinction to the fictional account plan. Suppose Amira loses access after producing a draft. There are several possible policies: prohibit future retrieval, prohibit opening previous drafts, or allow retention of material legitimately received earlier. The product owner must choose the intended behavior. A source revocation cannot recall information a person has already learned.

The engineering review then asks which stored artifacts the policy covers and how they become unavailable. If the requirement is immediate revocation but permission propagation is delayed, the design has an unresolved mismatch. “The index has ACL fields” does not resolve it.

Inspect the second route to the same information

An answer's citation often opens the original file through a different route. The pinned Azure demo includes a separate check_path_auth helper. With access control enabled, it checks for a matching source-file or source-page result using the user's search token. The helper returns early when enforcement is disabled. This is evidence of a distinct check in the source, not a complete audit of every route that calls it. Pinned source-path helper, lines 180–207 (opens in a new tab)

That second route deserves its own test. A citation preview, a download endpoint, an exported transcript and a conversation-sharing link can have different identities and storage policies. A protected search result does not establish that these routes enforce the same audience.

The same applies to information placed in operational systems. A debug trace containing retrieved passages is another destination. Before adding detailed traces to diagnose retrieval, decide who may read them and how long the private material remains there. Better observability can create another copy requiring protection.

Choose a cache policy you can actually explain

For our two-user task, three designs deserve comparison:

A per-user key is an improvement over a question-only key, but it does not solve revocation for that same user. A tenant key does not distinguish two groups inside a tenant. A list of source IDs helps only if the serving path actually evaluates the policy before releasing the answer.

For an early support assistant, start without cross-user answer reuse for restricted content. Keep shared caching for material explicitly eligible for the shared audience. This is a simplicity recommendation for the example, not a performance result or a ban on authorization-aware caches.

The serious counterargument is cost. Repeating retrieval and generation may be too slow or expensive. If that becomes an observed constraint, preserve the authorization invariant while optimizing the expensive stage. Do not quietly trade it away because the cache hit rate looks good.

Reading a document does not authorize its instructions

Even correctly authorized content can be misleading, obsolete or attacker-controlled. A document that Ben may read can tell the agent to export the whole account folder. The document's access policy answers who can receive its content. It does not grant permission for that export.

Keep the next action separate. The tool's execution identity, resource scope and task policy need to justify the export; the retrieved text is evidence to interpret, not an authority to widen the task. For a customer reply, an authorized internal answer still needs a decision about which details may leave the support workspace.

This is where retrieval security joins agent security. A system can enforce the correct read boundary and still give a document too much influence over writes. Conversely, a strong action gate cannot undo private text already sent to the wrong reader.

Test pairs, changes and alternate routes

A useful acceptance set needs more than one forbidden document. Start with Amira and Ben asking the same question, then reverse their order. Change group membership. Revoke source access. Repeat with a warm cache and with an existing conversation. Open the citation directly. Ask a permitted document to request an unrelated action.

Include a positive case in every pass: Ben should still get the public migration procedure, and Amira should still get the authorized internal answer. Otherwise a system that returns nothing could appear successful.

The retrieval review packet makes these proposed cases explicit as R01–R15. On October 23 we ran ten of them locally against pinned code, as described below. The rest, and every service-side decision, need an Azure tenant, a search service and a document collection, and we used none. Record where each decision occurs and what evidence would establish the result. Do not submit real private passages to a test system whose handling is unresolved.

What was executed

On October 23 we ran ten of the R01–R15 cases locally, with no model and no cloud service, against two pieces of real code. The first was the pinned Azure demo's own backend modules, unmodified, with Entra ID, Azure AI Search and Cosmos DB replaced by local stubs. The second was LangChain's in-memory and SQLite response caches in front of a scripted fake model.

The cache key we observed is the prompt plus the model parameters. No caller identity enters it unless the application puts it there. A per-user key stopped Ben from seeing Amira's answer, but it still served her the date after her access was removed. With document enforcement switched off, any valid token from the same tenant opened the restricted file, as the demo's docstring for that route says.

These observations cover one pinned revision's application layer and one cache library. Our stubs made every service-side decision, and we inspected no deployed configuration. Method, all statuses and limits

An accurate answer is useful only after the application has established who may receive it. Follow one answer all the way from its source to its final audience. The gap is often between two individually reasonable components.

---

Evidence and limits: source register. The demo is pinned to its July 27, 2026 revision; the pinned code and the live vendor documentation were re-checked on October 22, 2026, and the documentation still carries its August 24 and September 17 dates. On October 23, 2026 ten of the paired-user cases were run locally against the pinned backend code and LangChain's caches, with services stubbed (record). No current tenant configuration, service-side decision, performance, cache in the demo or end-to-end route coverage was verified. Apply it: retrieval review packet · Boundary decision records.