This is the complete Copilot Studio governance reference for Power Platform admins and CoE teams. It covers monitoring, restrictions, maker management, and common governance scenarios, with direct links to the controls that matter and the official resources that are actually useful.

The official documentation covers the basics, but it’s fragmented across multiple pages, sometimes inconsistently maintained, and leaves too many operational questions unanswered. This article fills those gaps.

The focus is Copilot Studio standalone agents. Some aspects of M365 Copilot are referenced where the two overlap, but this is not a M365 Copilot governance guide.

Hidden Gems in Official Documentation

A few resources stand out as genuinely useful for admins, and are consistently overlooked:

• Agent Governance Whitepaper: overview of the governance tools available for both M365 Copilot and Copilot Studio. It includes a high level description of the main relevant services in Purview.
• Copilot Studio Implementation Guide: probably the most comprehensive (and maintained!) official guide. More than 160 slides, covering multiple topics including architecture, AI capabilities, integrations, licensing, security, and many more.
• Microsoft CAT AI Webinars: webinar series dedicated to AI Agents. It covers various topics, with a fairly high coverage for Security (Agent 365, Purview, MAC, etc.).
• Copilot Studio Reference Architecture: less about governance and a lot more about architecture, it is still a valuable source of information for CoEs & Admins.
• Copilot Studio Licensing Guide: comprehensive licensing guide dedicated to Copilot Studio.

Understanding Copilot Studio Licensing

Governing Copilot Studio agents starts with understanding how licensing works, because the model you choose directly affects what you can control and what you can monitor.

The current model is built around two approaches: user licenses (M365 Copilot) and Copilot Credits, the latter available as either prepaid capacity or pay-as-you-go. Each has different cost profiles, governance implications, and limitations that are not always well documented.

A few things worth knowing before you commit to a model:

• No bulletproof way exists to enforce hard consumption limits at scale
• Pay-as-you-go cannot be used without the Dataverse meter
• Consumption monitoring options have recently improved in PPAC, but automation to report on consumption gaps remain.

For a full breakdown of the options, decision criteria, and monitoring approach, see Understanding Copilot Studio Licensing.

Sharing and Deploying Agents

Sharing and deploying agents involves more moving parts than the official documentation suggests, particularly around permissions, channel-specific behaviors, and what happens without admin intervention.

A few things worth knowing before you go further:

• Editor access requires the Environment Maker role at the moment of sharing, an overper-missive constraint
• Viewer permissions are not universal, they do not apply to SharePoint or unauthenticated channels
• Teams deployment offers two very different governance profiles: the shared link method requires no admin action and leaves limited visibility, while the admin-approved app method provides full control but introduces a manifest lifecycle that must be actively managed
• SharePoint deployment is controlled entirely by site permissions, with licensing requirements that do not yet fully match what the official documentation states

For a full breakdown of editor access, viewer permissions, and channel-specific deployment behaviors, see Sharing and Deploying Copilot Studio Agents.

Monitor Existing Agents

Being able to monitor existing agents is a core aspect of Copilot Studio governance, since you cannot govern what you cannot see. This section covers the way to monitor what agents are configured to do, how much they are used, and what users are doing with them at runtime.

Monitor Agent Configuration

Understanding what agents exist in your tenant, and how each one is configured, is the starting point for any governance practice. This means more than knowing an agent exists: it includes knowing what knowledge sources it uses, what actions and tools it has access to, what AI settings are enabled, and more.

Several inventories and tools exist out of the box, such as the PPAC Inventory, the MAC Agent Registry, Agent 365 and the CoE Starter Kit. But none provides a comprehensive configuration view today. Key governance questions remain unanswerable with these tools alone: which agents use Computer Use capabilities? Which can operate anonymously? Which agents are connected to a given connector or external service?

To address this gap, I built the Copilot Studio Monitor, a free CoE Kit extension that surfaces detailed agent configuration data directly from Dataverse and reports on it with a Power BI template. For a full walkthrough of the current gaps and how the Copilot Studio Monitor fills them, see Better Govern Agents with the Copilot Studio Monitor.

