Sharing and deploying agents in Copilot Studio is one of the most frequently misunderstood topics in the platform. The official documentation covers the essential, but it leaves several important behaviors unexplained, particularly around permissions & channel-specific characteristics.

This article covers sharing and deploying agents from a governance perspective. The goal is not to repeat the documentation, but to clarify the behaviors that matter for admins and CoE: who can access an agent, under what conditions, and what controls are available.

This article is part of the Copilot Studio Governance series. The master article covers the broader governance landscape; this post goes deep on sharing and deployment specifically.

Collaborating on Agents

To open and work on an agent created by someone else in the Copilot Studio portal, a user must meet 3 cumulative requirements:

1. Have access to Copilot Studio
2. Be added as an Editor of the agent
3. Hold a sufficient security role in the environment

Access to Copilot Studio

Before anything else, the user needs access to the Copilot Studio portal itself (copilot.studio.microsoft.com). This slide from the Copilot Studio Implementation Guide explains it well:

The Copilot Studio User license is only available when Copilot Credits are purchased. I provide more information on Copilot Studio licensing here.

The Editor Access and Owner Team

From the Copilot Studio portal, Makers can try to share their agent with an “Editor” to collaborate. Understanding the mechanisms behind this sharing option can help a great deal to troubleshoot some issues.

A non-admin user needs to be an Editor of an Agent to open it in the Copilot Studio portal. Being an editor of the agent allows the user to:

• Review the usage analytics of the agent
• Review and update the configuration of the Agent and related components
• Manage the publication and channels of the agents
• Test the Agent in the Copilot Studio Test pane

The Owner Team

When an Agent is created, Copilot Studio automatically creates an Owner team in the hosting environment. The team name is set to be the Agent Id, without “-“, suffixed by “_1”. The platform automatically shares the agent and related components (tools, knowledge sources configured, etc.) with this team.

The permissions are not identical across all records:

• The team receives permissions to view, edit, configure, share, and publish the agent, but not delete it
• The team has full permissions over agent components, including deletion

When a user is added as an editor, they are automatically added to this Owner Team. This is the underlying mechanism that grants them access to the agent and its components.

One important constraint: agents can only be shared with individual user accounts as editors. Sharing with a security group as editor is not supported.

The Environment Maker Role Requirement

For a user to be added to the Owner Team at the moment of sharing, they must already hold the Environment Maker role. The requirement is on the role itself, not on equivalent permissions. A user with a more permissive custom role will still fail to be added to the team if they do not hold the Environment Maker role.

The behavior depends on who is doing the sharing:

Scenario	Outcome
User already has Environment Maker role	Added to Owner Team without issue
User lacks the role, sharing user is System Administrator	Copilot Studio automatically assigns the Environment Maker role and then add user to Owner Team
User lacks the role, sharing user is not a System Administrator	Error is shown, user is not added to the Owner Team

⚠️ In the third scenario, the user will still appear as an editor in the Copilot Studio interface despite not having been added to the Owner Team. This is a bug, the sharing operation silently fails while showing a misleading result. If an incident is raised about Editors not having access to an Agent, the associated owner team is the first thing to check.

Maintaining Access After Being added as an Editor

The Environment Maker role requirement is sub-optimal. This role grants broader permissions than agent collaboration requires, including the ability to create Power Apps. The requirement applies to the role itself, not to equivalent permissions, which makes it an arbitrary constraint rather than a principled one.

Once added to the Owner Team, the user no longer needs the Environment Maker role for day-to-day collaboration. A less permissive role can replace it, provided it grants sufficient Dataverse permissions to work with the agent and its components. This follow-up reassignment is easy to miss and does not scale.

Ideally, Microsoft would provide two dedicated out-of-the-box roles:

• Agent Monitor: read-only access to review agent configuration, analytics, and test the agent
• Agent Collaborator: edit and create permissions scoped to the related Agent, without broader rights

For now, a custom Agent Collaborator role can partially fill the gap, but every editor addition still requires a manual follow-up reassignment.

