How to connect an existing Azure AI Search index to a Microsoft 365 Copilot agent when the connector is blocked by policy?

Based on the investigation, Azure AI Search is not currently available as a native Knowledge source for Microsoft 365 Copilot agents in the affected environment. Although the Azure AI Search connector is visible under Tools → Connectors, it is currently marked as "Blocked by policy", indicating that a Power Platform DLP policy is preventing its use.

For an existing Azure AI Search index, the recommended approach is typically to expose the indexed content through a supported integration layer, such as:

• A Custom Connector that queries the Azure AI Search index via API.
• An MCP Server that retrieves relevant content from the index and returns grounded results to the Copilot agent.
• Where applicable, storing content in Microsoft 365 repositories (e.g., SharePoint or OneDrive) and leveraging native Microsoft 365 knowledge sources, which provide built-in security trimming and citations.

To enable direct use of the Azure AI Search connector, the tenant's Power Platform administrator will need to review the applicable DLP policies and determine whether the connector can be moved from the blocked category to an allowed business connector category.

From a governance and security perspective, the recommended design is to:

• Use the Azure AI Search index as the retrieval source.
• Restrict agent responses to retrieved/indexed content only.
• Return document metadata to support source citations and attribution.
• Enforce user-level access controls through Microsoft Entra ID authentication and security trimming so that users only receive content they are authorized to access.

In summary, the existing Azure AI Search index can be surfaced through a Microsoft 365 Copilot agent, but this is generally achieved through a supported retrieval layer (such as a Custom Connector or MCP Server). The current blocker appears to be the environment's DLP policy, which would need to be reviewed by the administrator before the Azure AI Search connector can be used directly.

Two separate things are going on here: the DLP block, and the choice of integration.

1. "Blocked by policy" is a Power Platform data policy (DLP), not a Copilot Studio limit. An admin needs to open the Power Platform admin center > Policies > Data policies, find the policy that applies to your environment, and move the Azure AI Search connector into the same group (usually "Business") as the other connectors your agent uses. An environment-scoped policy is the cleanest way to do it without opening the connector tenant-wide. Once it is allowed, Azure AI Search can be added as a knowledge source, and the agent cites the passages it used.

2. MCP or a custom connector also works, and it is the better option if you need control over what reaches the model. I maintain an open-source sample that does exactly this: an MCP server that queries an existing Azure AI Search index, scores each candidate passage, and returns either cited evidence, a premise conflict, or "nothing reliable found" so the agent abstains instead of answering from memory: https://github.com/Zakariakhchiche/copilot-studio-jev (it is proposed as a sample in microsoft/CopilotStudioSamples, PR #539). Note that custom connectors and MCP tools are also subject to the same DLP policies.

3. Restricting answers to the index. In the agent's settings, turn off the option that lets the AI use its own general knowledge, and say in the instructions that the agent must answer only from the knowledge source and say so when nothing relevant is found. Test with questions whose answer is not in the index: that is where agents usually fail.

4. User-level access control. Azure AI Search does not know who the Copilot user is unless you pass that information. The usual pattern is security trimming: store allowed users or groups in a filterable field of each document and filter on the caller's identity at query time. With a custom connector or MCP server, that means authenticating the user (OAuth on the connector) and applying the filter server-side, never in the prompt.

(Disclosure: I'm the author of the sample above.)