Monitor Agent Consumption

Makers can review analytics for their own agents directly in Copilot Studio. As an admin, you need a tenant-level view with the ability to drill down by environment or agent, and that requires a different approach.

PPAC provides downloadable consumption reports covering agent usage credit consumption. These reports are useful, but the process is entirely manual: there is no built-in scheduled export or automated delivery.

Until recently, an undocumented API made it possible to export these reports programmatically. My PPAC Reports Extractor relied on this API to automate the export and feed a Power BI template. That API is currently unreachable, which breaks the extractor. This also impacts the Copilot Studio Kit, of which some features depend on the same endpoint.

For a full breakdown of what consumption monitoring covers and how it fits into the broader licensing model, see Understanding Copilot Studio Licensing.

Monitor Agent Usage at Runtime

Knowing what agents are configured to do is one thing. Knowing what users are actually saying to those agents, what data they are accessing, and whether anything risky is happening at runtime is a different problem that requires a different set of tools.

Two distinct monitoring problems exist here:

• Compliance and security monitoring: what was said, was sensitive data shared, is anyone doing something risky? This is Purview territory
• Operational monitoring: is the agent working as expected, what topics triggered, how much credits are being consumed, where do conversations fail? We have Dataverse transcripts, consumption reports, and Application Insights for that.

These are different tools, different audiences, and different prerequisites. CoE teams typically own the operational side. The Purview tools are primarily owned by compliance and security teams, and none of them are accessible to the Power Platform Admin role. Each requires dedicated roles assigned in the Microsoft Purview portal or Entra (such as Compliance Administrator, Audit Manager, or tool-specific role groups like Insider Risk Management or Communication Compliance). CoE involvement is usually limited to awareness and coordination.

Tools	What it shows	Audience	Notable constraint
Purview Audit Logs	Agent lifecycle events and interaction metadata (no conversation text)	Compliance / security	M365 license required per user for interaction events to be logged; some channels excluded from logging
DSPM for AI	Actual prompt / response content, sensitive data accessed, AI risk reports	Compliance managers	Global Admin cannot read content; Purview PAYG required for non-Microsoft channels; data risk assessments for SharePoint / OneDrive only
Communication Compliance	Content violations in conversations (regulatory, conduct)	Compliance / legal	Purview PAYG required for Copilot Studio; Global Admin is config-only; cannot investigate alerts; only available for tenants whose primary region is in the Azure dependency supported list
Insider Risk Management	Behavioural patterns, prompt injection, suspicious data access	Security team	Global Admin is config-only; cannot investigate cases; only available for tenants whose primary region is in the Azure dependency supported list
eDiscovery	Legal holds and export of specific interactions	Legal / compliance	Plan-dependent entitlement (Standard vs Premium); explicit Purview eDiscovery role required; Copilot Studio export/review-set actions may incur Purview PAYG
Data Lifecycle Management	Retention policies for interaction data in Exchange Online	Compliance	Uses the ‘Microsoft Copilot Experiences’ policy location, not Teams; Purview PAYG required; separate from Dataverse transcript retention, both must be addressed separately
Microsoft Sentinel	Alerting and automated response on audit events	SOC teams	Requires deliberate setup in Azure
Advanced Hunting & Threat Detection in Defender	Agent inventory, MCP tools, orphaned agents, hardcoded credentials	Security analysts	Requires PPAC + Defender enablement; runtime protection needs Entra app registration
Dataverse Transcripts	Full conversation text per agent	CoE	30-day default retention; responses accessing SharePoint documents with sensitive data not included in transcript content
Application Insights	Per-agent operational telemetry (topics, latency, errors)	CoE / makers	No tenant-wide switch; per-agent config required; Azure subscription

For a full breakdown of each tool, including configuration steps, role requirements, and what each one can and cannot see, see Monitor Copilot Studio Agents at Runtime.

Restrict Copilot Studio Agents

Monitoring gives visibility. Restrictions give control. Knowing that an agent uses Computer Use capabilities is valuable, but it does not prevent the capability from being used in the first place. The tools in this section let you proactively limit what agents can do and what makers can configure, before something problematic reaches production.

