Retrieval Boundary

What it is

A retrieval boundary is a rule that controls which sources an AI system is allowed to draw on when answering for a particular audience or workflow. Support answers might be restricted to help documentation, while sales answers are restricted to approved market-facing claims. The boundary is a policy about evidence, applied before generation rather than corrected afterwards.

Why it matters

Without a boundary, a system will answer a customer-facing question using an internal roadmap note, or answer a pricing question from a blog post written for a different market. Both produce fluent, plausible answers assembled from the wrong evidence. A boundary declared as a fixed filter attacks wrong-source error as a class, where one the model infers per query only makes it less likely case by case. Neither removes the category outright: the filter is only as good as the metadata it reads, and it can fail in both directions. It is also worth being clear about what access-control machinery does and does not do. Permission filtering scopes by identity, not by editorial purpose. It can keep a reader away from a document they are not cleared for, but it does not know that a roadmap note is the wrong evidence for a customer-facing answer.

Azure AI Search ships two shapes of this, and the difference is the lag. On the indexed path, built-in support for identity-based access at the document level is in preview, enforced at query time against permission data already written to the index. It has not left preview; the overview now places these features in the 2026-08-01-preview REST API. Microsoft's document-level access control overview states that a permission change made at the source is "only reflected in search results after that metadata is synchronized to the index" — by a subsequent indexer run, a push-API update, or a Purview-driven refresh — so a document whose access was tightened stays reachable until that synchronization lands. Its SharePoint permission-ingestion guidance says what follows: change permissions without triggering an update mechanism and "the index serves stale ACL data for previously ingested files". That lag is now uneven rather than uniform. Since the 2026-05-01-preview REST API, "ACL changes for items with unique permissions are detected and refreshed on each successful indexer run", picked up from SharePoint change tokens the way content changes are; the overview is explicit that "changes inherited from parent scopes (site, library, list, or folder) require an explicit refresh". The remote SharePoint knowledge source, also in preview, moves the lag rather than removing it. Its own guidance states that "Unlike indexed knowledge sources, remote SharePoint knowledge sources query live data directly at retrieval time" and that "No search index or connection string is needed". The permission lag does go with it: there is no copy of the ACLs to refresh, and the same page says "no ingestion-time permissions configuration is needed" on that path. Microsoft now points at that path for full-fidelity permissions, saying that with it "Governance remains fully in SharePoint, and query results automatically respect all applicable permissions and labels". What takes its place is a dependency on an index someone else runs. Remote SharePoint is served by the Microsoft 365 Copilot Retrieval API, which Microsoft describes as "returning relevant text chunks from the hybrid index that powers Microsoft 365 Copilot" and which "is subject to all limitations of the Microsoft 365 Copilot semantic index". Live at retrieval time is a claim about the Azure side of the boundary, not about the whole path. Chunking is another documented failure on the indexed path, and it runs in both directions depending on which metadata is missing. Where a skillset chunks documents into a single index the permission fields move from indexer field mappings to index projections, and the same SharePoint guidance warns that "In all chunked scenarios, every chunk must carry the ACL fields." It now states the consequence directly: "Permission filters apply per document, so a chunk missing ACL fields" cannot be returned to the right caller, withholding evidence from a reader who should have it. For Purview sensitivity labels the failure runs the other way: the overview states that "the skillset must also project the sensitivity label to each chunk row", and without that projection chunk-level references are not filtered. A third class fails earlier than either: the same SharePoint guidance lists indexer features — the Custom Web API skill, knowledge store, enrichment cache and debug sessions — where "If you use any of these features in a skillset or indexer, document-level permissions" are not included in the indexed content at all, so there is no boundary to enforce at query time. Knowledge Company position is that the boundary belongs with the claim record rather than the retrieval configuration, so it survives the claim being reused elsewhere.