DLP Policies for Agents

Overview

Copilot Studio agents use connectors to interact with data sources and external services. Every connector represents a potential data flow—data moving from one service to another through your agent. Without Data Loss Prevention policies, those data flows are uncontrolled. An agent could retrieve sensitive data from SharePoint and send it to an unauthorized external service.

DLP policies are your enforcement mechanism for controlling where data can go. This video shows you how DLP applies specifically to Copilot Studio agents, how to configure connector policies for government environments, and how to monitor for violations.

What You’ll Learn

• DLP fundamentals: How Data Loss Prevention policies apply to Copilot Studio agents
• Connector classification: How to configure Business, Non-Business, and Blocked connector groups
• Data flow control: How to block sensitive data flows and handle the HTTP connector
• Violation monitoring: How to detect and respond to DLP violations

Script

Hook: Your agents move data—do you control where?

Every Copilot Studio agent that connects to a data source or calls an API is moving data. It might be pulling documents from SharePoint, writing records to Dataverse, or calling an external API to look up information. Each of those actions is a data flow.

The question is: do your DLP policies cover those data flows?

If you are not sure, you are not alone. Many organizations set up DLP for Power Automate and Power Apps but overlook Copilot Studio. In the next seven minutes, I will show you how DLP applies to Copilot Studio agents, how to configure connector policies, and how to monitor for violations.

How DLP applies to Copilot Studio

DLP policies in Power Platform control which connectors can be used together within a single resource—whether that resource is a Power App, a Power Automate flow, or a Copilot Studio agent.

The mechanism is connector classification. Connectors are sorted into three groups: Business, Non-Business, and Blocked.

Business connectors can share data with other Business connectors. Non-Business connectors can share data with other Non-Business connectors. But data cannot flow between the Business group and the Non-Business group. This is the core DLP enforcement. If an agent tries to take data from a Business connector and pass it to a Non-Business connector, the action is blocked.

Blocked connectors cannot be used at all. If a connector is in the Blocked group, any agent that tries to use it will fail at that action.

Here is an important detail about how enforcement works. DLP violations are enforced at runtime, not at design time. This means a developer can build and publish an agent that violates DLP policy. The agent will publish successfully. But when a user triggers the violating action—say, trying to send SharePoint data through a Non-Business connector—the action fails at that moment.

This runtime enforcement model means you should test your agents against DLP policies before publishing. Do not assume that a successful publish means the agent is fully compliant. Run through every conversation path and verify that all connector actions execute successfully.

Configuring connector policies for agents

To configure DLP policies, navigate to the Power Platform admin center and select Data policies from the left navigation.

You can create a new DLP policy or edit an existing one. Each policy lets you classify connectors into the three groups.

Start by deciding your classification strategy. For government scenarios, here is a typical approach.

Business connectors include your core organizational services: SharePoint, Dataverse, Office 365 Users, Office 365 Outlook, and Microsoft Teams. These are the services where your organizational data lives, and agents should be able to move data between them freely.

Non-Business connectors include services that are acceptable to use but should not exchange data with your core organizational services. This might include certain third-party services that are approved but should be isolated from your internal data.

Blocked connectors include any service that should never be used in your environment. Consumer social media connectors, personal email services, and any connector that routes data to services outside your authorized boundary belong here.

Apply the policy to specific environments or tenant-wide. Tenant-wide policies set a baseline. Environment-specific policies can add further restrictions for sensitive environments. If multiple policies apply to the same environment, the most restrictive policy wins—a connector that is blocked in any applicable policy is blocked regardless of what other policies say.

In GCC, GCC High, and DoD, review your connector classifications carefully. Some connectors that are acceptable in commercial environments may connect to services outside your government cloud boundary. Block any connector that routes data outside your authorized data boundary. This is not optional in government—it is a compliance requirement.

Blocking sensitive data flows

Let me walk through specific scenarios to make this concrete.

Scenario one: an agent retrieves documents from SharePoint and sends a summary to an external API through a custom connector. If SharePoint is classified as Business and the custom connector is classified as Non-Business, the data transfer from SharePoint to the custom connector is blocked. The agent will fail at the step where it tries to pass SharePoint data to the external service. This is DLP working as intended—preventing organizational data from leaving your controlled boundary.

Scenario two: an agent uses a custom connector to call a third-party service for lookup data. Custom connectors inherit the default classification in your policy. If you have not explicitly classified a custom connector, it falls into whichever group your policy uses as the default. Review every custom connector and classify it explicitly—do not rely on the default.

Scenario three: the HTTP connector. This connector can call any URL, making it a potential bypass for DLP policies. An agent could use the HTTP connector to send data to any endpoint on the internet. If your agents should not make arbitrary external calls, block or restrict the HTTP connector. This is one of the most commonly overlooked DLP gaps in Copilot Studio deployments.

The governing principle for government environments: be explicit about what is allowed rather than trying to block everything that is not. For agents handling CUI or sensitive government data, take a deny-by-default approach. Block all connectors except those explicitly authorized for your environment. This aligns with zero-trust principles and is easier to audit than a permissive policy with a growing list of exceptions.

Monitoring DLP violations

Configuring DLP policies is step one. Monitoring violations is step two.

DLP violation events are logged in the Power Platform admin center. Review these violations regularly to identify problems before they affect users.

Common findings include agents that were built before the DLP policy was applied. These agents may have been working fine, but once a new DLP policy takes effect, their connector actions may start failing. You need to identify these agents and either update them to comply or adjust your policy if the usage is legitimate.

You will also find violations from new connectors that were not yet classified in your policy. As the connector ecosystem grows, new connectors appear that your policy does not address. Review new connectors regularly and classify them before they get used in production agents.

Attempts to use blocked connectors also appear in the violation logs. These may indicate that a developer is trying to use a service that is not authorized in your environment. Follow up with the developer to understand their need and either provide an alternative or adjust the policy if appropriate.

Activity logging captures DLP enforcement events in the audit log. This is your compliance record—evidence that your DLP policies are being enforced and that violations are being tracked.

Set up proactive monitoring. Configure alerts for DLP violations so you catch them quickly rather than discovering them during a quarterly review. The sooner you know about a violation, the sooner you can address it.

Use violations as feedback to improve your policies. If legitimate agents are consistently being blocked by your DLP configuration, that is a signal that your classifications may need adjustment. DLP should protect sensitive data, not prevent your organization from building useful agents.

Integrate DLP violation monitoring with your agency’s security operations workflow. DLP violations in Copilot Studio should be treated with the same seriousness as DLP violations in any other Microsoft 365 workload. Your SOC team should have visibility into these events.

Close: DLP is your data boundary

Let us recap. DLP policies control data flows by classifying connectors into Business, Non-Business, and Blocked groups. Configure these classifications with government-appropriate defaults—block connectors that route data outside your authorized boundary. Monitor violations through the admin center and audit logs, and integrate monitoring into your security operations workflow.

DLP policies are your enforcement mechanism for data boundaries. Without them, your agents can move data anywhere their connectors reach. With them, you have control.

Next up, we will cover agent lifecycle management for maintaining agent health over the long term.

Sources & References

• Data Loss Prevention policies — Comprehensive guide to DLP policies in Power Platform
• Connector classification in DLP — Detailed guide for classifying connectors in DLP policies
• Copilot Studio documentation — Main documentation hub for Copilot Studio
• Power Platform admin center — DLP configuration and monitoring documentation