TL;DR: Advanced Connector Policies (ACP) do not completely replace Data Loss Prevention (DLP) policies in Power Platform. ACP introduces a more granular, allowlist-based approach to connector governance, while DLP still provides important controls for custom connectors, HTTP integrations and endpoint restrictions. The biggest opportunity isn’t policy migration, but adopting a least-privilege governance model that defines what each environment actually needs.
Introduction
“Advanced Connector Policies are here, so we don’t need DLP anymore.”
Not quite.
Advanced connector policies, or ACP, mark an important evolution in Power Platform governance. Microsoft is clearly moving away from the traditional business, non-business and blocked connector model towards a more explicit allowlist approach. But saying “ACP replaces DLP” oversimplifies what is really changing.
The more useful question is this: What governance problem is each control solving?
ACP is not simply a newer version of the same policy screen. It changes how we should think about connector governance.
Why traditional DLP became difficult
Traditional Power Platform data policies were built around a relatively straightforward idea. Simple in theory, but often more complicated in practice.
Administrators classified connectors into categories such as:
- Business
- Non-business
- Blocked
The objective was clear: prevent inappropriate movement of organisational data between services. That model was valuable, and it still solves a real governance problem. But Power Platform has evolved considerably.
Today organisations are managing:
- hundreds of certified connectors
- custom connectors
- HTTP integrations
- Power Apps and Power Automate workloads
- Copilot Studio agents
- AI capabilities
- MCP servers
- rapidly expanding integration surfaces
At that scale, governance can easily turn into: “Here are hundreds of connectors. Decide which bucket every single one belongs in.”
That becomes difficult to maintain and even harder to explain.
More importantly, it encourages organisations to think broadly about whether a connector is trusted rather than whether a workload actually needs it.
ACP changes the default position
One of the most important differences with ACP is the shift towards an explicit allowlist model. Rather than starting with “What should we block?”, governance teams can begin with a more useful question: “What does this environment actually need?”
Consider an environment dedicated to an internal HR application. The solution might require only:
- Dataverse
- Microsoft 365 Users
- Outlook
- one approved HR integration
If those are the workload’s only requirements, there is little reason to expose another hundred connectors simply because the organisation generally considers them trustworthy.
This is where ACP moves Power Platform governance closer to the principle of least privilege. Instead of defining what an organisation broadly trusts, governance can define what a specific environment is intended to use.
ACP Does Not Make Existing DLP Capabilities Disappear
This is where the phrase “ACP replaces DLP” becomes misleading.
ACP currently focuses primarily on certified connectors. Existing data policies still matter in governance scenarios involving custom connectors and HTTP-based integrations.
Traditional data policies can also provide connector endpoint filtering, allowing administrators to restrict which endpoints supported connectors may access.
An organisation should therefore not enable ACP-only mode and assume that every control in its existing governance model has automatically moved across.
The first question should be: What controls are we relying on today, and which of them are actually covered by ACP?
Be Careful During the Transition
The transition period may create more complexity than either model would on its own. Organisations may temporarily operate with both ACP and traditional data policies, making it harder to identify which control is responsible when a workload is blocked.
For example, a maker reports, “My app can’t use this connector.” The administrator checks the traditional DLP policy, and everything appears correct. The restriction is actually coming from ACP, or ACP permits the connector while an existing data policy applies a more restrictive rule.
Across a large tenant, this can quickly create:
- unclear policy ownership
- troubleshooting complexity
- overlapping controls
- inconsistent assumptions
- maker frustration
- administrators becoming reluctant to change anything
ACP adoption is therefore more than a policy migration exercise; it also requires a clear operating model.
Teams need to understand:
- which policy layer owns which control
- how exceptions are handled
- how blocked workloads are investigated
- how policy changes are tested
- who approves new connector requirements
Without that clarity, adding another governance control can make governance harder rather than stronger.
Do Not Simply Rebuild Your Old DLP Policy in ACP
This may be the biggest missed opportunity.
If an organisation has spent years building an enormous connector-classification policy, the instinct may be to recreate the same configuration in ACP. That may help during migration, but it should not become the end state.
ACP gives organisations an opportunity to return to first principles. Instead of asking, “Which of our existing connectors should we allow?”, work through the following questions:
- What is this environment for?
- Which services does that purpose require?
- Which capabilities are actually necessary?
The governance model then becomes:
Environment purpose → permitted services → required capabilities → business justification
That is a stronger approach than allowing large groups of connectors simply because they were classified as trusted several years ago.
ACP Should Make Us Rethink Governance, Not Rename It
Advanced connector policies are a major step forward, but their value is not simply that they replace one Power Platform policy mechanism with another. The bigger opportunity is the change in mindset.
Traditional connector governance often started by asking, “What do we trust?” Modern governance increasingly needs to ask, “What does this workload actually need?”
That is a more scalable principle, and it becomes even more important when the workload is no longer just an application or flow.
Once agents can dynamically select tools and actions, what we expose to the workload becomes part of the security boundary itself.
That is where this conversation becomes much more interesting.
