Azure AI Search can return relevant information that the current user is not entitled to read. This guide examines permission-aware retrieval for Microsoft Foundry agents: indexing source ACLs, passing user identity at query time, distinguishing preview API behavior, and testing missing or revoked access before confidential content reaches a model.
A search result is not automatically an authorized source
Retrieval-augmented generation can improve the factual grounding of a Microsoft Foundry agent, but it can also expose information that the current user was never entitled to view. The risk appears before the model drafts its answer: a search system might return a relevant document from another department, an obsolete policy or a private customer record. The model can faithfully cite that document and still make the application unsafe. Correct retrieval therefore requires an identity-and-permission decision, not just a relevance score.
An ordinary Azure AI Search RAG design starts with indexing, text chunking, hybrid keyword/vector retrieval and citations. Hybrid retrieval can rank a chunk accurately while still violating a caller’s access boundary if authorization is not enforced before generation. The more specialized engineering problem appears when a knowledge base holds records with different permissions and an agent serves many authenticated users. A technically correct search query without user-bound authorization can then become a security incident.
Microsoft’s Azure AI Search documentation describes document-level permission filtering and query-time ACL/RBAC enforcement in version-specific preview features. For knowledge-base retrieve calls, Microsoft warns that omitting end-user identity in supported preview agentic retrieval can return unfiltered results. Ordinary index document search with current query-time ACL enforcement, by contrast, returns only public documents when a user token is omitted. These are different API paths, and the application must not assume that one has the other’s fail-closed behavior. That is an especially important operational hazard: the absence of an authorization header must never be interpreted by the application as implicit permission to retrieve everything.
Define the data boundary before building an index
Imagine an internal support assistant with three kinds of documents: public troubleshooting notes, private customer tickets and security incident reports. Two employees can ask similar questions about login failures, but only one belongs to the group allowed to read a particular incident report. Their queries may produce overlapping semantic matches. Authorization must constrain the source collection before the agent sees retrieved text, not be left to a post-generation instruction such as "do not mention confidential material."
Start by recording the document owner, source location, tenant, access classification, applicable user or group identities, permission version and effective time. A multi-tenant application should also bind each request to the authenticated actor and tenant outside model-generated content. Do not let the model choose the tenant simply by including a string in a tool argument. Authentication of the caller and resource-level authorization remain distinct from the choice of embedding model.
An application can implement its own filters, use native query-time permission enforcement where the supported feature/version permits it, or combine additional service-level rules with native filtering. These paths have different operational obligations. A manually maintained security-filter expression is not automatically equivalent to Microsoft Search’s preview permission-filter fields and token-based enforcement. State which mechanism was actually configured and tested rather than treating them as interchangeable.
Carry permission metadata through ingestion
Document access controls can be lost when a source is converted into chunks. Suppose the source file allows only group G-21, but the derived vector index contains twenty independent text chunks without any ACL metadata. A semantic search may then retrieve one of those chunks for an unauthorized caller even if the original file repository would have denied access. The indexing pipeline must preserve the permission relationship between source and searchable derivative.
Microsoft’s push-index API documentation describes enabling permission filters in an index schema and assigning specialized permission fields for user IDs, group IDs and certain RBAC scopes. These native permission-filtering capabilities are preview: Microsoft states preview functionality is not covered by a service-level agreement and is not recommended for production workloads. Check the actual region, API version and supported authorization method, and use a production-suitable approach rather than treating a preview configuration as generally available. It is not enough to copy field names into an arbitrary existing index; the indexing and query configuration must actually support the selected mechanism, and the source identity mapping must be accurate.
For enterprise repositories, resolve source ACLs to the identity type the search service supports and store that association with the searchable record. A document can be chunked into multiple records; each relevant chunk must remain restricted to an appropriately authorized set. If a document moves to a different team or becomes restricted, update permissions for its derivative records as part of the source-index synchronization. Deleting a document should also remove or invalidate its chunks. Keeping stale copies in a retrieval cache defeats even a correct current source ACL.
Never hardcode real access tokens, confidential source examples or personal customer IDs in a public tutorial. Use synthetic fixture identities and documents to prove the behavior in isolation.
Enforce the user’s identity at query time
In documented agentic retrieval configurations, the application passes the end-user identity in the authorization header expected by the knowledge source. Microsoft identifies the x-ms-query-source-authorization header for most sources, while Work IQ uses a different source-authorization header. The preview API and source type matter. The retrieval layer can then use identity and indexed permission metadata to exclude records the caller cannot read.
The request must come from the trusted host, not from an agent asking the model to invent a bearer token. The host should obtain the appropriate credential through its authorized sign-in and delegation process, validate its audience and scope, and apply any additional tenant/resource checks before calling Search. A valid identity for the host’s administrative operations is not interchangeable with the end user’s authorization to read a private knowledge source.
The absence of identity requires deliberate fail-closed behavior. If the product’s API configuration is one of the preview agentic retrieval paths where missing user identity yields unfiltered results, do not allow the request to proceed and assume the search service will reject it. Reject the operation at the host boundary, request valid authentication or route only to a separate explicitly public source. Logging "no user token" and then showing the user the unfiltered retrieval output is too late.
Native preview permission enforcement, earlier preview-version behavior and conventional manual security filtering must be assessed separately. Microsoft’s query-time ACL guidance says older 2025 preview versions could return all documents without a user token; later updates made ordinary index search respect protected ACLs without the token, but this is not a guarantee for every knowledge-base retrieve operation. Where a deployed API does not support the desired native feature or source type, do not claim it does. Use a supported explicit security filter with a verified identity mapping and negative tests, or defer the product feature until a secure implementation path is available.
Permission changes and caches are part of authorization
A permission-aware retrieval pipeline needs to know how quickly membership and source ACL changes become effective. An employee can lose access to a group while an older search index or cached result still contains a previous copy of the policy. Microsoft’s documentation notes that permissions set or changed outside certain preview versions may take time to appear in agentic retrieval results. Measure that propagation window for the actual source, provider and region; do not promise immediate revocation without test evidence.
Caches must respect both user identity and permission context. A cache key based only on question text risks returning an answer assembled from a prior user’s authorized documents. At minimum, an access-sensitive cache design should bind results to the correct tenant, caller or permission scope, source revision and freshness boundary. It must also ensure a privilege downgrade invalidates previously cached private content. The model’s conversation history is another possible cache of confidential information; a resumed agent must not replay another person’s restricted citation as if it were newly authorized.
Logging has similar boundaries. Traces should support audit of identity class, resource and filter decisions without copying full restricted documents into broadly accessible observability systems. A trace proving that a permission filter executed is useful; a trace containing the private content that filter excluded is an avoidable disclosure risk.
A fictional test corpus with meaningful negative cases
Create a synthetic knowledge base of six documents. D-01 and D-02 are public troubleshooting instructions. D-03 and D-04 belong to team Red. D-05 belongs to team Blue. D-06 is a confidential incident report accessible only to a specific review role. Include overlapping terminology such as "login outage" in all six so search relevance alone cannot separate the groups. Then define two fictitious users and a reviewer identity, with independent expected-visibility sets.
An allowed case asks user Red to summarize a relevant Red document; the citation and source ID should match a record Red may actually read. A denied case asks the same user a question that would rank D-05 most highly. The query must not return or quote D-05. A third case omits the user identity entirely; the host should block the protected retrieval request before sending it. A fourth case tries to persuade the model to set the target tenant itself; the host must ignore that argument and use the authenticated tenant.
Use a split-principal regression: run an identical query under team Red, team Blue and a session with no authenticated identity. Keep the relevance inputs constant but require different eligible source-ID sets at the retrieval boundary before generation. Then revoke Red’s access to a document, invalidate the applicable caches and repeat. This reveals whether a prompt or stored chat has been mistaken for permission. When examining AI-103 practice questions about secure RAG, reject explanations that add a “do not disclose” prompt after restricted records have already entered model context; authorization must be enforced before exposure.
Next simulate revocation: remove Red’s access to D-03 while a previous conversation still references it. The system should not use the old passage as new supporting evidence without checking current authorization. Test document deletion, index refresh failure, stale ACL material, empty filtered results and a missing source-authorization header. Check both the retrieval response and the agent’s eventual message; a polite refusal after an unauthorized document was already delivered to the model is not a full prevention success.
All tests should be executed in a controlled test environment with synthetic records. These scenarios are editorial proposals until the indexing and identity flow actually run. A reported 100 percent pass rate without a real service, model and current API version is not a valid measurement.
Fail safely when retrieval yields no authorized evidence
After access filtering, the correct result can be an empty source set. The agent should say that it cannot find evidence available to the current user, not try a broader index or privileged credential merely to obtain a confident answer. A legitimate user may be invited to request access through the organization’s normal channel, but the assistant must not bypass that process. A missing citation is a reason for uncertainty, not a reason to manufacture a policy answer from latent model knowledge.
A safe response contract can include authorized source IDs, source versions and retrieval status, while hiding the existence and contents of records the caller cannot access. Some applications may intentionally reveal that a general document category exists; that should be a business decision enforced by the host, not an accidental leak from retrieval error messages. The model should never receive private snippets solely to decide whether it is allowed to use them.
Release conditions for a permission-aware Foundry agent
Before deployment, verify the actual Azure AI Search API version, native permission-enforcement availability, index schema, source ACL mapping, identity delegation, cache isolation, index revocation behavior and end-to-end citations. The release gate should include negative tests for missing identity, wrong tenant, wrong group, permission revocation and stale or deleted sources. A high retrieval relevance score is not sufficient to waive any of these failures.
Preserve a test manifest containing the synthetic principal, source set, permission version, API version, retrieval request identity mode, query outcome and observed agent answer. The essential question is whether the application can prove that a user never received content they were not entitled to read, even when that document was the strongest semantic match. A convincing generated answer is not proof of authorized retrieval; current access-control behavior must be tested before protected passages reach the model, including after identity or permissions change. The synthetic cases described here are designs for tests, not evidence of a live Azure deployment.