Back to Blog
·VerseBlocks

The agents your DLP policy does not cover

Power PlatformCopilot StudioGovernanceSecurity

Ask a Power Platform admin what their DLP policy covers and most say every agent in the tenant. Microsoft's own documentation supports a narrower claim. Copilot Studio custom agents have been fully governed by Power Platform data policies since early 2025, when Microsoft closed the exemption that used to let some agents skip enforcement. Every agent built in Copilot Studio now answers to whatever connector policy applies to its environment, with no exception left to claim. Agents created inside Microsoft Teams get identical treatment, because Power Platform's data governance policies, DLP and tenant isolation included, apply to Teams environments the same way they apply to any other environment type. Dynamics 365's prebuilt agents for Customer Service, Finance and Operations, and Sales are managed through Copilot Studio too, so they inherit the same governance as anything a maker builds from scratch.

Microsoft 365 Copilot declarative agents get a smaller share of that coverage. Power Platform connector governance through the Power Platform admin center's DLP policies applies to them, but only for the Power Platform connectors they call. Declarative agents can't grant a user any privilege beyond what that user already has in Microsoft 365. Everything else about what they can see comes from Microsoft 365's own protections; a Power Platform data policy has no say in it. Connector policy itself changed shape in June 2026, when Advanced Connector Policies replaced the old Business, Non-Business, and Blocked model with a default-deny allowlist, a change covered in detail in DLP changed in June. The agent types under that policy stay the same either way.

Where Purview and other systems take over

SharePoint agents are governed differently. Microsoft's SharePoint agent guidance is explicit that these agents inherit the Microsoft 365 data access boundaries and permission model, so an agent can't grant a user access to a file that user couldn't already open on their own. That's a real safeguard, but it isn't Power Platform DLP. To stop a SharePoint agent from using a specific file, an admin has to build a Microsoft Purview DLP custom policy using the Content contains condition scoped to sensitivity labels, and make sure the content carries the right label in the first place. Power Platform's data policy tooling has no lever over SharePoint agents at all.

Azure AI Foundry agents get none of that coverage either. Microsoft's Cloud Adoption Framework guidance for AI agent governance states plainly that Power Platform DLP does not directly govern Azure AI Foundry agents. There's no documentation describing Power Platform DLP extending to them, because it doesn't. Governing them means configuring separate Purview DLP policies with custom detectors, or building Microsoft Agent Framework agents with Purview policy middleware configured to intercept prompts and responses and apply organisational DLP rules. Both of those are choices an admin has to make on purpose. Neither happens by default the way Copilot Studio enforcement does.

Then there's Microsoft 365 Copilot and Copilot Chat, governed by Purview DLP for Microsoft 365 Copilot, which reached general availability in June 2026. It's a separate system from Power Platform DLP, and Microsoft's own Purview documentation says so directly: Purview DLP operates on prompts and the content Copilot accesses, while Power Platform DLP governs connector usage. Purview DLP for Copilot can stop Copilot from using external web search when a prompt contains sensitive information types, and it can block Copilot from processing sensitive files or emails carrying sensitivity labels when it generates a response. Two more controls are still in preview: blocking sensitive information types written directly into the prompt, and excluding external email from being referenced or summarised. An admin who assumes Power Platform DLP is quietly watching Copilot Chat prompts is relying on a control that was never built to look at prompts at all.

The gaps that aren't in anyone's documentation

Some of what's missing comes from how creation works. Any user with Edit permissions on a SharePoint site or document library can create a SharePoint agent, according to Microsoft's own Copilot Studio security and governance guidance. Power Platform DLP governs who can build in Copilot Studio and which connectors that build can reach. It has no equivalent over who can create a SharePoint agent, because that decision was never routed through Power Platform to begin with.

Once a SharePoint agent exists, tracking it gets harder. A 2026 review of Copilot Studio's security posture found that SharePoint agents lack native lifecycle management. Nothing in the platform surfaces whether an agent has gone stale or who last touched it, and there's no signal for whether the content grounding its answers is still accurate. Compare that to Copilot Studio agents, where enhanced admin controls reaching general availability on 2 September 2026 let admins centrally require Microsoft Entra ID authentication and allow specific external providers. The same controls can prohibit anonymous access at the environment or environment group level. Copilot Studio has that kind of admin standing between the agent and its users. SharePoint agents don't.

One visibility gap in this category has already closed. Classic chatbots built in the legacy Copilot Studio app inside Microsoft Teams never showed up in the Center of Excellence Starter Kit, the tool most Power Platform teams use to inventory what's actually running. Microsoft retired classic agent creation in Teams on 30 June 2026 and redirected builders to the Copilot Studio web experience, so that particular gap stops growing even though agents built before the cutoff are presumably still out there.

Custom connectors and HTTP connectors aren't covered by Advanced Connector Policies yet either, a point already covered in DLP changed in June. That gap exists in addition to everything above it.

The numbers keep climbing. Gartner's April 2026 guidance on managing agent sprawl projects that the average global Fortune 500 enterprise will have more than 150,000 agents in use by 2028, up from roughly 15 in 2025, and reports that only 13 percent of organisations believe they have the right governance in place for them today. Most of that growth sits outside Copilot Studio, where Power Platform's coverage is strongest. It shows up in SharePoint and Azure AI Foundry, and in tools nobody in IT approved in the first place.

What to configure now

Discovery has to happen before governance does, and Microsoft built a product for exactly that gap. Agent 365 reached general availability on 1 May 2026 and includes shadow AI detection for agents nobody registered. It finds unmanaged agents on Windows devices, plus AWS Bedrock and Google Cloud, reaching well beyond Microsoft's own tools. It costs $15 per user per month as a standalone add-on, or comes bundled into Microsoft 365 E7 at $99 per user per month. The agent registry inside the Microsoft 365 admin center gives a single view of Microsoft-built and partner-built agents, plus custom ones. Registry sync, now generally available, extends that inventory to agents built outside Microsoft's platforms entirely.

For SharePoint agents specifically, the fix is a Purview DLP custom policy scoped to sensitivity labels. The Power Platform admin center has no lever over this at all. Pair it with an audit of SharePoint permissions before agents go live. An agent built on top of an oversharing problem just repeats that problem faster.

For Azure AI Foundry agents, the choice is between Purview DLP with custom detectors and Microsoft Agent Framework's Purview policy middleware. An admin has to pick one and set it up rather than assume Power Platform's data policy is quietly covering it.

For Copilot Studio agents, none of this replaces the basics: classifying connectors and filtering endpoints. The enhanced admin controls that shipped in September 2026 add a third requirement, Microsoft Entra ID authentication. That coverage is real, and it's the strongest layer in the tenant. It just isn't the whole tenant.