I see it all the time now. Copilot Studio agents show up across Microsoft 365 tenants, and some of them quietly pull from an odd mix of internal and external data sources. More than once I've walked into environments where business users could build agents that read SharePoint and public websites and even chatted with people outside the organization. The admin team usually found out by accident. Copilot Studio DLP used to be a niche topic. Today you can't skip it if you want real control over data flows and agent capabilities on the Power Platform.

Power Platform DLP policies matter more now than they ever did

The classic Data Loss Prevention (DLP) policies live in the Power Platform admin center under Security → Data and privacy → Data policy. Connectors are sorted into three groups there: Business, Non-business and Blocked. If you've worked with Power Apps and Flows, none of this is new. With Copilot Studio, though, it carries much more weight. Agents use connectors for knowledge sources such as SharePoint, Outlook, public websites or custom APIs. A well-designed DLP policy scoped to each environment shuts down risky scenarios right away, for example mixing sensitive company data with internet sources, or letting chat agents talk to anonymous users without Entra ID authentication. Microsoft's own documentation on Copilot Studio DLP is a sensible starting point, mainly because it shows which connectors matter most for Copilot Studio agents right now.

Practical tip: Test every new or changed DLP policy in a separate non-production environment before you roll it out further. Plenty of apps and agents break with obscure error messages once a connector is no longer available. A phased rollout and clear communication about the change save you a lot of trouble.

There's one trap people fall into regularly. Power Platform DLP policies are always scoped to an environment, but most organizations still drop their first agent projects into the Default environment, which is rarely locked down. If you want to keep Copilot Studio under control, your environment strategy decides whether that works.

A locked-down Default environment and dedicated agent environments come first

Keeping production apps out of the Power Platform Default environment has long been good practice. With Copilot Studio I don't treat it as optional anymore. The Default environment simply has too much going on to police properly. I create dedicated environments for Copilot Studio projects instead, and each gets its own DLP policy that fits the agent's business context. For one department I might allow only SharePoint and Microsoft 365 connectors (Business group) and block website and custom API connectors. Default Environment Routing sends new app and agent projects away from the Default environment into a managed space that follows your policies.

Separating things this way also makes it far easier to apply different controls for development, test and production. Managed Environments add more on top, such as app limits, environment insights and approval workflows. If you want Copilot Studio governance that holds up over time, I wouldn't do without them.

Copilot Studio brings its own connectors and authentication settings

Copilot Studio changes the DLP picture because it adds connectors and agent options that core Power Apps doesn't have. Knowledge sources are the part I watch most closely. An agent can connect to internal SharePoint and OneDrive, but just as easily to public websites, databases or open APIs, as long as DLP doesn't block the connector. In the Copilot Studio admin portal (or per environment in the Power Platform admin center) I can review connector groups and move connectors around to tune the policy. Pay close attention to the authentication settings. If "Chat without Microsoft Entra ID authentication" is allowed, anyone can reach the agent anonymously, and that's a serious risk in production. Outside of controlled pilots, I'd keep it switched off in nearly every case.

The diagram below shows how DLP policies, environments and the main agent controls fit together for Copilot Studio agents:

graph TD
    Admin["DLP policy admin"] --> Policy["DLP policy"]
    Policy --> Env["Environment"]
    Env --> Agent["Copilot Studio agent"]
    Agent --> Connector["Connector (e.g. SharePoint, Website)"]
    Connector --> Source["Data source"]
    Policy --> Blocked["Blocked connectors"]
    Agent --> Auth["Authentication setting"]

Figure: The DLP policy determines which connectors and data sources Copilot Studio agents can use and which authentication options are permitted.

I always review the same five points first

Whenever I look at a Power Platform environment with Copilot Studio agents, I start with these questions:

  • Is there a DLP policy in this environment that's built for Copilot Studio agents?
  • Are all production agents kept out of the Default environment?
  • Are risky connectors (websites, open APIs) explicitly blocked?
  • Is authentication set up so agents can't be accessed anonymously?
  • Is someone regularly monitoring changes to policies, agents and environments?

In my experience, the first two are where most organizations slip. Cut corners on environment design and connector grouping, and sooner or later you'll have agents with access to data or users you never meant them to reach. Only consistent governance and regular reviews keep that from happening.

DLP is a foundation for agent governance and not a checkbox

I don't see Copilot Studio DLP as a compliance exercise. It's what makes agent governance workable in the first place. Solid DLP policies, a well-thought-out environment model and close control over Copilot Studio's own connectors and authentication settings give you the best protection against data leaks and oversharing. Managed Environments and environment routing help bring some order to what is often a mess. If you want to go further, read my posts on Copilot Studio governance and on agent management in Copilot Studio.