Configure the Tenant for Copilot Studio

The Power Platform Admin Center exposes a small set of tenant-level switches that apply across all environments. For Copilot Studio, two are particularly relevant from a governance standpoint.

Publish Copilots with AI features

This setting blocks makers from publishing agents that use generative AI features. When turned off, agents can still be built and tested in Copilot Studio, but cannot be published. The restriction applies tenant-wide and cannot be overridden at environment level.

It is a blunt instrument: it applies to all new agents regardless of environment or audience. For organizations still assessing whether their generative AI use cases meet their security and compliance bar, it provides a clean way to prevent premature production deployment.

⚠️ When this setting is disabled, it does not impact agents already published.

Hosted browser in Computer Use

Computer Use is a capability that allows agents to operate a browser on a virtual machine. The hosted browser variant specifically uses a Microsoft-managed VM (Windows 365 for Agents) which isn’t Entra-joined, and therefore isn’t managed by Intune policies. Intended for experimentation and web automation tasks. Microsoft explicitly does not recommend it for production use.

The tenant-level toggle (“Hosted browser in computer use”) disables this specific variant across the entire tenant. A separate environment-level toggle (“Computer use”) disables the full Computer Use capability for a given environment, including both the hosted browser and any custom VM configurations. See Restrict Agents at Environment Level below for the environment-level controls.

---

Both tenant settings are accessible in PPAC. They are also manageable via PowerShell with the Get-TenantSettings and Set-TenantSettings cmdlets from the Microsoft.PowerApps.Administration.PowerShell module, which makes it possible to audit them in bulk and apply updates programmatically. See Export and Update Tenant Settings with PowerShell for ready-to-use scripts.

Restrict Agents at Environment Level

Environment-level controls are more granular than tenant switches: they apply to a specific environment or group of environments, and several can be delegated to Environment Admins rather than requiring tenant admin access. The tradeoff is that tenant admins cannot always enforce them over system administrators, and it where environment groups and the Settings Enforcer come in.

Several of the most useful controls in this section, such as sharing limits and environment group rules, require Managed Environments. For Copilot Studio specifically, enabling Managed Environments has no impact on credit consumption or licensing costs. The same Copilot Credits are consumed regardless of whether an environment is managed or not. The cost consideration that often blocks Managed Environment adoption elsewhere (since every app and flow becomes premium) does not apply to agent usage. The one caveat: if the same environment also hosts standard Canvas Apps, those apps would become premium. Keeping Copilot Studio agents in dedicated environments avoids the issue entirely.

Data Policies

Data policies (DLP) are the primary mechanism for restricting what agents can do at the environment level. For Copilot Studio, they cover:

• Authentication: block unauthenticated usage (Chat without Microsoft Entra ID authentication)
• Channels: block Direct Line, Facebook, Teams, or Omnichannel. Note: blocking the Direct Line channel may trigger a false DLP error warning in Copilot Studio even when the agent does not use it. This is a known issue and does not indicate an actual policy violation.
• Knowledge sources: restrict SharePoint/OneDrive, documents, or public websites; endpoint filtering is supported for the SharePoint and public website connectors
• Skills: block integration with Copilot Studio skills
• Application Insights: prevent makers from connecting agents to Application Insights
• Connectors: any connector blocked in the policy prevents its use in Cloud Flows called by agents
• Copilot Studio Connector: it allows to trigger agents autonomously
• Custom Connectors: Custom Connectors is what allow Makers to integrate with custom MCP servers and external agents. Blocking / Whitelisting appropriate endpoints for the custom connectors in a Data policies is the way to govern MCP servers and external agents in Copilot Studio.

One important update since 2024: DLP enforcement for Copilot Studio is now active by default for all tenants (announced via MC973179 in early 2025). The Set-PowerVirtualAgentsDlpEnforcement PowerShell command is no longer needed, and per-agent DLP exemptions are no longer supported. Any previously exempted agents are now subject to enforcement.

