Copilot admin center limits: the open-source stack keeps the record

What the Copilot settings actually hold

Copilot > Settings in the Microsoft 365 admin center breaks into four tabs: User access, Data access, Copilot actions, and Other settings. Two warnings at the top of Microsoft’s map of that page earn a read before anyone goes hunting for a toggle that is not there. What appears depends on what your tenant is provisioned for, and the article is revised often enough that its scenarios may differ from yours.

Permissions split along roles. AI Administrator may change a setting; Global Reader may only read it. Under those roles the switches are few, and every one of them names what it moves.

The four switches that decide what agents do

Copilot Frontier lives under Copilot > Settings > View all and covers preview and experimental features across web apps, desktop apps and agents. It arrives shut, since Microsoft’s default keeps Frontier away from everyone in the tenant until an admin says otherwise. The options run from no access through named groups to every group, and the same page’s Agents tab hands out early access to the agents Microsoft ships.

Microsoft Copilot self-service purchases sits under Settings > User access with three settings: Allow, Allow trials only, Do not allow. Choose Allow and anyone in the organization may try or buy Copilot unasked, which turns the admin’s job from handing out access into tracking demand.

Data access > Agents is what most admins came for. It decides who may reach agents and which kinds they may install, then passes the detail to the Manage all agents view.

Copilot actions > Advanced package uploads shrinks the group allowed to upload a package carrying actions or an MCP server. A package of instructions alone stays open to everyone, so the switch closes part of the surface and leaves the rest.

The registry is where an agent is allowed to exist

Agents > All agents > Registry is the inventory: Microsoft agents, external partner agents, agents your organization published, agents a creator shared. The registry is where an admin enables, disables, assigns, blocks or removes one, and where each request to publish into the store is approved or rejected. Microsoft reduces that power to a sentence: people in your organization reach only the agents an admin has allowed. The agent settings page adds rules that act on many agents together, security templates, sharing controls and access per group.

Graph endpoints for that registry sit in preview, and Microsoft’s own description of Agent 365 is a control plane for agents wherever they were built or acquired, which widens the console’s reach by design. Anyone who thought the console held only Microsoft’s agents should reread that line: the intent is to hold the record for every agent an organization runs.

Where the control stops

Every switch writes a permission into one tenant, and a platform you rent carries it out. The panel reflects provisioning, and Microsoft warns the page keeps moving. Evidence a person can diff is not among its outputs.

Interactions and admin changes are recorded in Microsoft Purview, inside a Microsoft subscription; for non-Microsoft AI applications, Microsoft puts the audit on a metered plan with 180 days of retention.

For work in Word, Teams and Outlook the arrangement holds, and often it is right. The arithmetic shifts outside the tenant: an agent reconciling an invoice export, calling a partner’s API, reading a queue that lives in your own database. That somebody allowed the agent, the console shows. Which revision of the instructions was live the night the wrong row was written, it cannot show. Eighteen months on, an auditor asking who widened an agent’s reach is left filing an access request for a console they cannot open.