We turned on a Purview DLP policy for the ‘Microsoft 365 Copilot and Copilot Chat’ location so Highly Confidential files stay out of summaries. Security assumes that also fences Copilot Studio agents. Does it — or are we leaving a gap?

Copilot DLP location vs Studio agents, SharePoint knowledge label restriction, Power Platform DLP — Steady Security without false comfort.

Does Purview Copilot DLP cover Copilot Studio agents?

That’s a fair assumption — and a dangerous one if it’s wrong. One Copilot-shaped DLP location does not automatically mean every agent surface is fenced the same way.

Here’s what’s going on. The Purview location Microsoft 365 Copilot and Copilot Chat is built for Copilot and Copilot Chat interactions: sensitivity labels can prevent Copilot from processing labelled files/emails in summaries (citations may still appear); SITs can block prompt processing or web search; external-email grounding blocks are rolling out. For agents built in Copilot Studio, Learn’s Purview guidance is narrower on DLP: when the knowledge source is SharePoint, a DLP policy scoped to that Microsoft 365 Copilot location can restrict Studio agents published to Teams, SharePoint, and Microsoft 365 Copilot from processing content with a specified sensitivity label. That is not “every Studio channel, every knowledge source, every connector.” Studio still leans on Power Platform data policies for Knowledge connectors, channels, and maker uploads; Purview separately covers audit, DSPM for AI, sensitivity labels on SharePoint/Dataverse knowledge, retention under Microsoft Copilot Experiences, and eDiscovery patterns for Studio interactions. Restricting Copilot from processing labelled files/emails via the Copilot DLP location remains an E5 / Purview Suite class capability for that action — check the service description for your SKU.

This is Steady Security without false comfort: labels + Copilot DLP for Chat are necessary; they are not a complete Studio fence. Schofield’s Third Law (historically attributed) still applies — easier grounding paths need matching controls, not a single tick-box.

Options that actually work:

Layer the controls. Copilot-location DLP for labelled SharePoint knowledge used by Studio agents in Teams/SharePoint/M365 Copilot plus Power Platform DLP for Knowledge/connectors plus permission hygiene. Best Steady default.
Studio-first fence in Power Platform. Treat environment DLP and connector groups as the primary maker control; use Purview Copilot DLP as the Chat/summary backstop. Good when Studio is the riskier surface.
Assume “we set Copilot DLP” covers all Studio agents and channels. Incomplete for non-SharePoint knowledge, other hosts, and connector actions. Don’t brief the board that way.
Labels only, no Copilot DLP, no Platform DLP. Classification without enforcement. Incomplete for your stated goal.

12 Panes action / comms: Tell Security: Copilot DLP helps Studio when knowledge is SharePoint and the agent runs in supported hosts — verify the rest in Power Platform. Tell makers: a red Knowledge banner is Platform DLP; a missing summary may be Purview — different tickets, different owners. Leadership: one policy location is not one AI control plane.

Benefits / risks: Honest layering closes the “we thought DLP covered agents” gap; over-promising a single location creates audit findings later; SKU and host support move — re-read Learn before renewal theatre; Endpoint DLP for third-party browser AI is a separate story again.

I’d suggest this week: map three rows for your top Studio agents — knowledge source, publish host, which DLP plane owns the fence — and fix any row that only says “Copilot DLP.” You’ll have Steady Security when Chat and Studio both have a named control, not a hopeful assumption.

DIGITAL SKILL WORKS LTD / 12 PANES · You ask, we answer