Data Loss Prevention for Copilot Studio Agents

Data Loss Prevention (DLP) in the Power Platform allows us to manage which connectors (aka APIs) we can or can’t use in apps, flows and agents. Your data is King and Queen of the platform, so anything that could leak data – intentionally or otherwise – must be taken seriously.

With increased creation of Copilot Studio agents, administrators need to understand what existing DLP controls they can utilise. In this article, I’ll highlight some Copilot Studio specific connectors we can manage in standard Data Policies.

Table of Contents

Accessing Power Platform DLP

To access, you’ll need administrative rights to the Power Platform. From there, you can navigate to the Power Platform Admin Centre, Security > Data and Privacy > Data Policy:

If you’re just starting out with Power Platform DLP, I recommend you read through my original series on the topic. It will give you a good grounding into creating policies, of which this article then follows.

As is standard behaviour, all connectors for Copilot Studio are enabled by default. Admins must block any they deem inappropriate for use.

Knowledge Sources

There are three key connectors relating to adding knowledge for Copilot Studio agents:

Knowledge Source with documents allows a maker to add static data as knowledge to their agent.

The downside of this is, what if that static data needs updating? You’ll have to edit the agent and update manually. If your agent is in production, in a Managed Solution, that might be tricky!

I normally suggest blocking this one and instead adding the file(s) to SharePoint or OneDrive. This just provides less hassle long term and ensures any edits are synced / recognised / picked up by your agent without needing to edit.

Therefore, Knowledge source with SharePoint and OneDrive is a must to allow in Power Platform DLP. Most basic retrieval agents can easily fit on top of any existing SharePoint or ODfB documents, libraries and lists. A far more scalable option for information retrieval than static files.

Allowing or blocking the Knowledge source with public websites might be more situational. Let the specific use cases drive whether to allow this option. For example, building an agent for external visitors to query your company website would be a good use case; building an agent to scan for cheapest Lego prices – maybe less so (well, not in your company tenant anyway!). Also keep in mind limitations, such as the limit of two levels deep for URLs.

For added granularity here, I recommend configuring Connector Endpoints. This allows you to specify which website(s) you want your agents to use as knowledge. You can then opt to deny any other URL not listed:

Publishing to Channels

You must publish an agent so you can share with others to use. There are several paths available, some good, some not so good.

Publishing your agents to Facebook or WhatsApp are viable avenues given the correct use case. However, as these are likely to be used by anyone who publicly has access, I’d expect some epic red teaming to have taken place first! Until then, it’s best to block these ASAP.

Direct Line allows a maker to publish their agent to a demo or custom website. Essentially then, you’re generating a URL for others to access and test. What’s stopping someone sharing the URL externally? Again, not something you’d want to expose without proper red teaming and Responsible AI in mind. Definitely a candidate to block in Power Platform DLP.

SharePoint and Microsoft Teams channels are likely to be the go-to destination for your agents. These integrate perfectly for internal users and relevant credit packs or M365 Copilot licensing. No problems to allow these connectors in your Power Platform data policies.

Copilot Studio shows multiple error messages if you’re unable to publish to a channel. You can download errors into xlsx format if you need to analyse further what the issue(s) might be.

Authentication

There’s one key option here that we can manage in Power Platform DLP:

Your most likely scenario for agents is for internal use only, so will naturally be using their Entra ID to authenticate.

This option might be more appropriate for any public facing agent, for example one on your company website. These will be used by people outside of your company and won’t have an Entra ID. This use case is fine, but would recommend segregating this activity in your Power Platform estate with its own environment and DLP policy to allow chat without Entra ID.

Otherwise, get this option blocked in your policies.

App Insights / Omni / Skills

These are the options we can allow or block in Power Platform DLP:

In Copilot Studio, you’re able to connect your agents to Application Insights. You can capture out-of-the-box and custom telemetry. It’s a powerful option, but likely only needed for your enterprise-grade, heavy usage agents that need extensive monitoring. It’s worth blocking this option in Power Platform DLP, especially as someone could create an App Insights instance in their own tenant to track data from a company agent.

Omnichannel is another good candidate to block. This is only a good option to allow if your company has Omnichannel for Customer Service (part of Dynamics 365). If not, you can block this connector in your policies.

Skills allow custom coded extensions to your agents, using Microsoft 365 Agents SDK or other pro-code tools. Again, not an option for your everyday agent maker in your organisation. Block this option, if needed it’s another candidate to ringfence with its own environment and DLP policy.

The Copilot Studio one

Yes, there’s a Copilot Studio connector you can allow or block in a DLP policy.

Recently, I discovered that this controls whether your can trigger an agent autonomously. With this connector blocked in a Power Platform DLP policy, you’ll notice the option to add triggers to agents is disabled:

It’s up to you if you want to enable this company-wide, or only for specific agents that need autonomous capabilities.

AI Actions

Ok, so this isn’t a connector consumed directly in Copilot Studio agents. However, it does impact your Power Platform DLP posture.

Have you played around with any of the Frontier tools yet? When enabled, the Workflows agent allows anyone to build simple automations using natural language:

You may encounter a DLP related error when trying to save anything created with Workflows (Frontier):

That’s because the AI Actions connector needs unblocking in whatever DLP policy covers your Default environment. It was difficult at first to identify, as the internal name of shared_aisteps isn’t the same as the display name:

Yes, workflows generated by Workflows (Frontier) are stored in your default environment. So keep that in mind when designing or editing your DLP policy for Default, as typically this will be the most restrictive.

Summary

For a quick reference guide, here’s my recommendations for all the above connectors and their DLP alignment. This is a good starting point/baseline that you can build from:

Connector	DLP Alignment
AI Actions	Allow
Application Insights	Block
Chat without Microsoft Entra ID authentication	Block
Direct Line channels in Copilot Studio	Block
Facebook channel in Copilot Studio	Block
Knowledge source with SharePoint and OneDrive in Copilot Studio	Allow
Knowledge Source with documents in Copilot Studio	Block
Knowledge source with public websites and data in Copilot Studio	Block, or allow with filtering
Microsoft Copilot Studio	Allow for autonomous agents
Microsoft Teams + M365 Channel in Copilot Studio	Allow
Omnichannel in Copilot Studio	Block
SharePoint channel in Copilot Studio	Allow
Skills in Copilot Studio	Block
WhatsApp channel in Copilot Studio	Block

Currently, you can manage ALL these connectors in standard Power Platform DLP policies. Only the AI Actions and Microsoft Copilot Studio connectors are currently available in Advanced Connector Policies so worth keeping that in mind.

I’ll be covering Advanced Connector Policies in my next post, so stay tuned for that.

Thanks for reading. If you liked this article and want to receive more helpful tips about Power Platform / Agent governance, don’t forget to subscribe or follow me on socials 😊