Making Agents Available to Users

Deploying an agent to a channel and granting users access to it are two distinct steps, and both must be in place for a user to interact with an agent. A common source of confusion is treating them as interchangeable. This section covers how each works, what controls are available per channel, and where the expected behavior differs from what the documentation suggests.

Before diving into each channel, it is worth summarizing the admin controls that govern agent distribution. Several independent layers of control exist, and understanding which applies where is essential for designing a coherent governance posture.

Control	Configured In	What It Controls	Applies To
Data Policies (ex “DLP Policies”)	PPAC	Enables or blocks specific channels entirely	All channels
Managed Environments – Sharing Limits	PPAC	Restricts who makers can share with (individuals, security groups, everyone)	All channels except SharePoint and unauthenticated channels
TAC – Custom Apps in Preview	Teams Admin Center	Allows or blocks agent distribution via shared link without admin approval	Teams only
Viewer Role	Copilot Studio	Controls which users can interact with an agent in a published channel	All channels except SharePoint and unauthenticated channels

These controls are independent and additive. A channel can be allowed by DLP but still be inaccessible if sharing is restricted via Managed Environments. Conversely, Viewer access can be configured correctly while the channel itself is blocked by a data policy. Governance over agent distribution requires all layers to be considered together.

The Viewer Role

From the Copilot Studio portal, an agent can be shared with users as Viewers. Microsoft refers to this as “sharing for chat“. Unlike Editors, Viewers cannot open the agent in the Copilot Studio portal, they can only interact with it through a published channel.

An agent can be shared as Viewer with:

• Individual user accounts
• Security groups
• Everyone in the organization

Two points are worth clarifying before going further.

1. Viewer access is not channel access. Adding a user as a Viewer does not automatically give them access to the agent. The agent still needs to be published to a channel the user has access to. Both conditions must be met: the user must be a Viewer, and they must have access to the agent in the relevant channel.
2. The Viewer role does not apply universally. This is the most common source of confusion around this topic.
   • If the agent is published to a SharePoint site, all users with access to the site can interact with the agent, regardless of whether they are added as Viewers in Copilot Studio. Access is controlled entirely by SharePoint site permissions.
   • If the agent is configured with no authentication, the Viewer configuration is also bypassed.
   • The Viewer role applies when Microsoft Entra ID authentication is configured, either manually or via the “Authenticate with Microsoft” option, on any channel other than SharePoint.

⚠️ It is tempting to assume that adding someone as a Viewer in Copilot Studio is sufficient. It is not. And conversely, on SharePoint, removing a user as a Viewer will not prevent them from accessing the agent if they still have access to the SharePoint site.

Deploying to Teams

There are two distinct ways a Copilot Studio agent can be made available in Teams. They differ significantly in terms of admin involvement, visibility, and governance control. In both cases, the user must be added as a Viewer of the agent in Copilot Studio to interact with it.

Custom App in Preview via Shared Link

After enabling the Teams channel in Copilot Studio, the agent owner can generate a link and share it directly with colleagues. When a user opens this link, the agent is installed in their personal Teams context.

This method has low friction by design, and that can precisely be the governance concern:

• The agent does not appear in the Teams App Inventory in the Teams Admin Center (TAC)
• It shows as “Agent shared by creator” in the Microsoft Admin Center (MAC) Agent Registry
• There is no admin approval step
• There is no straightforward way to track how many users have installed it

This sharing method is only available if the TAC Org-wide app setting “Let users interact with custom apps in preview” is turned on.

⚠️ If this setting is turned on, any maker can distribute their agent across the organization without any admin action, unless Managed Environments sharing limits are configured to restrict this.

⚠️ If the same agent is deployed both via shared link and as an admin-approved app, it will appear twice in the MAC Agent Registry: once as “Agent shared by creator” and once as “Published by your org”. Additionally, removing a user’s access to the admin-approved app does not prevent them from continuing to use the agent via the shared link. Both distribution methods are independent.

