Power Platform data policies control how agents, apps, and flows can use connectors and data sources. In Microsoft AI agent<\/a> environments, the policy is an active runtime boundary rather than documentation that makers can choose to ignore.<\/p>\n The topic belongs in Microsoft AI-103<\/a> architecture because a capable agent can still be unusable when its knowledge source, connector, HTTP action, or tool is forbidden by the environment\u2019s policy. Governance must therefore be tested with the deployed agent, not added after the build is functionally complete.<\/p>\n Microsoft now describes these controls broadly as data policies, although many teams still use the older DLP shorthand. Use current terminology in design documents while preserving the DLP term when discussing existing administrative processes or error messages.<\/p>\n In classic Power Platform data policies, connectors are grouped as Business, Non-Business, or Blocked. Data loss prevention<\/a> depends on how connector groups can exchange data: Business and Non-Business connectors cannot exchange data in the same governed resource, while Blocked connectors are unavailable where the policy applies.<\/p>\n The classification is about allowed data movement, not the reputation of the SaaS product. A connector can be trustworthy and still belong in a different data group because the organization does not want sensitive business content combined with that destination.<\/p>\n Some core connectors are not blockable and can only be classified into allowed groups. Administrators should understand those exceptions before choosing a default-deny-looking classic policy that cannot actually place every connector in Blocked.<\/p>\n Default classification deserves deliberate ownership. New connectors can enter the platform over time, and placing every unknown connector into a permissive group can create an unnoticed data path. Keep the default conservative enough for the organization and establish a review process for moving newly introduced connectors into the business-approved group.<\/p>\n Document exceptions for connectors that cannot be blocked. An administrator who assumes ‘Blocked by default’ literally applies to every connector can misread the effective posture, while a documented exception list makes the remaining identity and data controls easier to reason about.<\/p>\n Agent governance extends beyond ordinary connectors. Data policy settings can restrict knowledge sources, Power Platform connectors and tools, HTTP requests, skills, channels, triggers, and other Copilot Studio capabilities depending on the policy configuration.<\/p>\n This makes policy design a data-flow exercise similar to Purview DLP<\/a>. Inventory where prompts, retrieved knowledge, tool arguments, and generated outputs cross service boundaries, then place controls on those actual paths instead of on product labels alone.<\/p>\n Validate both maker experience and runtime behavior. A tool may be visibly unavailable during authoring, while a deployed agent can also encounter enforcement when a previously allowed connector or action becomes restricted.<\/p>\n Knowledge sources<\/a> deserve the same inventory discipline as tools. An agent can leak or blend data through retrieval even when its action connectors are tightly controlled, so document which sources are allowed, which environments host them, and whether the source content carries a sensitivity classification.<\/p>\n Policy tests should include realistic prompts that attempt to bridge data groups. A maker can configure components individually without noticing that the combined agent creates a prohibited path; end-to-end tests reveal the actual movement the platform will allow or deny.<\/p>\n Copilot Studio can add tools and resources from Model Context Protocol servers, but MCP connectivity relies on Power Platform connectors. Blocking or restricting the connector path can therefore make an MCP server or its tools unavailable even if the MCP endpoint itself is healthy.<\/p>\n When an MCP server exposes many tools, enable only the ones the agent needs and govern the connector that carries the connection. This reduces both attack surface and accidental policy interaction when a server later adds capabilities that were never part of the original agent design.<\/p>\n Treat MCP tool availability as a deployment dependency. Test the same server and tool set under the target environment\u2019s data policies rather than assuming a development environment proves production compatibility.<\/p>\n Connector ownership becomes important during incident response. If an MCP server is reachable through a connector owned by another platform team, the agent team still needs a documented escalation path because policy, authentication, and server availability can fail in different administrative domains.<\/p>\n Re-test MCP integrations when the server adds tools. Copilot Studio can expose newly available capabilities from the server, but policy and least-privilege assumptions should be reviewed before those capabilities become part of a production agent’s usable surface.<\/p>\n An environment can be subject to more than one tenant-level or environment-level data policy. Power Platform evaluates the applicable policies together, and a connector classified as Blocked by any applicable policy remains blocked even when another policy is more permissive.<\/p>\n This explains a common troubleshooting trap: reviewing only the policy a project team created can miss a stricter tenant policy applied by central administration. Diagnostic runbooks should identify every applicable policy before changing connector classifications.<\/p>\n Use separate environments intentionally. Development, test, and production can have different policy scopes, but the release process should surface those differences early so a deployment does not fail only after an agent reaches production.<\/p>\n Create an environment-level policy map for operators. Listing tenant policies, environment policies, advanced connector policies, and owning admin teams shortens incident diagnosis when an agent suddenly loses a dependency after a governance change.<\/p>\n Do not resolve every conflict by weakening the most restrictive policy. Sometimes the correct fix is to move the workload into an appropriately governed environment, replace a connector, split a process, or redesign the data flow so that the original security intent remains intact.<\/p>\n Keep policy names and owners visible in support documentation. When several controls combine, the effective denial may be correct even though no single project policy appears to explain it, so operators need a fast route to the administrators who own each applicable layer.<\/p>\n Microsoft has enforced Copilot Studio data policies across tenants since early 2025, and current troubleshooting guidance warns that misaligned policies can disrupt production agents. A newly blocked connector or default-group change can remove a dependency that the agent has used successfully for months.<\/p>\n Treat policy edits like production changes: inventory affected agents, test representative conversations, communicate expected impact, and keep a rollback path. Governance is strongest when it prevents unsafe flows without surprising the operations team that owns the business service.<\/p>\n Monitor policy-related failures separately from ordinary connector errors. A permissions failure, a service outage, and a data-policy denial can present similarly to the user but require completely different owners and remediation.<\/p>\n Use change windows and impact analysis for broad policy edits. A tenant-wide connector reclassification can affect many agents, apps, and flows simultaneously, so policy teams need dependency data and rollback procedures comparable to other shared platform changes.<\/p>\n After deployment, monitor both denied operations and unexpected reductions in agent success rate. Some policy effects surface as missing tools or unavailable knowledge rather than a clean ‘DLP denied’ message, and user reports may be the first signal unless telemetry connects those failures to governance state.<\/p>\n Include policy state in release evidence for important agents. Recording the effective connector classifications and required exceptions at deployment time gives operators a baseline when a later governance edit changes behavior, and it helps distinguish an application regression from an intentional policy change.<\/p>\n A connector being allowed does not mean every user or agent should be authorized to use every operation behind it. zero-trust identity architecture<\/a> still determines who can act after a data policy permits the connection path, because identity, least privilege, conditional access, and backend authorization remain separate enforcement layers. Likewise, a strong identity design does not replace data classification. A fully authenticated agent can still move sensitive information into a connector combination that the organization intentionally forbids.<\/p>\n Review the two layers together during threat modeling. The data policy constrains connectivity and data movement, while identity and resource permissions constrain the actor and operation inside the allowed path.<\/p>\nClassic policies separate Business, Non-Business, and Blocked connectors<\/h3>\n
Copilot Studio adds agent-specific policy surfaces<\/h3>\n
MCP servers do not bypass Power Platform governance<\/h3>\n
Multiple applicable policies combine into the effective restriction<\/h3>\n
Policy changes can create real production outages<\/h3>\n
Identity policy and data policy solve different parts of trust<\/h3>\n
Design for the policy model you will operate, not just the one you inherited<\/h3>\n