Securing Microsoft Copilot Studio Agents: Connector Governance and DLP Before Data Sprawl

Copilot Studio is designed to remove friction between an idea and a working agent. A business user in finance, HR, or operations can open the maker portal, describe what they want, point the agent at a SharePoint site or a Dataverse table as a knowledge source, add a connector as a tool, and publish, all without filing a ticket with IT. That is the product's selling point and its governance risk in the same sentence. Every agent that gets built this way is a new data path: a new consumer of whatever SharePoint site, Dataverse table, or line-of-business system the maker pointed it at, potentially exposed through a channel (Teams, a public Direct Line website, WhatsApp) that the maker chose without input from whoever owns that data source's access model.

The sprawl risk is specific to Copilot Studio, not the core M365 Copilot experience. M365 Copilot answers questions using data a user already has SharePoint or OneDrive permission to see; the fix there is permission hygiene and oversharing remediation on the existing content estate. Copilot Studio creates the connection itself. A maker can build an agent today that reads from a Dataverse table containing customer PII and writes results to an external HTTP endpoint, entirely inside the low-code canvas, and if no data policy blocks that specific connector pairing, the agent maker sees no warning and the Publish button simply works. Multiply that by every maker in the tenant building agents in parallel, and the governance question stops being about any single agent and becomes about the connector policy that applies before the first one gets built.

Confirm these before making any changes, in this order.

Role and access: you need to be a tenant admin, or hold the Environment Admin role for the environments you intend to govern, to configure data policies in the Power Platform admin center. Neither Copilot Studio maker access nor a Microsoft 365 admin role alone is sufficient for this specific configuration.

Inventory: pull a list of existing Copilot Studio environments and agents before writing any policy. Microsoft's own recommendation for this is the Center of Excellence (CoE) Starter Kit's Power BI dashboard, which lists agents and environments across the tenant; note that classic chatbots built through the legacy Copilot Studio app in Microsoft Teams do not appear there; a Power Automate flow using the List rows from selected environment Dataverse action is Microsoft's documented workaround for that gap.

Decide your default posture up front: whether new connectors that arrive with no explicit classification should default to blocked (safer, more maker friction) or allowed (faster maker onboarding, wider exposure window). Microsoft's platform default already leans toward caution here: connectors introduced after 2019, which includes several Copilot Studio-specific connectors, are placed in the Non-business data group by default, and many organizations configure their data policies to auto-block that entire group. Know which posture your tenant is actually running before you assume either one.

Understand that agent creation itself is not the lever you can pull. Per Microsoft's published security FAQ, agent creation in Copilot Studio cannot be disabled tenant-wide. The two levers that do exist are making custom agent publishing available or unavailable at the tenant level, and using data policies to block a given agent from being chatted with or from using specific connectors. Plan your governance model around those two levers, not around blocking creation.

Run these steps in the Power Platform admin center, in this order, before agents are broadly in use. Each step maps to a distinct, documented Copilot Studio control.

A saved data policy is not the same thing as an enforced one. Validate each control directly in Copilot Studio, not just in the admin center's policy list. For authentication, open an agent that was not built to require sign-in in an environment covered by the new policy; the Channels page should show an error banner with a Details button, and No authentication should no longer appear as a selectable option on that agent's authentication settings. For a blocked knowledge source, add the specific knowledge source type your policy blocks to a test agent and attempt to publish; a violation should appear per knowledge source and per generative-answers node that references it. For a blocked connector-as-tool, add a Tool node backed by a blocked connector and attempt to publish; the same error-banner and downloadable-details pattern should appear. In every case, the practical tell that enforcement is live is that the Publish button itself becomes unavailable until the violation is resolved, not merely a warning the maker can dismiss. If a maker reports being blocked, the downloaded details file names the specific data policy and the specific violation, which is also the fastest way to distinguish a genuine policy conflict from a maker simply hitting an unrelated error.

A handful of behaviors catch teams off guard during rollout, worth knowing about ahead of time rather than discovering during an incident review.

Every control in this procedure trades maker velocity or convenience for a narrower attack surface, and that tradeoff is worth stating plainly rather than presenting the whole procedure as free.

Blocking maker-provided credentials tenant-wide is the single highest-leverage control here for preventing an agent from overexposing data, because it forces every end user's access through their own actual permissions instead of the maker's. The direct cost is that any agent legitimately designed to act with elevated, maker-level access on behalf of users who should not individually have that access, a genuine and sometimes valid design pattern, stops working until it is explicitly reconfigured or exempted. Turn this on by default and grant exceptions deliberately, rather than leaving it off broadly to avoid the conversation.

Defaulting new or unclassified connectors to Blocked, and requiring an explicit request to move a connector to Business, is the safer posture, but it directly slows down makers who want to prototype with a connector nobody has classified yet. The alternative, defaulting to Business or leaving new connectors in whatever the platform assigned automatically, moves faster but means a connector nobody reviewed can already be in active use as a tool before anyone in security notices.

Endpoint filtering versus wholesale connector blocking is a precision-versus-effort tradeoff, not just a security one: endpoint filtering requires someone to maintain an actual allow or deny list of sites and domains over time, which is real ongoing work, whereas blocking a connector outright is a one-time decision that then generates recurring maker friction instead of recurring admin maintenance. Neither is free; the question is which kind of ongoing cost your team is better resourced to carry.

Finally, tenant-wide data policy scope is the right default for a connector-classification baseline specifically because it auto-applies to environments that do not exist yet, closing the gap where a brand-new environment temporarily has no policy at all. The cost is that a legitimate, narrow exception for one team now has to be modeled as an explicit exclusion or a separate environment-scoped policy, adding a small amount of ongoing policy-management overhead in exchange for never having an ungoverned environment by default.