If you run governance for Power Platform, there is one control that sits underneath almost everything else you do: the Data Loss Prevention (DLP) policy. It is the guardrail that decides where your organization’s data can and cannot flow when people build apps, flows, and agents. Get it right and your makers move fast inside a safe lane. Get it wrong and you are either leaking data or fielding angry tickets about broken flows.
This post explains what DLP policies are, why they are so important, how they actually work, the best practices that keep them effective, and the major shift now underway with Advanced Connector Policies, which went generally available in June 2026.
What a DLP policy actually is
Power Apps, Power Automate, and Copilot Studio all reach data through connectors strongly typed wrappers around APIs that let makers drag a data source into an app, flow, or agent. A connector might be Microsoft Dataverse, SharePoint, Office 365 Outlook, or it might be personal Gmail, X, or an arbitrary HTTP endpoint.
A DLP policy is a governance control that classifies those connectors into groups and enforces rules about which connectors are allowed to be used together in the same resource. In other words, DLP is less about blocking individual connectors and more about preventing dangerous combinations the moment where trusted business data and an uncontrolled external service meet inside one app or flow.
Why DLP policies matter
The reason DLP is consistently called the single most important governance control in Power Platform is simple: every licensed Microsoft 365 user can now build apps, automations, and AI agents that touch enterprise data. Without guardrails, that reach is also your exposure.
Here is the canonical leak scenario. A well-meaning employee builds a flow in the default environment that reads files from a corporate SharePoint site and pushes them out through a personal Gmail connector. No malice, no hacking just an app wiring together two connectors that should never have met. A single DLP policy that places SharePoint in one group and Gmail in another prevents that flow from ever being built.
The benefits are concrete:
– It stops accidental exfiltration. Most data leakage in low-code is unintentional. DLP blocks the risky combinations before they ship.
– It tames shadow IT. The default environment is open to everyone. DLP turns it from a playground into a perimeter.
– It is preventative, not reactive. Rather than auditing damage after the fact, DLP enforces the boundary at design and run time.
– It scales your security posture. The same classification logic applies across Power Apps, Power Automate, and Copilot Studio, so you are not reinventing controls per product.
## How DLP policies work
Every connector is sorted into one of three groups, and the core enforcement rule follows from that classification.
– Business: trusted, sanctioned data sources such as Dataverse, SharePoint, and Office 365 Outlook.
– **Non-business: connectors that are allowed to exist but must be kept away from business data, such as personal email or social platforms.
– Blocked : connectors that cannot be used at all in scope of the policy.
The golden rule: a connector in one group can only be combined with connectors in the **same** group within a single app or flow. Business plus business is fine. Non-business plus non-business is fine. Mixing a business connector with a non-business one in the same resource is blocked. That single rule prevents the majority of low-code data leakage scenarios.
Tenant level versus environment level
DLP policies apply at two scopes, and the relationship between them matters:
– Tenant-level policies are managed by admins and apply broadly across the tenant. Use these as your baseline.
– Environment-level policies apply to one or more specific environments and can be tighter or looser to fit a particular business unit, project, or risk profile.
A widely recommended pattern is to set a permissive tenant-wide baseline and then layer more restrictive environment policies where you need them, keeping the tenant policy less restrictive than the environment ones to avoid confusing conflicts.
Beyond standard connectors
DLP has grown well past simple connector buckets. You can now classify custom connectors by name at the environment level, or by Host URL pattern (with wildcard support) at the tenant level, assigning those URL patterns to Business, Non-business, or Blocked. Power Automate also lets you classify desktop flow modules and individual actions**, and DLP extends into Copilot Studio, helping keep agent prompts and outputs within compliance as generative AI interacts with business data.
DLP best practices
A DLP policy is only as good as the strategy around it. These habits keep policies effective without turning governance into friction.
1. **Set a tenant-wide baseline first** so no environment is left unprotected by default.
2. **Lock down the Default environment.** It is shared by everyone, so block non-Microsoft connectors there and route makers into their own developer environments.
3. **Layer environment-level policies** on top of the baseline for tighter or looser control where it is warranted.
4. **Classify before makers build.** Retrofitting policy onto live apps and flows is painful and triggers “scream tests” when things suddenly break.
5. **Keep tenant rules more permissive than environment rules** to avoid unexpected conflicts and blocks.
6. **Review every quarter.** Microsoft ships roughly 10–15 new connectors per quarter, and each new one deserves a deliberate classification decision.
7. **Communicate the policy and an exception path.** Publish which connectors are Business, Non-business, and Blocked, and give makers an admin contact for exceptions so they know where to build and who to ask.
8. **Monitor continuously.** Use the CoE Starter Kit and Power Platform inventory to see real connector and operation usage, so policy decisions are grounded in evidence rather than guesswork.
One more note worth internalizing: align your DLP strategy with your environment strategy. Environment groups do not yet have a rule that applies a data policy directly, but you can name a data policy to match an environment group and apply it to those environments, keeping the mental model clean.
The big shift: Advanced Connector Policies
DLP served the platform well for nearly a decade, but the world your makers operate in has changed. Copilot, agents, and personal developer environments have multiplied both the number of builders and the number of environments — a tenant that had dozens of environments two years ago can have thousands today. And what needs governing is no longer just *which* connectors, but which **actions** and **MCP servers** an AI tool reaches through. To meet that moment, Microsoft made **Advanced Connector Policies (ACP)** generally available in June 2026.
ACP is a ground-up redesign with a much simpler mental model: **every environment has at most one policy in effect**, either inherited from its environment group or set directly on the environment. The headline changes:
– **One clear question.** The Business and Non-business classifications are gone. A connector or action is simply allowed or blocked.
– **An allowlist, not a sorting exercise.** You start from “nothing extra is allowed” and add the connectors your teams need. A brand-new connector is blocked until you decide on it, so nothing slips in just because it is new.
– **Action and MCP-server level control.** Allow a connector but switch off a single risky or deprecated action, and block an MCP server just like any other connector — the controls AI agents actually need.
– **Govern what used to be non-blockable.** On managed environments and environment groups, you can now block connectors that classic DLP could never touch.
– **It scales with environment groups.** When a new environment is created and routed to a group, the correct policy snaps into place automatically — no more include/exclude bookkeeping.
ACP also shifts feedback earlier. It enforces at run time, but with GA, makers now find out at design time — the moment they add a connector or action — whether that choice is allowed, instead of discovering it only when the app runs.
Crucially, **DLP is not going away overnight.** Some classic capabilities, notably custom connectors and endpoint filtering, have not yet reached parity in ACP. Until they do, you can run ACP and DLP together in **mixed mode**, then move to a clean ACP-only posture when you are ready. Before changing any connector policy, review Power Platform inventory — now with preview visibility into connector and operation usage — so you can assess impact before you publish.
The bottom line
DLP policies matter because they convert an open, everyone-can-build platform into a governed one without smothering it. They stop the accidental leaks, contain shadow IT, and apply one consistent boundary across apps, flows, and agents. The fundamentals — classify connectors, control combinations, baseline at the tenant and refine per environment — remain the foundation of Power Platform governance.
The direction of travel is clear, though. As your estate grows and agents become first-class builders, the future is the simpler, allowlist-driven, environment-group-native model of Advanced Connector Policies. The smart move today is to run a solid DLP posture, start piloting ACP in a single environment or group, and plan your migration deliberately.
–
*Further reading: Microsoft Learn — Data Loss Prevention (DLP) policies; Establishing and implementing a DLP strategy; Advanced Connector Policies (aka.ms/LearnACP).*