Reassign Copilot Studio Agent Ownership via Admin Center

An employee leaves. Their account is disabled. The Copilot Studio agent they built still supports a business process—but nobody now has the authority to own its lifecycle.

That is an orphaned agent problem.

Sharing is not the same as ownership. A collaborator can edit, configure, share, and publish a Copilot Studio agent, but cannot delete it. In the source walkthrough, the non-owner also saw certain owner-oriented interface actions—such as Delete and Go to demo website—disabled. Because Copilot Studio interfaces and deployment paths evolve, treat the disabled demo-site action as an observed UI behavior rather than a universal permission guarantee. Ownership reassignment changes the accountable principal: the new owner gains full edit and delete permissions, while the previous owner loses access.^{1 2}

This guide explains that boundary, shows how to reassign an agent in the Microsoft 365 admin center, and provides an API-based option for repeatable offboarding workflows.

The mental model: access is not accountability

Think of an agent like a production service with several access layers:

• Users can invoke the service.
• Analytics viewers can inspect performance data, subject to additional transcript permissions.
• Collaborators can change and publish the implementation.
• The owner is the principal ultimately responsible for the asset and its lifecycle.

Those roles overlap, but they are not interchangeable.

Microsoft’s current sharing documentation says collaborative authoring can be granted only to individual users in the organization. Coauthors also require the Environment Maker Dataverse security role. By contrast, chat access can be granted to users, supported groups, or the organization, depending on configuration.¹

The practical rule is simple:

That distinction matters during offboarding. Adding a colleague as a collaborator may preserve day-to-day editing, but it does not transfer lifecycle authority.

What the two-user walkthrough demonstrates

The original demonstration uses two signed-in personas to make the boundary visible:

1. Person A creates and owns the agent. The agent list identifies Person A as the owner, and the owner can open the agent’s menu and permanently delete it.
2. Person A shares the agent with Person B. Person B receives the relevant use, authoring, and analytics access, so the agent becomes visible in Person B’s Copilot Studio agent list.
3. Person B is still not the owner. Person B can work with the shared agent according to the assigned role, but the Delete action remains unavailable. In the recorded interface, Go to demo website was also disabled for the non-owner.
4. An administrator reassigns ownership. The administrator selects the agent in the Microsoft 365 admin center and assigns Person B as the new owner.
5. The interfaces synchronize. After refreshing the admin center and Copilot Studio, the owner field changes from Person A to Person B.
6. Person B now has owner-level lifecycle control. The Delete action becomes available, while Person A loses ownership and access.

This before-and-after comparison is more useful than the labels alone: sharing makes the agent available to another person; reassignment transfers control of the asset.

When ownership reassignment is appropriate

Reassignment is useful when:

• the original owner has left the organization;
• the owner’s account is disabled or scheduled for deletion;
• responsibility moves to another team;
• a temporary maker must hand operational responsibility to a permanent owner; or
• an ownership review finds an active agent tied to the wrong person.

The Microsoft 365 admin center can reassign an agent whether its current owner is active or the agent is already ownerless.²

Avoid treating reassignment as a substitute for broader application lifecycle management. An agent can depend on Power Automate flows, connectors, connection references, environment variables, knowledge sources, service accounts, and external permissions. Changing the agent owner does not prove that every dependency is healthy under the new operating model.

Before you transfer: run a dependency check

A clean handover starts before the button click.

1. Identify the agent and environment. Confirm that you have selected the correct agent, especially when names are reused across development, test, and production environments.
2. Choose a real accountable owner. The target must be a user in your organization. For API reassignment, Microsoft explicitly requires the new owner to belong to the tenant.³
3. Check environment access. API-based reassignment gives the new owner Environment Maker permissions in the agent’s environment.³
4. Inventory dependencies. Review flows, connectors, connection references, authentication settings, knowledge sources, custom connectors, and external APIs.
5. Review transcript access separately. Reassignment does not automatically bypass transcript controls. The new owner can access existing transcripts only if they have the required Read transcript privilege.³
6. Record the handover. Capture the old owner, new owner, agent ID, environment ID, reason, timestamp, and ticket or approval reference.