Policies can be scoped to a single environment, a set of environments, or tenant-wide. Tenant-wide policies take precedence and cannot be overridden at environment level.

For the full list of Copilot Studio DLP options and configuration steps, see Configure data policies for agents.

⚠️ Worth noting that most of these Copilot Studio connectors are “virtual connectors”, characterised by the fact that when a user uses the related features, it does not create a connection in the environment. This is a challenge to detect when these connectors are actually in use and to assess the impact prior to blocking one of them. The Copilot Studio Monitor can help with that since it shows all the features used by the agents in tenant.

Advanced Connector Policies

Advanced Connector Policies (ACP) look like the intended successor to classic DLP for connector governance, currently in preview. The model is meaningfully different:

• Allowlist instead of classification: when an ACP is in place, any connector not explicitly allowed is blocked. There is no business/non-business grouping.
• MCP server support: ACP can block the out of the box Model Context Protocol servers, some of which cannot be blocked via classic DLPs.
• Scoped to environment groups only: per-environment support is not yet available. ACP requires environments to be in an environment group with Managed Environments enabled. However they are announced to support individual and standard environments in the future.
• No endpoint filtering: endpoint filtering (supported in classic DLP for some connectors) is not available in ACP at the moment.

ACP is a promising feature which should help to better support Admins governing the platform. Still too early today to justify the migration from dlps, and the side-by-side approach does not work in practice.

For an in-depth comparison of ACP and classic DLP from a governance standpoint, see this great write up from Craig White.

Limit Agent Sharing

Sharing controls are a Managed Environments feature that restricts how agents can be distributed within an environment. Four rules are configurable:

Rule	Effect
Let people grant Editor permissions	Whether Makers can share agents with editors or only admins can grant editor access
Let people grant Viewer permissions	Whether Makers can share with viewers or security groups
Only share with individuals (no security groups)	Whether Viewers can only be individuals, not security groups
Limit number of viewers per agent	Cap on viewer count

A few constraints worth knowing:

• Viewer Sharing controls only apply to authenticated agents. Unauthenticated agents are unaffected.
• Rules apply at share time and do not revoke existing access retroactively, they only prevent new shares that would violate them.
• The Viewers Restriction rules do not apply to the SharePoint channel
• Configuration is available per Managed Environment or via environment group rules for bulk rollout.

I share more information about sharing and publishing agents and related limitations here.

Control Connection Credentials

When a maker adds a connector or Cloud Flow to an agent, they choose how it authenticates: using their own credentials (maker-provided) or the end user’s credentials. The default allows both options.

With maker-provided credentials, anyone using the agent silently operates under the maker’s account and permissions. This is the most common source of unintended data access in Copilot Studio agents. An end user retrieves data or triggers actions they wouldn’t have access to directly.

Admins can restrict this via Control maker credential options in PPAC (environment Settings > Product > Features), allowing only end-user credentials or both.

One side-effect to plan for before enforcing end-user-only: autonomous agents break. Any agent triggered by a schedule or an event without an active user session will fail, because every tool call must authenticate against a live user. All agent triggers must involve an active user when maker credentials are blocked.

The setting can be configured per environment or at environment group level. Group-level settings override individual environment settings.

See Control maker-provided credentials for authentication for configuration steps.

Transcript Recording and Visibility

Two independent toggles in PPAC (environment Settings > Product > Features > Copilot Studio agents) control transcript behaviour:

• Allow conversation transcripts and their associated metadata to be saved in Dataverse: when off, no new transcripts are persisted in Dataverse. Existing transcripts remain available. Note that transcripts can continue saving for up to 24 hours after the toggle is turned off.
• Allow agent owners and editors to see session transcripts: when off, makers cannot view or download transcripts in Copilot Studio. Only environment admins and users with the Bot Transcript Viewer security role retain access.

Both default to on.

One thing these toggles do not control: retention period. The default is 30 days, managed via a scheduled bulk delete job in Dataverse. Adjusting retention requires creating or modifying that job separately. See Control transcript access and retention.

Disable Computer Use at Environment Level