Custom App (Admin-Approved)

Upload the Agent to Teams as a Custom App

As opposed to the Custom App in Preview, this method results in the agent being added as an app in the Teams App Inventory in the TAC, and it shows as “Published by your org” in the MAC Agent Registry. This method requires admin involvement and provides significantly more governance control.

The App can reach the TAC in two ways:

• Submitted by a maker from Copilot Studio: if the user selects “Show to everyone in my org”, an admin must approve the app before it becomes available
  
• Uploaded directly by an admin as a zip file in the TAC: no approval step is required, the app is immediately imported into the org catalog

Deploy the Custom App in Teams

Once approved or uploaded into the TAC App Inventory, the admins can determine which users or groups can have access to the App.

⚠️ Even if a user is configured to have access to the Agent in Teams, it does not mean that they are able to install it. There is another Org-wide app setting “Allow users to install and use available apps by default” which determines whether users can install the Apps they have access to.

If this setting is turned off, the only way for the users to have access to the App is for the admins to configure and assign them an appropriate App setup policy. Since this policy can be applied to a group, a controlled deployment approach involves:

1. Grant Viewer access in Copilot Studio to a security group
2. Grant access to the Teams app to the same security group in the TAC
3. Use the same group to automatically deploy the app to its members with an App setup policy

This ensures the Viewer audience in Copilot Studio matches exactly the audience with the app installed in Teams, avoiding situations where users have the app installed but cannot interact with it, or vice versa.

⚠️ When submitting an agent to be shared org-wide from Copilot Studio, the platform automatically sets Viewer access to “Everyone in the organization”. This can be adjusted after the fact, but it will not be reverted automatically. Regardless of how the agent was deployed, the Viewer audience in Copilot Studio and the audience defined in the TAC must always be kept in sync manually as Copilot Studio does not enforce this alignment.

The Teams App Manifest

Whether the agent is distributed via shared link or deployed as an admin-approved app, its appearance in Teams (name, description, icon, and other metadata) is defined by the Teams App Manifest. Copilot Studio generates this manifest from the agent configuration but does not keep it in sync automatically after the initial deployment.

The practical implications differ by deployment method:

• Custom App in Preview: if the agent name, icon, or description is updated in Copilot Studio, users who installed the agent via a shared link will not see those changes. They must uninstall and reinstall the agent manually to get the updated manifest.
• Custom App (Admin-Approved): if the manifest details change in Copilot Studio, the maker must re-submit the agent and an admin must re-approve it before the changes are reflected for users. For apps uploaded directly by an admin as a zip file, the admin must generate a new zip and re-upload it.

⚠️ Manifest changes, even minor ones such as a name correction or icon update, carry an operational cost: user reinstallation or a full admin re-approval cycle. The practical recommendation is to finalize agent naming, description, and branding before deployment, not after. This is particularly relevant in organizations where the TAC approval process involves multiple stakeholders or has a defined change management cycle.

Deploying to M365 Copilot

Copilot Studio does not have a dedicated M365 Copilot channel: the channel is Teams & M365 Copilot. When configuring it, the maker can tick an option to also publish the agent to M365 Copilot. This means it is not possible to publish to M365 Copilot without also publishing to Teams (but the App in Teams can be blocked or shared with no one).

When the agent is submitted for org-wide availability, an admin can approve it either in the TAC or in the MAC (if the M365 Copilot option is enabled). Once approved, the deployment and access model mirrors Teams: admins can restrict availability to specific users or groups, and can choose whether the agent is automatically deployed or simply made available for users to install themselves.

There is currently no built-in way to track how many users have installed the agent.

Users must also be added as Viewers in Copilot Studio to interact with the agent, the same requirement as for Teams.

Deploying to SharePoint

Permissions and Licensing

Unlike Teams, the Viewer role configured in Copilot Studio does not apply to SharePoint. Any user with access to the SharePoint site can interact with the agent, access is controlled entirely by SharePoint site permissions.

