Power Platform DLP Policies: Connector Governance Guide

Power Platform DLP policies seem like a dull admin control until a flow connects payroll data to a consumer service. The goal is not to block makers into giving up. Instead, it is to build connector guardrails that protect business data, keep useful automation running, and give admins a repeatable way to review risk.

This guide gives you a practical design pattern for DLP across Power Apps, Power Automate and Copilot Studio. It covers classic data policies, connector classification, Advanced Connector Policies, Copilot Studio controls, rollout sequencing, and the checks that keep production running.

What Power Platform DLP policies control

Microsoft describes data policies as guardrails that reduce the risk of users unintentionally exposing organizational data. The control point is the connector: SharePoint, Dataverse, Outlook, SQL, Salesforce, HTTP, custom APIs, Copilot Studio capabilities and many more. Because makers use connectors to read and write data, connector governance is the practical boundary between useful automation and data ending up somewhere it shouldn’t.

Classic DLP policies classify connectors into three groups:

• Business: connectors trusted with sensitive or organizational data, such as SharePoint, Dataverse, SQL or approved line-of-business systems.
• Non-business: connectors for lower-trust or personal services. New connectors usually land here unless you set a different default.
• Blocked: connectors makers cannot use in the scoped environments.

The key rule: connectors in the same group can share data; connectors in different groups cannot. For example, put SharePoint and Salesforce in Business and Gmail in Non-business, and makers cannot build a flow that combines SharePoint with Gmail in that policy’s scope.

A practical connector classification pattern

Use a classification simple enough to explain and strict enough to matter. If nobody understands the policy, nobody can operate it during an incident.

Be especially careful with HTTP connectors. Microsoft notes that HTTP, HTTP Webhook and “When an HTTP request is received” are within data policy scope. It also notes that child flows share an internal dependency with the HTTP connector. So if you classify HTTP too aggressively in shared environments, you can break child flows by accident.

Design scopes around environments

A good DLP strategy starts with your environment strategy. The default environment should not have the same connector freedom as a managed production environment or a sandbox for integration-heavy makers. If you use Managed Environments, align data policies to those boundaries so DLP reinforces your environment model.

• Default environment: conservative connector set, no broad HTTP or custom connector access, and clear maker guidance.
• Productivity environments: approved Microsoft 365 connectors and low-risk automation patterns.
• Integration environments: custom connectors, HTTP, premium connectors or external systems, only after review.
• Regulated environments: Advanced Connector Policies, stricter allowlists and a formal exception process.

Related governance guides: Copilot Agent Builder governance and Restricted Content Discovery for SharePoint and Copilot.

Where Advanced Connector Policies fit

Advanced Connector Policies (ACP) are Microsoft’s newer governance model for connectors. Instead of the Business, Non-business and Blocked groups, ACP uses a strict allowlist: everything is blocked unless explicitly allowed. That is a much stronger posture for regulated or high-control environments.

ACP also gives more granular visibility into certified connectors, including triggers, internal actions and deprecated actions. It can be configured per environment or through environment groups. Microsoft documents two enforcement modes. In mixed mode, ACP runs alongside classic data policies and the most restrictive setting wins. In ACP-only mode, classic policy evaluation is skipped for that scope.

Recommendation: start ACP in mixed mode in a pilot environment. Inventory active apps, flows and agents first, build the allowlist, and test both authoring and runtime behavior. Only then decide whether ACP-only makes sense. Default-deny without discovery is just an outage waiting to happen.

Don’t forget Copilot Studio agents

Copilot Studio adds a different kind of risk, because agents combine knowledge, channels, tools, authentication choices, event triggers and Power Platform connectors. Microsoft documents DLP controls for agents. These include policies to require user authentication, block certain knowledge source types, block connectors as tools, block HTTP requests, block skills, restrict publishing channels and block event triggers.

Two details matter. First, Copilot Studio enforces data policies in real time, so makers and users see policy violation messages. Second, since early 2025, agent DLP enforcement exemptions are no longer supported, so previously exempted agents are now subject to enforcement. If your tenant has older agents, review them before changing policies.

Rollout runbook for Power Platform DLP policies

Policy changes have enforcement effects. Microsoft describes a cascade: saved policy configuration flows down to environments, and resources periodically check for updates. Violating apps, flows and agents may be suspended or quarantined, blocked connections can be disabled, and running resources can fail when they hit blocked pieces. Most enforcement happens within an hour, but it can take up to 24 hours.

1. Inventory first. Export apps, flows, agents, owners, environments, connectors, custom connectors and HTTP usage. The Power Platform admin PowerShell cmdlets help automate this.
2. Tag owners. Every exception needs a current human owner, not someone who left the team two years ago.
3. Design the baseline. Define Business, Non-business and Blocked groups for the default, productivity and integration environments.
4. Pilot changes. Use a low-risk environment or environment group, and test both maker authoring and existing runtime flows.
5. Communicate the impact. Tell makers what is changing, why, what errors they might see and how to request an exception.
6. Monitor and tune. Watch failures, quarantine events, tickets and maker feedback, and refine the policy rather than declaring victory from a dashboard.

Exceptions: yes, with a record

DLP exceptions are normal in a real business. The failure is approving them with no scope, owner, expiry or review. A good exception record includes:

• Environment name and ID
• App, flow or agent name
• Connectors and data groups involved
• Business justification
• Data classification and any external destination
• Owner and backup owner
• Expiry or review date
• Rollback plan if runtime impact appears

Quick checklist

• Use Power Platform DLP policies to separate business data connectors from lower-trust services.
• Keep the default environment conservative.
• Don’t block HTTP casually if child flows or integrations depend on it.
• Use dedicated environments for higher-risk connectors and custom APIs.
• Pilot ACP in mixed mode before considering ACP-only.
• Review Copilot Studio controls for authentication, knowledge sources, tools, channels and event triggers.
• Document exceptions with owners and review dates.
• Tell makers what changed before they find out from an error message.

Bottom line

The best Power Platform DLP policies are not the strictest ones; they are the clearest and the easiest to operate. Use classic DLP where connector grouping and HTTP or custom connector governance matter. Use Advanced Connector Policies where default-deny makes sense. Then wrap both in an environment strategy, owner documentation and a rollout plan that respects production.

Last reviewed: October 2026

Sources

• Data policies overview (Microsoft Learn)
• Manage data policies (Microsoft Learn)
• Connector classification (Microsoft Learn)
• Advanced connector policies (Microsoft Learn)
• Configure data policies for Copilot Studio agents (Microsoft Learn)
• PowerShell support for Power Apps and Power Automate (Microsoft Learn)