The Computer Use toggle in environment settings disables the full Computer Use capability for that environment, both the hosted browser variant and any custom VM configurations. This is a broader control than the tenant-level hosted browser toggle covered above, which only disables the hosted browser.

The toggle is in PPAC under environment Settings > Product > Features.

When Computer Use is enabled, additional settings control log verbosity (all data, without screenshots, or minimal) and log retention period. Logs are stored in Dataverse by default and consume database, log, and file capacity.

Disable AI Prompts

A separate environment toggle controls whether AI Prompts are available to makers on that environment. When disabled, makers cannot create prompts in the environment, and therefore cannot leverage them form an Agent. This setting is accessible in PPAC under environment Settings > Product > Features.

Global Secure Access

Preview: This feature is currently in preview and not recommended for production use.

When a Copilot Studio agent makes outbound calls to a connector, a custom MCP server or an HTTP action, that traffic bypasses the network security controls your organization applies to users. A user browsing the web goes through your proxy policies, content filtering, and threat intelligence checks. An agent making the same request does not, by default.

Global Secure Access (GSA) for agents closes that gap. It lets you forward agent outbound traffic through GSA’s globally distributed proxy service, where the same security policies applied to users can be evaluated against agent requests in real time. If a request violates a configured policy, GSA blocks it and logs the event.

What GSA Controls Enable

Once traffic forwarding is enabled, you can apply the following through the GSA baseline profile in the Microsoft Entra admin center:

• Web content filtering: block access to URL categories (web repositories, NSFW, illegal software, etc.)
• Threat intelligence filtering: block known malicious destinations
• Network file filtering: control file uploads and downloads inline

Policies must be linked to the baseline profile, not to a Conditional Access policy. This means enforcement is at the tenant level, not per-user or per-group. There is currently no way to scope GSA agent policies more narrowly than the full tenant.

Configuration

Enabling GSA for agents is a two-step process spanning two admin portals:

1. Entra admin center: ensure your tenant is onboarded to Global Secure Access and assign the Global Secure Access Administrator role to whoever will manage policies.
2. PPAC: enable the Global Secure Access for Agents toggle under Security > Identity & access, per environment or per environment group. Environment group configuration is available for Managed Environments.

Once enabled, all new custom connectors in that environment automatically route through GSA. Existing custom connectors require a manual edit-and-save to pick up the forwarding configuration.

Security policies are created and linked in the Entra admin center. Changes to web content filtering policies typically take effect within five minutes.

Known Limitations

Several traffic types are explicitly excluded from GSA enforcement in the current preview, which limits its usefulness for some governance scenarios:

• Bing search traffic (public website knowledge, Wikipedia) is not supported
• LLM traffic (orchestration, generative answers) is not routed through GSA
• Dataverse and Azure SQL knowledge source requests are not supported
• Third-party DLP integrations via the GSA partner ecosystem are not supported
• Connector support is partial: only a specific list of connectors is supported; others may not function reliably when GSA is enabled

The block experience also has a known rough edge: blocked HTTP actions return a 502 Bad Gateway, and blocked connectors return a 403 Forbidden, which provides limited context to makers or end users.

For the full configuration walkthrough and supported connector list, see Configure Global Secure Access, the Secure Web, and AI Gateway for agents.

Manage Settings at Scale

Several settings in this section are configurable via environment group rules, which push them consistently across all environments in a group without touching each one individually. This currently covers transcript settings, sharing controls, and connection credential controls.

Not all settings are covered through groups, and groups are only supported for Managed Environments. For the rest, I created the Settings Enforcer to fill the gap. It writes the Dataverse organization table (where most environment settings are stored) through policies across environments and supports scheduled enforcement, so that any changes made locally by environment admins are automatically reverted to the tenant-defined value.

Manage Copilot Studio Makers

Controlling who can create agents requires layering two things: tenant-level access (licenses and the Author group) and environment-level access (security roles). Neither alone is sufficient.

Control Who Can Access Copilot Studio

A user can access Copilot Studio if any one of the following is true:

