When Copilot Pages and Microsoft Loop first showed up in the tenants I support, the governance questions followed almost immediately. People wanted to know where these new artefacts actually live and how to handle sharing and compliance for them. Unlike Teams or OneDrive content, Copilot Pages and Loop workspaces are stored in SharePoint Embedded containers. These containers belong to individual users, have their own lifecycle and are not classic SharePoint sites. Administrators have to rethink how they handle visibility, control and retention.

Loop and Copilot Pages store their content in per-user embedded containers

There are no classic team sites here. Each user gets their own set of embedded containers for Loop and Copilot Pages, and the container is owned by whoever creates the workspace or page. That has real consequences for access management and admin visibility. The containers don't appear as regular sites in the SharePoint admin center, and you can't manage them the way you would a team site or OneDrive. If you don't know what to look for, you'll miss them, and applying your existing policies to them is harder still.

The following Mermaid diagram gives a rough picture of the architecture for Loop and Copilot Pages with embedded containers:

flowchart TD
  user["User"] --> container["Embedded container"]
  container --> loopworkspace["Loop workspace"]
  container --> copilotpage["Copilot Page"]
  admin["Admin center / PowerShell"] --> container

Figure: The user creates a container for Loop and Copilot Pages, while admins only have indirect control.

Admins control Copilot Pages mainly through Cloud Policy settings

The main governance settings for Copilot Pages sit in the Microsoft Cloud Policy service, in the policies for Loop workspaces and Copilot Pages. With the Loop workspaces configuration you decide who may create workspaces or pages, you can set limits by group or location, and you can restrict usage to selected users. These policies don't target standard SharePoint sites. They apply to the embedded containers themselves, which matters because most of the usual site-based controls have no effect here. As of October 2024, you can:

  • Allow or block the creation of Loop workspaces and Copilot Pages
  • Limit ownership and usage to selected users or groups
  • Set the default sharing policy for new workspaces and pages
  • Optionally control the use of Loop components in other Microsoft 365 apps

You'll find more detail in the official Microsoft documentation.

Labels and retention work, but eDiscovery still has gaps

In projects I keep hearing the same question: do the familiar compliance features cover Loop and Copilot Pages? The honest answer depends on the feature:

  • Sensitivity labels: As of October 2024, you can apply sensitivity labels to embedded containers and their contents, just as you would for other SharePoint artefacts. The behaviour can be inconsistent unless labels are explicitly enabled and applied to new containers, so plan for targeted testing.
  • Retention: Microsoft 365 retention policies are supported. Still, check in the compliance portal how they actually affect individual containers.
  • eDiscovery: As of October 2024, eDiscovery support for Loop and Copilot Pages is limited. It is rolling out, but coverage isn't complete yet. The Loop compliance summary has the details.

Practical tip: Test how sensitivity labels behave on Loop and Copilot Pages before a broad rollout. Some compliance features, eDiscovery in particular, only show up for new content or may need to be re-enabled by an admin in the compliance center.

The admin center handles containers better than PowerShell does

Managing embedded containers as an admin still feels new. In the SharePoint admin center, the "Container sites" view (which used to be hidden behind feature flags in some tenants) lists all embedded containers along with their owners and sharing status. You can also delete or assign containers there when a user leaves. PowerShell support exists, but it isn't as complete as it is for regular sites. For simple queries you can use the SharePoint Online Management Shell (version 16.x or later) in PowerShell 7, provided you have SharePoint admin rights:

Get-SPOSite -Template "SPEMBEDDED#0" -Owner [email protected]

For deleting or reassigning containers I'd stick with the admin center to be safe. Removing a container can wipe out a user's personal artefacts.

Containers are not reassigned automatically when a user leaves

When an employee leaves, their embedded containers are not reassigned automatically, which is different from OneDrive. The containers remain until an admin deletes or reassigns them, and ownership isn't transferred by default. You need regular reviews in the admin center, ideally tied to your HR offboarding process. Some policies can help with automatic removal or with restricting sharing after someone leaves, but test them in a non-production environment first.

I go into the practical side of embedded content and retention in more depth in Restricted SharePoint Search: Copilot pilots done right.

Embedded containers call for a new kind of governance

You can't leave Copilot Pages governance to chance. If you want real value and less risk, embedded containers and Cloud Policies belong in your governance playbook, and the compliance features need proper validation. There are still gaps. Even so, workable governance is already achievable, as long as you understand how this model differs from what you're used to and plan around those differences.