Do agents have to be published first?

No—not according to Microsoft’s current Agent Registry integration documentation. Copilot Studio agents are registered automatically when they are created, and metadata changes are synchronized automatically.⁴

That corrects an older operational assumption that only published agents appear in the registry. If a newly created agent is missing, first verify the tenant, environment, platform filter, and registry synchronization rather than publishing solely to make it discoverable.

Reassign ownership in the Microsoft 365 admin center

The Agent Registry is the tenant-wide inventory and governance surface for agents. It is broader than the Power Platform inventory, which is scoped to Power Platform assets and environments.^{5 4}

Required administrative authority

Microsoft documents several roles for the API route. For a Copilot Studio agent, the caller can be a:

• Global Administrator;
• AI Administrator;
• Power Platform Administrator; or
• Environment Administrator.³

In production, use the least-privileged role that meets the requirement and your organization’s administrative model.

Procedure

1. Sign in to the Microsoft 365 admin center.
2. Go to Agents > All agents.
3. Ensure the Registry view is selected.
4. Find the agent. Use the Platform filter and select Copilot Studio if the tenant has a large inventory.
5. Select the agent to open its details pane. Depending on the current admin-center experience and the data available for that agent, this surface can expose information such as users, data and tools, security and permissions, and activity. The registry may also offer other governance actions, including blocking the agent; blocking and ownership reassignment solve different problems.
6. Under the agent name, select Assign new owner.
7. Search for a user in your organization.
8. Select the user, then select Assign.²

Microsoft documents this action for both ownerless and active shared agents. Reassignment is currently supported for shared Agent Builder and Copilot Studio agents.²

What changes after reassignment

The operation is more decisive than adding a coauthor:

• The new owner receives full edit and delete permissions.
• Uploaded files previously associated with the agent become accessible to the new owner.
• The previous owner loses all access, including read access.²
• For Copilot Studio API reassignment, the new owner receives Environment Maker permissions in the agent’s environment.³
• Existing transcript visibility still depends on the new owner’s transcript privileges.³

The previous owner therefore does not remain a fallback administrator. If they still require access, grant the appropriate access deliberately after reassignment, subject to your sharing policy.

Post-transfer validation

Do not close the offboarding ticket merely because the admin center accepted the action. Validate the outcome:

1. Refresh the registry and confirm that the owner name changes from the previous owner to the new owner.
2. Ask the new owner to refresh Copilot Studio, return to the Agents list, and confirm that the same ownership change is visible there. A hard refresh can help when the browser is showing stale UI state.
3. Open the agent as the new owner and verify that owner-only lifecycle actions—most importantly Delete—are now available. Do not actually delete a production agent merely to test the permission.
4. Verify that editing and publishing work.
5. Test every channel used by the agent.
6. Exercise actions and flows that depend on connections or delegated identities.
7. Confirm knowledge sources remain reachable.
8. Verify analytics and transcript access separately.
9. Record the result and any remediated dependencies.

A refresh or short synchronization delay may be necessary before every interface reflects the change, but Microsoft does not publish a guaranteed “couple of minutes” service level for this propagation. Treat any exact delay as observation, not a contractual expectation.

Automate reassignment with the Power Platform API

For a single agent, the admin center is usually fastest. For bulk offboarding, ownership reviews, or workflow-driven remediation, use the documented Power Platform API.

Prerequisites

You need:

• the target Environment ID;
• the target Bot ID;
• the new owner’s Microsoft Entra user ID;
• a Microsoft Entra user access token;
• an accepted administrative role;
• an app registration granted the CopilotStudio.AdminActions.Invoke scope under the Power Platform API; and
• a target owner who belongs to the tenant.³

The Reassign API does not support classic chatbots; Microsoft documents a 405 Method Not Allowed response for that scenario.³

REST operation

POST https://api.powerplatform.com/copilotstudio/environments/{EnvironmentId}/bots/{BotId}/api/botAdminOperations/reassign?api-version=2024-10-01
Authorization: Bearer {AccessToken}
Content-Type: application/json

{
  "NewOwnerAadUserId": "{EntraUserId}"
}