Licensing is less straightforward than the documentation suggests:

• Users with a M365 Copilot license can access the agent without any additional configuration, this is the simplest path.
• For users without a M365 Copilot license, the official documentation states that prepaid Copilot Credits or a Power Platform pay-as-you-go setup is sufficient. However, there was a previous additional requirement for a pay-as-you-go billing policy configured in the MAC for the SharePoint Agents Service. This pay-as-you-go policy had to be set up for the agent consumers, on top of the Power Platform pay-as-you-go configuration for the hosting environment. Microsoft announced this requirement was removed and updated the documentation accordingly. Based on testing in my tenant, this requirement still appears to apply in practice. Worth verifying in your own environment before committing to a licensing approach.

I share more information about Copilot Studio licensing here.

Data Policy Requirements

Two data policy behaviors are worth knowing before deploying to SharePoint:

• If the SharePoint channel is blocked in a data policy, agents cannot be published to SharePoint from Copilot Studio and cannot be accessed in SharePoint.
• ⚠️ If the Direct Line channel is blocked, a DLP conflict is shown and publishing is initially blocked. This is a known and acknowledged behavior by Microsoft. The workaround is to enable the Teams channel. Once done, the agent can be published again. The DLP conflict error continues to appear but no longer blocks publishing.

Accessing the Agent in SharePoint

Publishing an agent to a SharePoint site creates a .agent file in the site, at the root of the main document library, in a folder called “Copilot Studio Agents”. Users with appropriate licensing can access the agent in three ways out of the box:

• Via the top-right corner agent icon in SharePoint, only visible for site owners and for all site users if the agent is marked as approved and the user has a M365 Copilot license or a pay-as-you-go billing policy configured
  
  

• By opening the .agent file directly, either in side pane or in file viewer window
  
  

• Via a SharePoint web part on a page, clicking it opens the agent in a side pane
  

Publishing Limitations and the .agent File

The Copilot Studio Portal only supports publishing an agent to a single SharePoint site at a time. However, the .agent file it creates on the site is a plain JSON file that can be edited, copied, and created manually, giving admins capabilities that go beyond what the portal exposes.

The file structure is as follows:

{
    "schemaVersion": "0.2.0",
    "copilotStudioMetadata": {
        "state": "Published",
        "botMetadata": {
            "botSchema": "your_agent_schema",
            "environmentID": "your_environment_id",
            "hostnameSuffix": "api.powerplatform.com",
            "transport": "rest"
        },
        "name": "Your Agent Name",
        "deepLinkUrl": "https://copilotstudio.microsoft.com/environments/your_environment_id/copilots/your_agent_id/details",
        "icon": "data:image/png;base64,..."
    }
}

The botMetadata values can be retrieved either from an existing .agent file or directly from the Copilot Studio portal. This makes it possible to construct the file from scratch without having previously deployed the agent to SharePoint. Once you have them, you can:

• Customize the name and icon displayed in SharePoint independently of the Copilot Studio configuration
• Deploy to multiple SharePoint sites by copying or recreating the file, bypassing the single-site limitation

⚠️ Copilot Studio has no visibility into copied or manually created .agent files. Undeploying an agent from the original site removes the file from that site only, copies on other sites remain active and are no longer linked to the Copilot Studio deployment lifecycle. Factor this into your governance process if agents are distributed across multiple sites.

Conclusion

Sharing and deploying agents in Copilot Studio involves more moving parts than the official documentation suggests. The key takeaways for admins:

• Editor access depends on the Environment Maker role at the moment of sharing, an over-permissive 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
• The .agent file gives admins an easy path to deploy agents beyond the single-site limitation, but those deployments are invisible to Copilot Studio

As the platform matures, some of these points will likely be addressed. In the meantime, understanding the current behavior is the first step toward governing it effectively.

The Copilot Studio Governance: The Complete Admin Reference covers the rest: DLP enforcement, tenant settings, restriction controls, consumption monitoring, and agent lifecycle management.