Copilot Studio governance in 2024 starts with who can build copilots

Since Power Virtual Agents was renamed late last year, I've watched Copilot Studio show up almost overnight in a lot of tenants. Sometimes that was planned. More often it wasn't. Many admins notice new Copilot objects accumulating in the Power Platform Admin Center, but the implications usually only sink in once someone builds a Copilot on sensitive internal data and publishes it straight to Teams. My experience is simple: organizations that skip Copilot Studio governance end up with real problems around data and control. And what trips people up is rarely a big technical gap. It's the licensing and configuration details that look minor until they aren't.

Licensing and trial settings decide who can build copilots

Out of the box, anyone with a Microsoft 365 license can try Copilot Studio. A single click on “create Copilot” is often all it takes to start a trial license. That applies in particular to the global Default Environment, which has very few restrictions by default. Copilot Studio does need its own license (or a Power Virtual Agents license), but the trial process makes it easy for new creators to get going anyway. If you want to stop the sprawl, you have to do something about it. In the Power Platform Admin Center you can disable self-service trial licensing and limit Copilot Studio creation to selected users or groups. As of June 2024 there is still no granular control by feature set, although managed environments (more on those below) let you restrict quite well who can build and publish copilots.

Practical tip: If you want to keep Copilot Studio out of your tenant, disabling the app isn't enough. Use the Power Platform environment controls too and check license assignments regularly, or one click can lead to a jump in shadow IT.

The Default Environment works against you

In most tenants I've looked at, the Power Platform Default Environment is where experiments, shadow IT and untraceable apps go to pile up. For Copilot Studio that's a real risk, because unless you intervene, every user can simply start building copilots there, and dedicated environments rarely exist by default. I always recommend a dedicated environment for every production Copilot, configured as a "Managed Environment". That gives you far more control over data, connectors and lifecycle. Microsoft's official overview of managed environments is a good reference.

The diagram below shows a recommended Copilot Studio governance process using dedicated, managed environments. Pay attention to how control and risk shift along the way:

flowchart TD
    User["User"] --> EnvSelect["Choose environment"]
    EnvSelect --> DefaultEnv["Default Environment"]
    EnvSelect --> DedicatedEnv["Dedicated environment"]
    DedicatedEnv --> ManagedEnv["Managed Environment"]
    ManagedEnv --> Control["Governance & DLP controls"]
    Control --> BuildCopilot["Build Copilot"]
    DefaultEnv --> Risk["Less control, high risk"]
    BuildCopilot --> Publish["Publish"]

Figure: Copilot Studio governance process – Default vs. dedicated managed environments.

In practice, organizations that run Copilot Studio in dedicated, managed environments get far fewer surprises with permissions and connectors. Keeping track of inventory and lifecycle is also a lot easier for them.

Power Platform DLP carries much of the Copilot Studio governance load

The Power Platform Data Loss Prevention (DLP) policy system is one of the most effective tools you have for Copilot Studio governance. As soon as a Copilot uses internal data sources or HTTP requests, or gets published to external channels (Teams, websites and so on), sensitive data can leak. DLP policies let you decide per environment which connectors (authentication, knowledge sources, HTTP, etc.) a Copilot may combine. Microsoft's documentation on Copilot Studio and DLP explains this clearly.

These are the problems I run into most often in workshops and tenant reviews:

• Copilots pulling from knowledge sources (SharePoint, websites) that contain sensitive content and then answering in public channels
• HTTP connectors sending data to third parties without anyone noticing
• DLP policies that are too permissive and allow risky combinations

For production Copilots, set DLP rules that block dangerous connector combinations, above all HTTP requests and knowledge source access. Managed environments enforce DLP as a requirement, which helps a lot.

A minimal DLP config example:

{
  "Environment": "Copilot-Prod",
  "BlockedConnectors": ["HTTP", "Custom"],
  "AllowedConnectors": ["SharePoint", "Teams", "Outlook"]
}

Auditing still leaves gaps that data can slip through

DLP doesn't remove every risk. Someone can still configure a Copilot so that information leaks through knowledge sources and publishing channels. That's why sources and channels need tight control and a regular review. I usually suggest automating the inventory of Copilot objects through the Power Platform Admin Center and going through the audit logs in Microsoft Purview on a regular basis. Copilot Studio now writes dedicated audit events for knowledge source changes, publishing and channel updates, provided you've enabled Purview audit logs.

If you're taking Copilot Studio into production, test your Purview auditing setup before you roll out critical copilots. The right queries are often missing, and the volume of events can swamp you if you're not prepared.

Keep in mind that Purview audit search uses filter fields, not KQL. The fastest way to get an overview is the Microsoft Purview portal → Audit → Search: set the date range, choose the Copilot Studio activities in the "Activities – friendly names" field and export the results to CSV if you need them. The activities Copilot Studio records are listed in Microsoft's documentation on Copilot Studio audit logging.

Copilot extensions keep raising the bar for governance strategy

New plugin and Copilot extension capabilities are rolling out, and they make governance harder, not easier. Managed environments help you keep extensions under control, but your governance strategy has to keep up. I cover the technical side of Copilot extensions and current governance practice in my post Copilot extensions and governance – Build 2024 insights.

Copilot Studio governance isn't something you finish. It's an ongoing process that has to balance technology, compliance and what users actually need. If you sort things out now, you'll save yourself a lot of trouble later and can use what Copilot Studio offers without the risk.