The current REST reference documents API version 2024-10-01 and a successful 204 No Content response.⁶

PowerShell example

The following example assumes that your authentication process has already produced a suitable delegated access token. Token acquisition should follow your tenant’s identity controls; do not embed credentials in the script.

param(
    [Parameter(Mandatory)]
    [string] $EnvironmentId,

    [Parameter(Mandatory)]
    [string] $BotId,

    [Parameter(Mandatory)]
    [string] $NewOwnerEntraId,

    [Parameter(Mandatory)]
    [securestring] $AccessToken
)

$encodedEnvironmentId = [uri]::EscapeDataString($EnvironmentId)
$encodedBotId = [uri]::EscapeDataString($BotId)

$uri = "https://api.powerplatform.com/copilotstudio/environments/$encodedEnvironmentId/bots/$encodedBotId/api/botAdminOperations/reassign?api-version=2024-10-01"
$body = @{
    NewOwnerAadUserId = $NewOwnerEntraId
} | ConvertTo-Json

$headers = @{
    Authorization = "Bearer $([System.Net.NetworkCredential]::new('', $AccessToken).Password)"
}

try {
    Invoke-RestMethod `
        -Method Post `
        -Uri $uri `
        -Headers $headers `
        -ContentType "application/json" `
        -Body $body

    Write-Host "Ownership reassignment completed. Validate the agent and its dependencies."
}
catch {
    Write-Error "Ownership reassignment failed: $($_.Exception.Message)"
    throw
}

The API is REST-based; Microsoft does not document fictional cmdlets such as Get-CopilotAgent or Invoke-CopilotAdminTransfer. PowerShell is simply the HTTP client in this example.

Troubleshooting

The Assign new owner action is missing

Check that:

• the selected item is a supported shared Agent Builder or Copilot Studio agent;
• you are in Agents > All agents and the Registry view;
• you selected the correct platform and tenant; and
• your account has an appropriate administrative role.^{2 3}

The agent is not in the registry

Current documentation says a Copilot Studio agent should register when created.⁴ Verify:

• the correct tenant and environment;
• registry filters;
• whether the asset is a classic chatbot rather than a supported agent;
• whether metadata synchronization is delayed; and
• whether the agent was deleted or created in another environment.

The API returns 400 Bad Request

Validate the environment ID, bot ID, JSON property name, Entra user ID, content type, and API version. The request body property is NewOwnerAadUserId.⁶

The API returns 405 Method Not Allowed

The target may be a classic chatbot, which the Reassign API does not support.³

The admin-center action fails in a firewalled environment

Microsoft documents a specific limitation: admin actions initiated from the Microsoft 365 admin center can fail when the target Power Platform environment has IP firewall active enforcement mode enabled. In audit-only mode, the actions can succeed and generate an alert. Microsoft’s documented workaround is to run the action directly through the Power Platform API.²

The transfer succeeded, but the agent is still broken

Ownership and runtime identity are different concerns. Inspect:

• expired or user-bound connections;
• flows owned only by the departed employee;
• connection references pointing to invalid connections;
• inaccessible SharePoint sites or other knowledge sources;
• secrets and certificates nearing expiry;
• custom connector permissions; and
• channel-specific deployment configuration.

An ownership transfer restores authority over the agent. It does not automatically repair the rest of the dependency graph.

A better offboarding pattern

The best orphaned-agent process is the one you rarely need to invoke reactively.

Use a lightweight lifecycle pattern:

1. Maintain an inventory of business-critical agents and named accountable owners.
2. Require a secondary collaborator for critical agents—but do not mistake collaboration for ownership.
3. Include agents, flows, connections, knowledge sources, and channels in offboarding reviews.
4. Reassign ownership before disabling the departing owner’s account when possible.
5. Validate runtime dependencies after transfer.
6. Periodically review ownerless agents in the Agent Registry.
7. Use the API for repeatable, logged remediation at scale.

The central lesson is straightforward: an agent is not just a prompt or a chat surface. It is an operational asset with an owner, dependencies, permissions, and a lifecycle. Reassignment solves the ownership problem; disciplined validation keeps the business process working.

References