In more and more of the tenants I work with, Copilot Studio agents are showing up in one department after another. Some of them deliver real business value. Governance and security, though, are usually still catching up. I get asked about Copilot Studio agent sharing all the time. Who is allowed to share with whom, and through which channels? How do you stop an agent from being shared with the entire organization by accident, or even with external users? And which technical settings actually keep this under control?

Managed Environments put real sharing limits on agents

Managed Environments in Power Platform have been used for a while to keep Power Apps and flows from sprawling. As of mid-2025, their sharing limits also fully apply to Copilot Studio agents. In the Power Platform admin center (Environments → [your environment] → Edit Managed Environments → Limit sharing), you can now define how Copilot Studio agents may be shared: only with selected security groups, with no external users, or by invitation only. These boundaries matter a lot in practice, particularly once business users start building their own agents. There is one catch. The limits only work in environments marked as managed, and only for agents created in those environments. The detailed options are in Microsoft's documentation on sharing limits.

Even so, what's configured and what actually happens often don't match. Agents get built in unmanaged environments and shared widely, simply because their creators don't know the limits aren't in effect everywhere. That's why I review the agent inventory in the Power Platform admin center (Environments → [environment] → Copilot Studio → Agents) on a regular basis. It's the only way to see which agents exist in which environment and how far they've been shared.

Pro tip: In environments with broad usage, make security groups the only allowed sharing target. You can then manage access centrally in Entra ID and pull it back quickly when you have to.

Security groups and ownership define the sharing boundary

When you assign security groups to environments, you control not only who can use Copilot Studio agents but also who can share them. I usually recommend one group per team or department, and only members of that group may share agents in their environment. That way a single enthusiastic user can't accidentally share an agent with the whole organization or with outsiders. One lesson I learned along the way: IT should manage group membership, not the agent creators. Otherwise the governance model falls apart quickly.

Ownership gets far less attention than it deserves. What happens when the person who built the agent leaves the company? The agent inventory in the admin center shows the owner of every agent, and you can reassign ownership manually. As of July 2025 there is no automatic process for this, so you have to review it regularly. In the worst case, Power Platform or Entra admins can change the owner, but this step belongs in your standard offboarding process.

Authentication settings decide who can use the agent

The authentication setting on each agent is a central part of Copilot Studio agent sharing. You can require users to sign in with Microsoft (Entra ID), set up manual authentication, or use no authentication at all. Never skip authentication for anything beyond a basic prototype. If you publish an agent on the website channel without authentication, anyone can reach it, search engines included. My recommendation is to always use "Authenticate with Microsoft" for any agent that touches data or business functions. Microsoft's guide to end-user authentication walks through the steps.

Each publishing channel carries its own risks

You can now publish Copilot Studio agents through several channels: Microsoft Teams, the Microsoft 365 Copilot app (formerly the Microsoft 365 app), or a website chat embedded in intranet pages. Every channel has its own access model. Teams normally limits access to the organization or to specific security groups. The website channel, on the other hand, can make an agent public, especially when authentication isn't required or enforced. The admin center shows where each agent is published and lets you manage it, and Microsoft has an official overview of publishing channels.

Before any larger rollout, I go through the channel and authentication settings carefully. I find it useful to see how the pieces relate to each other, so here is a diagram of the main components:

flowchart TD
    agents["Agent creator"] --> environment["Managed environment"]
    environment --> group["Security group"]
    environment --> sharinglimit["Sharing limit"]
    agents --> authentication["Agent authentication"]
    authentication --> channel["Publishing channel"]
    channel --> teams["Teams/M365 app"]
    channel --> website["Website"]

Figure: How the managed environment, security group, sharing limit, authentication and publishing channel fit together for Copilot Studio agents.

DLP policies complete the governance picture

If Copilot Studio agent sharing matters to you, Power Platform data loss prevention (DLP) policies have to matter too. Regardless of who can share with whom, DLP determines which connectors an agent is actually allowed to use. That's an important safeguard, particularly where sensitive data is involved. I've written about practical DLP controls in Copilot Studio DLP: Controlling agents and data flows, and I summarized the newer governance features for autonomous agents in Copilot Studio autonomous agents: Governance essentials.

For Copilot Studio agents to be ready for production, managed environments, security groups, authentication, publishing controls and DLP policies all have to work together. You're always trading some agility for oversight. Set the right switches, get into the habit of checking the inventory in the admin center, and your exposure stays manageable.