# Retrieval boundaries — source dossier and editorial boundaries

**Research ID K09 · Checked September 21, 2026 · Static public-source analysis.** Supports [Retrieval is not permission](/blog/retrieval-is-not-permission) and the [review packet](/resources/retrieval-review.md). No Azure account, search service, model or real document collection was used.

**Public copy prepared 2026-10-22.** Pins re-checked: revision 3f4a21f0 (committer date 2026-07-27T20:00:14Z) of `authentication.py` (`get_auth_claims_if_enabled` at line 142, `check_path_auth` at lines 180–207, previously cited as 180–205), `approaches/approach.py` (`search()` at lines 287–326, previously cited as 288–327, passing `query_source_authorization` at lines 317 and 325) and `docs/login_and_acl.md` (the enable/enforce steps start at line 65; the article anchor previously pointed at blank line 64); the two Microsoft pages still carry updated dates of 2026-08-24 and 2026-09-17 and still state the quoted conditions. Not re-checked: anything requiring an Azure tenant, search service or document collection; every proposed case in the review packet remains NOT RUN.

## Admission test

- **Decision:** whether an agent's private-document answer reaches only its intended audience across retrieval and reuse.
- **Implementation:** Azure's public search demo passes an end-user token into search and contains a separate source-path check.
- **Open question:** whether all paths in a given deployment preserve that boundary through caches, history and subsequent actions.
- **RA contribution:** a two-user, changing-permission scenario; compare three reuse designs; retain a positive task outcome in each proposed test.
- **Evidence that changes the recommendation:** observed costs that justify an authorization-aware shared cache, or a product policy that explicitly permits retention after source revocation.

## Full bibliography and observations

All sources below were checked **2026-09-21**. Pinned sample repository revision: **3f4a21f03ae3d565aca37cc300e3d38b0c7b582a**, committer date **2026-07-27T20:00:14Z**. This is a code snapshot, not the deployed configuration of any reader.

| ID | Citation and date | Direct observation / confidence | Limitation / refresh trigger |
|---|---|---|---|
| K09-1 | Microsoft/Azure Samples contributors. `app/backend/core/authentication.py`, pinned revision above. [Source](https://github.com/Azure-Samples/azure-search-openai-demo/blob/3f4a21f03ae3d565aca37cc300e3d38b0c7b582a/app/backend/core/authentication.py). Primary implementation. | Lines 142–207: token handling is conditional on configuration; separate source-path check queries with caller token. High for static reading. | No full auth audit or route coverage claim; inspect deployed revision and callers before security advice. |
| K09-2 | Same contributors/revision. `app/backend/approaches/approach.py`. [Source](https://github.com/Azure-Samples/azure-search-openai-demo/blob/3f4a21f03ae3d565aca37cc300e3d38b0c7b582a/app/backend/approaches/approach.py). Primary implementation. | Lines 287–326 pass `access_token` as `query_source_authorization` in both inspected search branches. High for code path. | The parameter can be absent; these functions alone do not prove identity/configuration correctness or all retrieval coverage. Recheck callers in implementation work. |
| K09-3 | Same contributors/revision. *RAG chat: Setting up optional login and document level access control*, `docs/login_and_acl.md`. [Pinned guide](https://github.com/Azure-Samples/azure-search-openai-demo/blob/3f4a21f03ae3d565aca37cc300e3d38b0c7b582a/docs/login_and_acl.md). Primary project documentation. | Separate authentication, enforcement and global/unauthenticated access configuration. High for documented options. | Not a production certification or safe-default audit. Recheck exact deployed configuration. |
| K09-4 | Microsoft. *Security filters for trimming results in Azure AI Search*. Last updated **2026-08-24**. [Official documentation](https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search). Primary living vendor documentation. | Filter principal strings do not authenticate themselves; permissions-field visibility is not a replacement for every-query enforcement. High for stated mechanism. | Application-built pattern differs from K09-5. No performance claims reused. Recheck on filter/authentication changes. |
| K09-5 | Microsoft. *Query-time ACL and RBAC enforcement in Azure AI Search (preview)*. Last updated **2026-09-17**. [Official documentation](https://learn.microsoft.com/en-us/azure/search/search-query-access-control-rbac-enforcement). Primary living vendor documentation. | Preview status; indexed permission metadata, freshness dependencies and fail-without-partial-results behavior described. High for documented conditions. | Vendor statement, no service testing; connector/API-specific details vary. Refresh before publication and before any configuration recipe. |

The sample source was fetched as text through raw GitHub URLs; no third-party application was installed. Documentation is not independent confirmation of a deployed service's behavior. The sample and vendor docs are from the same ecosystem and are not independent replications.

## Original analysis, not reported incidents

| ID | Claim / constructed condition | Confidence and limit | Decision affected / evidence needed |
|---|---|---|---|
| K09-A | A cache keyed only by question could release an earlier authorized answer to a different unauthorized reader | Logical consequence of the stated synthetic design, not an observed sample defect | Prohibit this design for restricted answers; inspect real cache key and serving policy |
| K09-B | Per-user or per-tenant keys alone do not establish current document access | Conditional reasoning; same-user revocation and within-tenant groups are counterexamples | Define retention/reuse policy before cache optimization |
| K09-C | Source revocation cannot recall information already learned | Logical limit; no specific retention/legal policy prescribed | Decide whether old artifacts remain accessible; test the chosen rule |
| K09-D | Start without cross-user answer reuse for restricted material | Engineering judgment for a small fictional support workflow | Revisit after observed cost/latency and authorization-maintenance burden |
| K09-E | Read permission does not authorize an instruction inside a document | Task-authority distinction from the existing editorial model | Review action credentials, task scope and release boundary separately |
| K09-F | Alternate output paths need their own audience checks | Architectural inference; sample's helper is one concrete illustration | Inspect actual citation, download, export, sharing and logging routes |

The article does not assert a particular cache exists in the sample. It does not claim end-to-end route protection, universal immediate revocation, verified cross-tenant exposure, buyer demand, measured savings or compliance. Neither named fictional user represents a real person or customer.

## Follow-up work with real evidence

An authorized synthetic integration can exercise paired users, group changes, warm caches and direct citations. Preserve request identity, policy version, source membership and returned artifact IDs without logging sensitive source text unnecessarily. All observations remain absent today. Technical correctness of a toy fixture would still not establish performance, ease of configuration or demand in production teams.

**Executed 2026-10-23 (I06):** ten of the packet's cases were run at the application layer of this pinned revision (Entra ID, Azure AI Search and Cosmos DB stubbed) and against LangChain's response caches, with no model and no cloud service. See the [I06 investigation record](/research/retrieval-audience-pilot.md).

An especially useful future source-inspection pass would trace every call to `check_path_auth` and each path that constructs `access_token`, including document downloads and conversation storage. That is deliberately outside this article's scoped inspection; do not describe it as completed.