• They hold a Microsoft 365 Copilot license
• They hold a Copilot Studio User license: a free per-user license, provisioned automatically when Copilot Credits (prepaid capacity) are purchased for the tenant
• They are a member of the security group assigned to the Copilot Studio Authors tenant setting in PPAC, which grants access under a pay-as-you-go model
• They signed up via a viral trial (if self-service sign-up is enabled in the tenant)

The Copilot Studio Authors setting (PPAC > Manage > Tenant settings) is often misunderstood: assigning a security group does not revoke access from users outside it. A user outside the group can still access Copilot Studio if they hold a Copilot Studio User license or an M365 Copilot license. The setting only adds an access path, it does not replace the license-based paths.

To fully block a user from accessing Copilot Studio, all three conditions must be true simultaneously:

1. The user is not in the Author group
2. The user has no Copilot Studio User license and self-service signup is disabled
3. The user has no Microsoft 365 Copilot license

This also means that if Copilot Credits are purchased and provisioned, the Copilot Studio User license is automatically available in the tenant. Admins should review who gets this license assigned, or restrict assignment proactively before purchase to avoid unintentionally broadening access.

To prevent users from acquiring access via trial, disable self-service sign-up via the AllowAdHocSubscriptions flag in Entra. See Block Copilot Studio sign-ups for the steps. Note that trial licenses allow creating and testing agents, but not publishing them.

For the full licensing breakdown, see Understanding Copilot Studio Licensing.

Control Through Security Roles in Environments

Having tenant-level access is not enough to create agents: users also need the appropriate security role on the target environment.

The Environment Maker role is the standard role for makers. It grants CRUD permissions on the botsand botcomponents Dataverse tables scoped to user-owned records. One constraint worth planning for: the Environment Maker role is also required for a user who an agent is shared with as editor. See Sharing and Deploying Copilot Studio Agents for the implications. Another constraint is that this role is automatically assigned to all users in the default environment. See the common scenarios section below for recommendations on how to control the default environment despite this fact.

A best practice is to assign security roles via Entra ID group teams rather than individual user assignments, which makes bulk management and audit significantly more tractable at scale.

Purview Restrictions

The Purview tools covered in the monitoring section are primarily detection tools. Two of them can also actively restrict what data flows through agents.

Sensitivity labels with encryption prevent agents from processing labeled files when the label applies encryption. The user must have both the EXTRACT and VIEW usage rights; without them, the encrypted content is excluded from responses. Sensitivity labels are supported for the SharePoint (including OneDrive) and Dataverse knowledge sources, but encryption enforcement applies only to the SharePoint knowledge source.

Purview DLP policies can block agents from processing prompts or returning responses when specific sensitive information types or sensitivity labels are matched. When a DLP block fires, the agent returns no response to the user and the prompt is not used in any internal or external search. Policies are scoped using the Microsoft 365 Copilot location in Purview DLP and apply across supported channels.

All other Purview tools, such as Communication Compliance, Insider Risk Management, eDiscovery and audit, are detection only. They identify and surface risky activity but do not prevent it in real time.

For configuration steps, role requirements, and a breakdown of what each tool can and cannot see, see Monitor Copilot Studio Agents at Runtime.

Delete Agents as Admin

Until recently, there was no clean supported path for admins to delete Copilot Studio agents programmatically. The only viable workaround involved the internal Dataverse Web API (PvaDeleteBot with the deprovisionbotondelete tag), which handled the Azure app registration cleanup but was explicitly documented as “for internal use only”. Using it required provisioning an Application User with a System Administrator role on each target environment and was therefore a significant operational overhead at scale. I documented that approach in Delete Copilot Studio Bots as Admin along with a solution to automate the App User lifecycle.

Thankfully, that workaround is now obsolete. Agent deletion is supported through two official paths:

