Microsoft 365 Agent Settings: 5 Controls to Separate

Selecting No users is not always a tenant-wide agent kill switch. In the Microsoft 365 admin center, Sharing, User access, Allowed agent types, and Agent Registry actions control different parts of the agent lifecycle.

That distinction matters because an administrator can tighten one control and still leave another distribution or access path open. The useful question is not “Did we disable agents?” It is “Which agent type, action, audience, and surface did this setting actually govern?”

The Problem

Microsoft 365 now brings several agent controls into the admin center, but the labels can sound broader than their actual scope. The most important example is Sharing.

Microsoft documents that No users under Sharing disables organization-wide sharing, while users can still share directly with specific individuals. The same Sharing control applies only to agents built with Microsoft 365 Copilot Agent Builder.

That makes it a distribution control, not a universal block. Copilot Studio agents, Microsoft-built agents, external agents, and core Copilot experiences can follow different management paths.

The Nugget

Treat Microsoft 365 agent settings as five separate control layers:

Control	What it actually decides	What it does not prove
Allowed agent types	Which publisher categories users can see and install from the Agent Store	That existing agents are blocked or removed
Sharing	Who can broadly share Agent Builder agents	That direct sharing to individuals is impossible
User access	Which users or groups can interact with agents	That every individual agent is approved
Agent Registry lifecycle	Which agents are allowed, assigned, blocked, or removed	That every risk signal is current or complete
Core Copilot boundary	Which experiences are outside agent settings	That Researcher or Analyst disappear with an agent setting

Microsoft also notes that Microsoft-built agents can remain visible when their publisher category is disabled, although users cannot install them. Visibility and availability are therefore not the same thing.

Why This Matters

These controls solve different governance questions:

1. Catalog: What can users discover?
2. Distribution: Who can share an agent broadly?
3. Consumption: Who can use agents?
4. Lifecycle: Which specific agent should be allowed or blocked?
5. Experience boundary: Which Copilot capabilities are not governed by these agent settings?

If an organization only changes one global-looking toggle, it can create false confidence. A safer rollout combines tenant settings with per-agent review in the Agent Registry and the existing app policies and assignments.

This also connects to the wider Agent 365 security transition: inventory, ownership, policy, and evidence have to agree. A setting screenshot is not end-to-end proof.

What Admins Should Do

Use this five-step verification path:

1. Open Agents > Settings in the Microsoft 365 admin center and record the selected Allowed agent types, Sharing, and User access scopes.
2. Test with one pilot user inside the allowed scope and one user outside it.
3. Create or use a low-risk Agent Builder agent and verify organization sharing separately from direct individual sharing.
4. Open the Agent Registry and confirm the agent’s publisher, owner, availability, assigned audience, and lifecycle status.
5. Verify any expected block from the user experience, not only from the admin setting page.

Use the AI Administrator role where possible. Microsoft explicitly recommends least-privileged administration instead of routine Global Administrator use.

Verification Notes

Do not interpret a zero in the Agent Registry Risks column as proof that the agent has no risk. Microsoft documents that the column shows high-severity risks, that lower-severity signals can still exist in the security portals, and that the aggregated count can lag those portals by up to one hour.

Also separate core Copilot experiences from agents. Microsoft documents that Researcher and Analyst do not fall under agent-related settings even though they coexist with governed agent experiences.

Pro Tip

Build a small evidence matrix with one row per control and three columns: configured state, expected user outcome, and observed user outcome. This turns an ambiguous settings review into a repeatable access test.

For the content side of the same operating model, the organizational prompts guide shows how to add ownership and lifecycle rules after access is controlled.

Sources

• Agent settings in Microsoft 365 admin center
• Manage agents in the Microsoft 365 admin center
• Agent Registry in Microsoft 365 admin center