Power Platform DLP policies are one of those admin controls that sound boring right up until a flow connects payroll data to a consumer service and everyone suddenly discovers a deep appreciation for governance. The trick is not to block makers into despair. The trick is to build connector guardrails that protect business data, keep useful automation alive, and give admins a repeatable way to review risk.
Apps, flows, agents
Business / Non-business / Blocked
SharePoint, Dataverse, HTTP
Useful automation with fewer surprises
This guide gives you a practical design pattern for Power Platform DLP policies across Power Apps, Power Automate, and Copilot Studio. We’ll cover classic data policies, connector classification, Advanced Connector Policies, Copilot Studio-specific controls, rollout sequencing, and the “please don’t break production on a Tuesday” checks that matter.
What Power Platform DLP policies actually control
In Microsoft’s model, data policies act 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. Since makers use connectors to read, write, populate, push, and pull data, connector governance becomes the practical boundary between “nice automation” and “oh no, why is that data over there?”
Classic DLP policies classify connectors into three groups:
- Business: connectors trusted for sensitive or organizational data, such as SharePoint, Dataverse, SQL, or approved line-of-business systems.
- Non-business: connectors for lower-trust or personal-use services. New connectors commonly land here unless you set a different default.
- Blocked: connectors makers cannot use in the scoped environments.
The key rule is simple: connectors in the same data group can share data; connectors in different groups cannot. Put SharePoint and Salesforce in Business and Gmail in Non-business, and makers cannot build a flow that mixes SharePoint with Gmail in that policy scope.
Sensitive org data
Lower-trust or personal services
No use where policy applies
Review new connectors regularly
A practical connector classification pattern
Use a classification pattern that is boring enough to explain and strict enough to matter. If nobody can understand the policy, nobody can operate it during an incident.
| Connector type | Suggested starting group | Why | Admin check |
|---|---|---|---|
| Core Microsoft 365 business data: SharePoint, Outlook, Teams, Planner, Power BI | Business | These commonly hold organizational content and collaboration data. | Confirm which combinations are acceptable. SharePoint plus Outlook may be fine; SharePoint plus personal services probably is not. |
| Dataverse and approved line-of-business systems | Business | Usually high-value business records or process data. | Document owners and environments. Treat production Dataverse like production, not like a maker playground with better furniture. |
| Consumer/social connectors | Non-business or Blocked | Useful in some marketing scenarios, risky in broad default environments. | Allow only in dedicated environments with owners and review cadence. |
| HTTP, HTTP Webhook, custom connectors | Dedicated environment or tightly reviewed classic DLP | They can reach almost anything, which is both the magic and the problem. | Use endpoint filtering where appropriate and require owner documentation. |
| Copilot Studio channels, knowledge, authentication, and tool controls | Depends on agent risk | Agents can expose knowledge sources, publish to channels, or call tools. | Block unauthenticated/public paths unless there is a clear business case. |
Be especially careful with HTTP connectors. Microsoft notes that HTTP, HTTP Webhook, and “When an HTTP request is received” are within data policy scope, and that child flows share an internal dependency with the HTTP connector. If you classify HTTP too aggressively in shared environments, you can accidentally break child flow scenarios. That is not a governance win; that is a ticket generator wearing a fake moustache.
Design scopes around environments, not org-chart vibes
A useful DLP strategy normally starts with environment strategy. The default environment should not have the same connector freedoms as a managed production environment or a sandbox for integration-heavy makers. If you already use managed environments, align data policies to those boundaries so your DLP model reinforces your environment model instead of arguing with it in the hallway.
- Default environment: conservative connector set, no broad HTTP/custom connector freedom, and clear maker guidance.
- Productivity environments: allow approved Microsoft 365 connectors and low-risk automation patterns.
- Integration environments: allow custom connectors, HTTP, premium connectors, or external systems only after review.
- Regulated environments: consider Advanced Connector Policies, stricter allowlists, and a more formal exception process.
For internal links and adjacent governance thinking, your admins may also like the SharePoint Monkey guides on Microsoft 365 Copilot Agent Builder governance and Restricted Content Discovery for SharePoint and Copilot governance.
Where Advanced Connector Policies fit
Advanced Connector Policies, or ACP, are Microsoft’s newer governance model for connector usage. Instead of the classic Business, Non-business, and Blocked model, 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 brings more granular visibility for certified connectors, including triggers, internal actions, and deprecated actions. It can be configured on individual environments or through environment groups. Microsoft documents two enforcement modes: mixed mode, where ACP runs alongside classic data policies and the most restrictive setting wins, and ACP-only mode, where classic data policy evaluation is skipped for the affected scope.
Business / Non-business / Blocked
Strict allowlist
Most restrictive wins
Use after migration proof
My recommendation: start ACP in mixed mode for a pilot environment. Inventory active apps, flows, and agents first; build the allowlist; test maker authoring and runtime behavior; then decide whether ACP-only makes sense. Default-deny is powerful, but default-deny without discovery is just an outage wearing a security badge.
Do not forget Copilot Studio agents
Copilot Studio brings a slightly different flavor of risk because agents can combine knowledge, channels, tools, authentication choices, event triggers, and Power Platform connectors. Microsoft documents DLP controls for agents, including policies to require user authentication, block certain knowledge source types, block Power Platform connectors as tools, block HTTP requests, block skills, restrict publishing channels, and block event triggers.
Two details matter for admins. First, Microsoft states that Copilot Studio supports data policy enforcement in real time, so makers and users see policy violation messages. Second, since early 2025, agent data policy enforcement exemption is no longer supported: previously exempted agents are subject to enforcement. If your tenant has older agents, review them before policy changes surprise everyone.
| Copilot Studio risk | Policy idea | Question to ask |
|---|---|---|
| Anonymous or broad access | Block no-authentication chat paths where not approved. | Should this agent require Microsoft Entra ID authentication? |
| Public or uncontrolled knowledge | Restrict knowledge source connectors or use endpoint filtering. | Can this agent use public websites, documents, SharePoint, or OneDrive? |
| External tool execution | Control Power Platform connectors, HTTP, and MCP-related access. | What can the agent call, and under whose permissions? |
| Publishing sprawl | Block unapproved channels such as public web, Direct Line, or social channels. | Where is this agent allowed to appear? |
Rollout runbook: safer policy changes in six steps
Connectors + owners
One environment
Mixed mode first
Failures + tickets
Exceptions + docs
Policy changes have enforcement effects. Microsoft describes a cascade process where saved policy configuration flows down to environments, resources periodically check for updated configuration, violating apps/flows/chatbots may be suspended or quarantined, blocked connections can be disabled, and runtime resources can fail when they try to use blocked pieces. Microsoft also notes that enforcement latency varies: most cases are within an hour, while extreme cases can take up to 24 hours.
- Inventory first. Export apps, flows, agents, owners, environments, connectors, custom connectors, and HTTP usage. Power Platform admin PowerShell cmdlets can help automate monitoring and management tasks.
- Tag owners. Every exception should have a human owner, not “that flow Bob made before he moved teams.” Bob is happy now. Let Bob rest.
- Design the baseline. Define Business, Non-business, and Blocked groups for the default environment, productivity environments, and integration environments.
- Pilot policy changes. Use a low-risk environment or environment group. Test both maker authoring and existing runtime flows.
- Communicate the impact. Tell makers what is changing, why, what errors they might see, and how to request an exception.
- Monitor and tune. Watch failures, quarantine events, support tickets, and maker feedback. If a policy creates chaos, refine it instead of declaring victory from a dashboard.
Exception process: yes, but with receipts
DLP exceptions are not a failure. They are how a real business works. The failure is approving exceptions with no scope, no owner, no expiration, and no review. A good exception record should include:
- Environment name and ID.
- App, flow, or agent name.
- Connector names and data groups involved.
- Business justification.
- Data classification and external destination, if any.
- Owner and backup owner.
- Expiration or review date.
- Rollback plan if runtime impact appears.
Quick checklist for Power Platform DLP policies
- Use Power Platform DLP policies to separate business data connectors from lower-trust services.
- Keep the default environment conservative.
- Do not casually block HTTP if child flows or integration patterns 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 agent controls for authentication, knowledge sources, tools, channels, and event triggers.
- Document exceptions with owners and review dates.
- Tell makers what changed before they discover it through angry red error messages.
Final take
The best Power Platform DLP policies are not the strictest possible policies. They are the clearest, most explainable, and most operationally survivable policies. Use classic DLP where connector grouping and HTTP/custom governance matter. Use Advanced Connector Policies where default-deny and certified connector granularity make sense. Wrap it all in environment strategy, owner documentation, and a rollout plan that respects production.
That is how you protect SharePoint, Dataverse, Microsoft 365, Copilot Studio, and external integrations without making every maker feel like the admin center personally stole their lunch.
Sources
- Data policies overview – Power Platform
- Manage data policies – Power Platform
- Connector classification – Power Platform
- Advanced connector policies – Power Platform
- Configure data policies for Copilot Studio agents
- PowerShell support for Power Apps and Power Automate
Discover more from SharePoint Monkey
Subscribe to get the latest posts sent to your email.