• Power Platform API: DELETE https://api.powerplatform.com/copilotstudio/environments/{EnvironmentId}/bots/{BotId}/api/botAdminOperations?api-version=1. Returns 204 on success. Requires a Global Tenant Admin, AI Administrator, or Power Platform Administrator role, and an app registration with the CopilotStudio.AdminActions.Invoke scope. See Delete agents programmatically with the Power Platform API.
• Power Platform for Admins V2 connector: exposes a Delete a bot in Copilot Studio action (DeleteCopilotAgent) that wraps the same API, making it usable directly in Power Automate flows without writing raw HTTP calls.

Both paths delete the agent and its associated Azure app registration. Admins with governance flows for apps and flows can extend those same patterns to agents using the connector action.

Common Governance Scenarios

The controls in this article rarely map to a single decision. What follows are common governance situations and the tools to reach for.

Block Copilot Studio Access Entirely

Three independent access paths exist, and all three must be closed simultaneously:

1. Ensure no one in scope holds a Microsoft 365 Copilot license or a Copilot Studio User license. The latter is automatically available when Copilot Credits are purchased, and may already be assigned more broadly than intended.
2. Disable self-service sign-up via the AllowAdHocSubscriptions flag in Entra. Trial licenses allow creating and testing agents (but not publishing).
3. The Copilot Studio Authors setting in PPAC is not configured or point to an empty security group. This group only adds an access path; it does not block users who hold a license through other means.

See Control Who Can Access Copilot Studio for the full breakdown.

Control the Default Environment

Every user has the Environment Maker role in the Default Environment by default. It cannot be deleted. Four approaches proposed below:

Option 1: Minimize who can create in it

Tightly control Copilot Studio User license assignment, disable self-service sign-up, and restrict the Copilot Studio Authors group. Role-based environment access controls alone are not a reliable way to hard-block creation in the Default Environment.

Option 2: Restrict what can be built

Apply tight data policies (block unauthenticated usage, restrict knowledge sources, block channels beyond Teams) and prevent publishing via the “Publish Copilots with AI features” tenant toggle. Makers can experiment, but the blast radius is contained.

Option 3: Accept it as a sandbox

Convert to a Managed Environment with its costs implications, apply strict sharing controls, and run automated cleanup of inactive or orphaned agents via the Delete Agents as Admin capabilities.

Option 4: Redirect to a dedicated sandbox

Combine Options 2 and 3: create a Managed Environment as a sandbox (e.g. “Personal Agents Environment”) with restricted connectors and sharing. Automatically detect and delete new agents in the Default Environment, then route makers to the sandbox via an automated email or Teams Adaptive Card. This enforces an onboarding process before makers can create agents, giving you the opportunity to share guidelines and training. A separate process can handle promotion to a shared environment when an agent is ready to be published.

---

Option 2 is a reasonable starting point, but it does not solve the sharing problem: every user in the Default Environment holds the Environment Maker role, which means any maker can share their agent with the entire organization. Data policies restrict what an agent can do, but not who can use it. If broad sharing is a concern, Option 4 is the stronger choice. It contains creation to a dedicated sandbox where sharing controls (Managed Environments) can be enforced, and uses automated cleanup in the Default Environment to prevent agents from accumulating there unmanaged.

For non-default environments, the control is simpler: restrict who holds the Environment Maker role to restrict creation and leverage Managed Environments to restrict sharing.

Reduce Runtime Usage Risk

Runtime risk spans four classes: data exposure, privilege misuse, autonomous execution abuse, and unsafe outbound traffic.

Data exposure:

• Sensitivity labels with encryption prevent agents from extracting content unless the user has both EXTRACT and VIEW rights.
• Purview DLP policies block responses when sensitive information types are matched in prompts or responses.
• Scoped knowledge sources limit retrieval to specific sites or libraries. Admins can enforce this through DLP endpoint filtering on the SharePoint knowledge source connector.

Auditing SharePoint permissions for sites used as knowledge sources is the single most impactful step most organizations can take here. Copilot Studio respects SharePoint permissions for authenticated agents.

Privilege and execution risk:

• Control maker credential options: rationalize the option to use maker credentials to prevent users from silently operating under a maker’s permissions. This breaks autonomous execution since each tool call requires a live user identity.
• Rationalize autonomy: clearly define when the Microsoft Copilot Studio connector should be enabled in data policies.
• Restrict outbound paths: block or endpoint-filter HTTP and custom connector usage where MCP servers and external agents are not approved.

