How connector policies actually protect your data -the model, the traps that catch people, and what changed in 2026. For IT, security and governance teams.

Every Power Platform governance conversation eventually arrives at the same foundation: data loss prevention. Before environments, before a Centre of Excellence, before AI agents, DLP is the control that decides whether a maker can wire your corporate data to a personal or third-party service -by accident or otherwise. Get it wrong and everything built on top is exposed. Get it right and makers can build freely without becoming a security incident. It should be the first thing on any rollout plan. This guide covers how it actually works, the traps that catch people, and what changed in 2026.

What DLP actually controls

A data loss prevention policy -a “data policy” in the admin centre -governs which connectors apps, flows and agents can use, and, crucially, which connectors they can use together. It is connector-aware: it reasons about the services a resource touches, not the individual records passing through. Two consequences catch people out. First, DLP is enforced at the environment or tenant level -never at the level of an individual user. Second, it controls connector combinations, not the connection itself: DLP is not a substitute for API access control. If a data source must be restricted to certain people, enforce that at the API -do not rely on a connector policy to do a job it was never designed for.

The classic model: Business, Non-Business, Blocked

For years the model has rested on three groups. Every connector is classified as Business, Non-Business or Blocked, and the rule is simple: a connector can only be combined with other connectors in the same group, and a Blocked connector cannot be used at all. The canonical example is the one that prevents most real-world leaks -an app cannot combine a Business connector such as SharePoint with a Non-Business one such as personal Gmail, so corporate data cannot be quietly routed to a personal inbox. When you create a new policy, every connector starts in Non-Business; you promote the ones you trust to Business and push the dangerous ones to Blocked. Where two policies touch the same environment, the most restrictive wins.

What changed in 2026: Advanced Connector Policies

The classic model is still the foundation most organisations run on today, but it is being superseded -and if you are setting up governance now, you should know where it is heading. In 2026 Microsoft made Advanced Connector Policies (ACP) generally available, changing the mental model in three important ways:

From sorting to an allowlist. Instead of classifying every connector into a bucket, ACP starts from “nothing extra is allowed” and you add the connectors and actions your teams actually need. A brand-new connector is blocked until you decide on it -so nothing slips in simply because it is new.

One policy per environment. The old world of overlapping tenant, environment and maker-created policies -where predicting the effect of a change meant holding several rule scopes in your head -is gone. Under ACP every environment has at most one policy in effect, inherited from its environment group. That is the whole model.

Action-level and agent-level control. You can allow a connector but switch off a single risky or deprecated action -and, critically for AI, you can block the MCP servers that agents use to reach external tools, governing them exactly like any other connector.

ACP exists because personal developer environments and environment routing created far too many environments for the old include-and-exclude approach to keep up with; the right policy now follows the environment automatically. The guidance below applies under either model -but where they differ, the direction of travel is firmly toward the allowlist.

Start with the default environment

If you do only one thing, do this. Every licensed user is automatically a maker in the default environment and cannot be stopped from building there -which makes it the single biggest source of ungoverned data movement in most tenants. Lock it down: put every connector that can be blocked into Blocked, leave only the handful that cannot be blocked in Business, and set the default group to Blocked, so any new connector is automatically blocked until reviewed. The default environment should be the most restricted place in your tenant, not the free-for-all it is out of the box. It is also worth pairing DLP with Managed Environments, whose additional controls -sharing limits, usage insights and stricter admin oversight -close gaps that connector policy alone cannot, particularly in shared and production environments.

A practical policy pattern

Beyond the default environment, a few habits separate a DLP strategy that holds from one that leaks or frustrates. Start by choosing your overall approach: a shared strategy applies one standard policy across environments -simplest to maintain, but a connector approved anywhere is approved everywhere -while a bespoke strategy gives each environment stack its own policy, which suits departmental separation (a finance connector only in finance environments) at the cost of more to manage. Most organisations lean shared for simplicity and layer bespoke policies only where a real separation of duties demands it.

Keep dev, test and prod under one policy. Promoting an app between environments governed by different policies is how live apps suddenly break. One consistent policy across the lifecycle avoids it.

Block by default in every new environment. Start locked, then add only the connectors that environment genuinely needs -Salesforce here, SQL Server there -rather than opening everything and clawing back.

Keep the tenant-wide policy light. Use it only to block genuinely dangerous connectors everywhere. Because the most restrictive policy wins, over-blocking at tenant level frustrates every maker and makes administration harder.

Control at the action and endpoint level. Allow a connector but disable its risky or deprecated actions; restrict SQL Server to a single endpoint; grant read-only access where a maker has no need to write. Blunt allow-or-block is rarely the finest control available.

Watch the HTTP connector. Child flows depend on it, so misclassifying HTTP can silently break automations. If it is risky in shared environments, block it there and give makers who need it a dedicated, restricted environment.

Classify custom connectors deliberately. Classify them by name at the environment level and by URL pattern at the tenant level, so an in-house connector never becomes a governance blind spot.

The part that breaks things: change management

DLP is not set-and-forget, and its biggest operational risk is self-inflicted. Changing a policy after apps and flows already exist can break them instantly. So before any change, run an impact analysis -the Centre of Excellence Starter Kit includes a DLP editor that shows exactly which apps and flows a change will affect -then warn the makers involved and give them a route to comply. Customise the governance error message (through PowerShell) so a blocked maker sees who to contact rather than a dead end. And review your policies on a regular cadence: Microsoft adds new connectors every quarter, and an unreviewed policy quietly drifts out of date.

DLP in the agentic era

DLP has quietly become one of the most important controls for AI, not just for apps and flows. Data policies now extend to Copilot Studio agents and to individual desktop-flow actions, governing how an agent connects to and interacts with data inside and outside the organisation. As agents proliferate, this is the control that stops one quietly reaching a data source it was never meant to touch -and with ACP’s ability to block MCP servers, it is how you keep an agent’s reach inside approved boundaries. If you are scaling agents, your DLP strategy is no longer a Power Apps concern; it is central to your AI governance.

The bottom line

DLP is the foundation the rest of your governance stands on. Neglect it and every environment, app and agent above it is exposed; get it right and your makers can build freely without becoming your next security incident. The real work is not the initial setup -it is treating DLP as a living policy that keeps pace with new connectors, new environments and, now, new agents.

VE3 helps organisations design and operate DLP and connector-policy strategies as part of a governed Centre of Excellence. Our free Power Platform Readiness Framework assesses your security and compliance posture across eleven domains, so your data guardrails are built on evidence, not assumption.