A healthcare organization is deploying a Copilot Studio agent that helps clinical staff access medical protocols stored in SharePoint. Due to regulatory requirements, physicians must only receive protocols relevant to their specialty (e.g., cardiologists cannot see oncology-only protocols). All documents are indexed in Azure AI Search. The agent uses Entra ID authentication and can identify the user's specialty from their Entra ID profile. Which RAG pipeline design ensures that protocol retrieval is filtered to the user's specialty at query time, without duplicating index content per specialty?

User-context filtering in RAG pipelines can be implemented in several ways, each with different trade-offs in index architecture, query performance, and security guarantees. The metadata-filter approach is correct because it implements the recommended pattern: a single index with metadata-based filtering at query time. During indexing, each document chunk is enriched with a 'specialty' metadata field (e.g., 'cardiology', 'oncology', 'all') that reflects the document's intended audience. When the agent receives a query, it retrieves the user's specialty from Entra ID, constructs an Azure AI Search filter expression (e.g., specialty eq 'cardiology' or specialty eq 'all'), and includes this filter in the search request. Azure AI Search applies the filter server-side before ranking, so only authorized chunks are returned. This approach maintains a single index (no duplication), enforces filtering at the search layer (not after retrieval), scales well as specialties grow, and avoids sending unauthorized content to the language model at all. The separate-index approach is wrong because it creates a separate Azure AI Search index for each specialty. This is technically correct for isolation but operationally unsustainable: with 30+ medical specialties, maintaining 30+ indexes with separate indexer schedules, content duplication for cross-specialty protocols, and index selection logic is a significant overhead. This approach also fails for protocols that are relevant to multiple specialties (they must be duplicated or maintained separately). The post-retrieval filtering approach is wrong because it implements filtering in the Copilot Studio agent's Power Automate flow by retrieving all matching chunks and then discarding any chunks whose metadata specialty field does not match the user's specialty before passing the context to the language model. This is a security anti-pattern for access control. The problem: chunks for unauthorized specialties are retrieved from the index and passed to the Power Automate flow before being filtered. The language model never sees them (the filtering discards them), but the retrieval cost is wasted, and the approach introduces a risk window — if the filtering logic has a bug, unauthorized content reaches the LLM. Filtering should happen at the earliest possible point in the pipeline (at the search layer, not after retrieval). The SharePoint sensitivity labels and permission-trimming approach is wrong because it does not implement specialty filtering from the user's Entra ID specialty attribute at query time. Azure AI Search's SharePoint permission trimming filters results according to SharePoint permissions, not according to a specialty metadata value. Sensitivity labels alone do not automatically create specialty-based access unless those labels are mapped to SharePoint permissions or access-control policies for every document and specialty. That means you would have to manage SharePoint permissions or label-based access for each specialty-specific document, which is an administrative burden and still does not give the agent a simple query-time specialty filter. Also, permission trimming is based on the authenticated user's SharePoint permissions, which requires the search query to be executed as the user's identity (not a service principal), adding complexity to the agent's authentication flow. Exam tip: For RAG filtering questions, know these patterns: index-time metadata plus query-time filter is recommended; multiple indexes per persona are operationally complex; post-retrieval filtering is a security anti-pattern; permission trimming is valid for SharePoint-native ACL scenarios but complex to manage. The $filter parameter in Azure AI Search queries accepts OData filter expressions and is applied before vector similarity ranking.