Network-level controls: Global Secure Access for agents (preview) applies web filtering and threat intelligence to supported outbound traffic. Treat it as defense-in-depth: Bing search, LLM orchestration, and Dataverse/Azure SQL traffic are currently excluded.

Investigation: Align with compliance team to get copilot studio interactions reviewed and monitor through Purview.

Enable Copilot Studio while Blocking Autonomous Agents

Block the Microsoft Copilot Studio connector via a data policy. Agents can still be built and used interactively via Teams, SharePoint, or the web channel; only the autonomous trigger path is blocked.

Control MCP Servers and External Agent Integration

Makers can point an agent at an arbitrary external endpoint via custom connectors, with no default restriction. The governance mechanism is connector endpoint filtering in data policies:

1. Block all custom connector endpoints by default in the data policy. No custom MCP servers or external agent integrations without explicit approval.
2. Add endpoint allowlist entries for vetted services. Classic DLP endpoint filtering supports URL patterns.
3. Review Advanced Connector Policies (ACP) as they mature: ACP can block out-of-the-box MCP servers that classic DLP cannot target. Still in preview. See Advanced Connector Policies.

If you have an existing connector review process for Power Automate, extending it to cover MCP servers is a natural next step.

Recommendations

Three things consistently make the difference between organizations that govern Copilot Studio well and those that are perpetually catching up.

Use Managed Environments for Copilot Studio

Most of the controls in this article either require Managed Environments or work significantly better with them: sharing limits, environment group rules, the Settings Enforcer, Global Secure Access scoping. The governance surface without Managed Environments is materially smaller.

The common objection is cost. For Copilot Studio, it does not apply. Enabling Managed Environments has no impact on credit consumption or licensing, the same credits are consumed regardless. The one scenario where it matters: if the same environment also hosts standard Canvas Apps or classic cloud flows, those apps and flows become premium. The fix is straightforward, keep Copilot Studio agents in dedicated environments, separate from general Power Apps development.

If your organization is not using Managed Environments for Copilot Studio today, there is no real cost argument against it. The governance argument for it is strong.

Bring Your Data Governance and Compliance Team In Early

The Purview tools covered in this article such as DSPM, Communication Compliance and Insider Risk Management, are not Power Platform admin tools. They are owned by compliance and security teams, require dedicated Purview roles, and none of them are accessible to the Power Platform Admin role. A CoE that discovers Copilot Studio agents are processing sensitive data without those teams already onboarded is in a difficult position.

The conversation to have early is straightforward: here are the tools available, here is what each one can see, here is what they require to set up. The compliance team may not need to act immediately, but they need to know the surface exists. The alternative, waiting until something surfaces a risk, makes every subsequent conversation harder.

Treat Agent Governance as a Cross-Functional Effort

Copilot Studio governance touches more teams than Power Platform governance typically does: network security (GSA), identity (Entra, conditional access), compliance (Purview), and AI governance functions that may not have existed two years ago. The tools are spread across PPAC, Purview, Entra, Azure, and the Microsoft Admin Center.

No single team has full visibility or full control. A CoE that tries to own all of it will hit walls. The more productive framing is to map which tools belong to which team, establish shared awareness of what each team can and cannot see, and define escalation paths when something crosses boundaries. The governance model needs to match the actual ownership of the tooling, not the other way around.

What Comes Next

The governance gaps described in this article are the gaps of March 2026. They won’t be the same six months from now. The Copilot Studio and Power Platform teams ship improvements at a pace that makes any static reference like this one a snapshot, not a permanent map.

With the rise of Agent 365 and the broader push toward autonomous agent scenarios, several sections in this article will need revisiting later this year. Runtime monitoring, Purview integration, and Advanced Connector Policies are all areas where significant changes are already in preview or announced. The governance surface is expanding, and the tooling is catching up.

Use what’s here to build your baseline today. Revisit it when the landscape shifts. I’ll update this article as those changes land.