Data Loss Prevention(DLP) Policies
Data Loss Prevention (DLP) policies in Microsoft Power Platform are essential tools for safeguarding organizational data by regulating how data can be shared across different connectors within apps and flows. These policies help prevent unintentional data exposure and ensure compliance with organizational standards.
Organizational data is administrators' most vital asset, crucial for building automation and company success. Rapidly deploy high-value agents for end users, integrating with multiple data sources and services, including non-Microsoft and social networks. However, this can expose data to leaks or unauthorized access. Administrators can use DLP policies with existing and Copilot Studio connectors to govern agents. Create these policies in the Power Platform admin center. You must be a tenant admin or have the Environment Admin role.
DLPs Concepts Explained
DLP policies can be established at two levels:
Tenant-Level Policies: Managed by tenant administrators, these policies can be applied across all environments, specific multiple environments, or all environments except certain excluded ones. This flexibility allows for broad governance while accommodating exceptions as needed.
Environment-Level Policies: Managed by environment administrators, these policies are specific to individual environments. It's important to note that environment-level policies cannot override tenant-level policies; instead, they add an additional layer of control within their specific scope.
Figure 1: Interfaces to manage DLPs
Connector Classification
Connectors in the Power Platform facilitate interactions between apps, data, and services. Within DLP policies, connectors are categorized into three groups:
Business: Connectors that handle business-sensitive data. Apps or flows using a connector from this group cannot combine it with connectors from the Non-Business group.
Non-Business: Connectors intended for personal or non-business data. Similar to the Business group, connectors here cannot be used alongside those from the Business group within the same app or flow.
Blocked: Connectors that are entirely restricted from use within the environment or tenant, preventing any data flow through them.
By default, when a new policy is created, all connectors are placed in the Non-Business group. Administrators can then reclassify connectors based on organizational requirements. This is done by "Set Default Group" in the picture below.
Implementing DLP Policies
To create or manage DLP policies, administrators can use the Power Platform admin center. The process involves:
Assigning a Policy Name: Clearly define the policy for easy identification.
Classifying Connectors: Categorize each connector into Business, Non-Business, or Blocked groups based on how they handle data.
Defining Policy Scope: Determine whether the policy applies to all environments, specific environments, or excludes certain environments.
Selecting Environments: Choose the environments to which the policy will be applied.
Reviewing Settings: Ensure all configurations align with organizational data governance strategies before finalizing the policy.
This structured approach ensures that data handling within the Power Platform aligns with organizational standards and regulatory requirements
Figure 2: Creating a DLP policy in Power Platform Admin Center
DLP Policies in Copilot Studio
In the context of Microsoft Copilot Studio, DLP policies extend to govern agents and their interactions with data sources and services. Administrators can classify Copilot Studio connectors into Business, Non-Business, or Blocked groups, similar to other connectors in the Power Platform. This classification helps protect organizational data from potential exfiltration by agent makers.
By effectively implementing and managing DLP policies, organizations can maintain robust data security, prevent unauthorized data sharing, and ensure compliance with internal and external data.
NOTE: By default, DLP enforcement for agents is turned off in all tenants.
To verify if DLP for Copilot Studio is activated for a tenant, you can execute the following PowerShell cmdlet.
Get-PowerVirtualAgentsDlpEnforcement -TenantId <tenant ID>If Copilot Studio DLP is not configured, the cmdlet results will be empty.
Use auditing or "soft" mode to see DLP errors in the Copilot Studio web or Teams apps
Execute the following PowerShell script to activate DLP policies in auditing mode. When configuring agents in the Copilot Studio web and Teams apps, agent makers will encounter DLP-related errors, but they will not be prevented from carrying out DLP-related actions. Furthermore, makers cannot publish agents while the soft mode is active.
Set-PowerVirtualAgentsDlpEnforcement -TenantId <tenant ID> -Mode SoftEnabledTo enforce DLP policies in Copilot Studio, you can execute the following PowerShell command. This will prevent agent creators from carrying out actions affected by DLP, and end users will encounter errors if they initiate such actions.
Set-PowerVirtualAgentsDlpEnforcement -TenantId <tenant ID> -Mode Enabled -OnlyForBotsCreatedAfter <date>After enabling, Copilot Studio can enforce DLP policies in real-time. This means both makers and end users will encounter DLP enforcement errors when a policy is in effect.
It's important that connectors reside within the same data group, as data sharing is not permitted between connectors in different groups.
Learn about enabling enforcement.
Figure 3: Copilot Studio connectors example
DLP Enforcement
At Design-time, Copilot Studio authors are guided to maintain compliance while building their solutions. If authors use blocked or mismatched connectors, such as combining Business and Non-Business groups, they receive errors in Power Apps and warnings in Power Automate. Apps and flows violating DLP policies cannot run, and Power Apps cannot even be saved until the issues are resolved.
At Run-time, DLP policies ensure continued compliance for published solutions. If policy changes make an app non-compliant, authors and users will be unable to launch it, seeing an error message instead. For Power Automate flows, non-compliant flows are automatically suspended to prevent execution. These updates typically take about five minutes to apply.
This enforcement framework ensures that Copilot Studio authors create secure, compliant, and reliable AI-driven solutions while protecting organizational data.
Figure 4: Error when violating DLPs
Other Settings
Tenant Settings: Publishing bots with AI features
Default enabled. Your admin can disable the publication of agents with generative AI features through the Power Platform admin center.
Deploy and enable actions in Copilot Studio
This is prerelease documentation and may change.
End users can use AI actions in chats with a Copilot agent if:
· The Microsoft 365 tenant admin deploys the Copilot Studio app.
· The end user enables the connection within their chat with the Copilot agent.
Figure 5: Deploy Copilot Studio app to enable the app in chats with a copilot agent
Manage Sharing From New Power Platform Admin Center
In Copilot Studio (Preview), sharing permissions are managed by defining roles for Editors and Viewers:
Editors: Can be granted permissions to edit, share, publish, and use Microsoft 365 Copilot agents and custom agents. By default, owners and editors can allow others to have these permissions.
Viewers: Can only use the agents without editing capabilities. Sharing Viewer permissions can be restricted further:
To specific individuals only (excluding security groups).
By limiting the number of viewers per agent.
These controls ensure secure and precise management of who can interact with Copilot agents, aligning with organizational data governance and security standards
Deep dive for Copilot Studio Connectors
Connector name | Description |
Application Insights in Copilot Studio | Block agent makers from connecting agent with Application Insights. |
Chat without Microsoft Entra ID authentication in Copilot Studio | Block agent makers from publishing agents that aren't configured for authentication.agent users must authenticate themselves to chat with the agent.For more information, see Data loss prevention example - Require end-user authentication in agents. |
Direct Line channels in Copilot Studio | Block agent makers from enabling or using Direct Line channel.For example, the Demo website, Custom website, Mobile app, and other Direct Line channels would be blocked. |
Facebook channel in Copilot Studio | Block agent makers from enabling or using the Facebook channel. |
Knowledge source with SharePoint and OneDrive in Copilot Studio | Block agent makers from publishing agents configured with SharePoint as a knowledge source. Supports DLP connector endpoint filtering to allow or deny endpoints. |
Knowledge source with public websites and data in Copilot Studio | Block agent makers from publishing agents configured with public websites as a knowledge source. Supports DLP connector endpoint filtering to allow or deny endpoints. |
Knowledge source with documents in Copilot Studio | Block agent makers from publishing agents configured with documents as a knowledge source. |
Microsoft Teams channel in Copilot Studio | Block agent makers from enabling or using the Teams channel. |
Omnichannel in Copilot Studio | Block agent makers from enabling or using the Omnichannel channel. |
Skills with Copilot Studio | Block agent makers from using skills in Copilot Studio agents.For more information, see Data loss prevention example - Block skills in agents and Data loss prevention example - Block HTTP requests in agents. |
Event triggers with Copilot Studio | Block agent makers from using event triggers in Copilot Studio agents.For more information, see Data loss prevention example - Block event triggers in agents. |
Table from Configure data loss prevention policies for agents - Microsoft Copilot Studio | Microsoft Learn
Stay tuned for more.
Sources:
Комментарии