If you’ve ever looked at a Power Platform DLP policy and found it impossible to anticipate the impact on a specific environment, rest assured — it wasn’t your fault. The tool simply fell short.
Overlapping policy scopes, tenant-wide rules colliding with environment-specific exceptions, and a classification model that forced every connector into a three-bucket sorting exercise — classic DLP was built for a simpler era. An era before personal developer environments numbered in the thousands, before agents started reaching out to external MCP servers, before “who built this and what can it connect to” became a question no admin could answer with confidence.
Advanced Connector Policies (ACP) hit general availability on June 4, 2026. This is not a patch on top of DLP. It is a governance model rebuilt from first principles — and if you are architecting Power Platform solutions at enterprise scale today, you need to understand exactly what changed, what it still cannot do, and where the transition will hurt before it helps.
What Actually Changed
ACP is a ground-up redesign of connector governance, moving away from the classic DLP model of sorting connectors into business, non-business, and blocked buckets. The core shift: every environment has at most one policy in effect — inherited from an environment group or set directly on the environment.
Benefits
1. Simplified Mental Model
The old DLP approach required holding several overlapping rule scopes in your head — tenant-wide rules, exceptions, and environment-specific policies — and the DLP wizard was optimized for placing policies but made it hard to identify the effective policy on a given asset. ACP eliminates that entirely with the one-policy-per-environment rule.
2. Allowlist-First Security Posture
You start from “nothing extra is allowed” and add the connectors your teams need. When a brand-new connector appears on the platform, it’s blocked until you decide — so nothing slips in just because it’s new. This is a significant improvement for enterprise risk management.
3. Action-Level Granularity
You can allow a connector but switch off a risky action or a deprecated one. For the first time you can see which actions are deprecated, which are internal, and which are triggers — right where you set the policy.
4. MCP Server Governance
Agents reach out to the world through MCP servers; ACP lets you block an MCP server just like any other connector or action. This is the most forward-looking feature — directly relevant to your agentic architecture work.
5. Scale with Environment Groups + Routing
Because ACP is a native part of environment groups, the right connector policy follows the environment automatically. As soon as a new environment is created and routed to a group, the correct policy snaps into place — with zero friction for makers and no ongoing environment-by-environment overhead for IT.
6. Earlier Feedback for Makers
When a maker first adds a connector or action to an app, flow, or agent, ACP can tell them immediately whether that choice is allowed in the environment they are building in. And soon, blocked connectors and MCP servers will be greyed out up front, so makers can focus only on the tools that are available, compliant, and expected to succeed.
7. Previously Non-Blockable Connectors Now Blockable
On managed environments and environment groups, you can block all connectors and actions — in classic DLP policies some connectors could not be touched.
Drawbacks / Gaps to Watch
1. Not Yet Feature-Complete vs. DLP
There are still important capabilities in classic DLP that customers rely on today — especially custom connectors and endpoint filtering — that have not yet fully landed in ACP. This is a meaningful gap for enterprise tenants with complex custom connector estates.
2. Mixed Mode Complexity During Transition
Until those experiences fully land in ACP, customers can use ACP and DLP together in mixed mode — combining the strengths of both systems where they need to. Running dual governance models simultaneously introduces its own cognitive overhead and potential for policy conflicts.
3. Runtime Enforcement Still the Primary Safety Net
ACP has enforced policy at runtime throughout public preview — meaning a maker could build a new asset, wire up connectors and actions, and only discover at runtime that the experience could never successfully run because it violated policy. The earlier design-time feedback is rolling in, but runtime-first has been the reality through preview.
4. Requires Managed Environments
Full ACP capability (blocking all connectors including previously non-blockable ones) is tied to managed environments and environment groups — not a zero-cost addition for tenants not yet on that licensing tier.
5. Migration Effort
Existing DLP policies don’t auto-migrate. The blog recommends reviewing Power Platform inventory — which now includes preview visibility into connector and operation usage across apps, flows, and agents — before making connector policy changes, to understand which resources could be affected before publishing a policy update. For large tenants, this impact analysis is non-trivial.
Conclusion:
ACP is the governance architecture Power Platform should have had three years ago. The one-policy-per-environment model, allowlist-first posture, action-level control, and native MCP server governance are not incremental improvements — they represent a genuinely different way of thinking about connector risk in an agentic world.
That said, GA does not mean ready to replace DLP wholesale. If your tenant carries custom connectors or relies on endpoint filtering, you are in mixed mode for now, whether you plan to be or not. The migration effort is real, the impact analysis is non-trivial at scale, and running two governance systems in parallel demands the same discipline you would apply to any dual-write architecture — deliberate, documented, and time-boxed.
Discover more from Ecellors Blog
Subscribe to get the latest posts sent to your email.
