Microsoft 365 Copilot federated connectors can let people retrieve live information from external services without indexing that external content into Microsoft 365. That can be useful for project systems, customer platforms, knowledge services, and other business tools—but it also gives administrators a practical access-governance task: decide which connector publishers are trusted, which users can connect, and which individual connectors should be enabled.

A legacy tenant-wide connector toggle is also at a transition point. Microsoft’s current guidance says that tenants whose administrators previously used Set-FederatedConnectorToggle must reapply their intended control through the Microsoft 365 admin center by October 20, 2026 if they want that behavior to continue. The old command-line state should not be treated as the long-term control. Microsoft’s current interface uses Agent and plugin access, User access, and connector-level settings instead. See the official Manage federated connector availability guide.

This is an administrator-focused walkthrough, not a claim that every tenant has the same connector inventory or licensing. Menu availability and connector behavior can vary by tenant, product rollout, license, and connector publisher.

What changes after October 20, 2026?

Microsoft’s documentation describes the transition from the older Set-FederatedConnectorToggle PowerShell/CLI-style control to settings managed in the Microsoft 365 admin center. The practical point is to verify and explicitly reapply your intended policy in the current interface, rather than assume a historical toggle will continue to enforce it.

The current controls serve different purposes:

  • Agent and plugin access controls whether agents and plugins from selected publisher types are allowed across the tenant. The categories include Microsoft, your organization, and external publishers.
  • User access sets the maximum group of people who can use agents and plugins. It can be set to all users, specific users or groups, or no users.
  • Connector-level Enable/Disable turns an individual connector on or pauses it without deleting its configuration.
  • Staged rollout limits an individual connector to selected users or Microsoft Entra ID groups.
  • Tools block/unblock provides another control surface for supported tools.

These settings are related, but they are not interchangeable. In particular, a connector’s staged rollout cannot expand access beyond the population permitted by User access.

Before you change anything

Use an account with the required administrative role. Microsoft’s guide lists Global Administrator or Search Administrator for managing federated connector availability. Follow your organization’s change-management process, and capture the current settings before making changes.

Prepare a short change record with:

  1. The intended policy: allow or block Microsoft-published, organization-built, and external-publisher agents/plugins.
  2. The user population that should be allowed to use connectors.
  3. The connectors that must remain enabled for business-critical workflows.
  4. The pilot users or groups for staged rollout.
  5. The test account and test prompts you will use to verify the result.
  6. The rollback decision: which publisher categories and individual connectors should be restored if a business workflow breaks.

Do not assume that blocking a publisher category means every connector is permanently removed. Microsoft says existing connectors remain visible to administrators in Copilot connectors > Your connections; their staged rollout is set to No users when the publisher type is blocked. Administrators can still make an individual connector available where policy permits.

Step 1: Open the current tenant-wide controls

  1. Sign in to the Microsoft 365 admin center with an authorized administrator account.
  2. Open Agents > Settings > Agent and plugin access.
  3. Review the options for agents and plugins built by Microsoft, built by your organization, and built by external publishers.
  4. Clear the publisher types that should be blocked, or leave approved categories selected according to your organization’s policy.
  5. Select Save and record the change.

For example, an organization that has not approved third-party federated connectors may choose to block external publishers by default, then enable only vetted connectors individually. Another organization may allow a trusted publisher category but restrict actual availability to a pilot group using the other controls below.

Do not copy a configuration blindly from another tenant. The correct choice depends on your threat model, approved data sources, licensing, and business requirements.

Step 2: Limit who can use connectors

  1. In the Microsoft 365 admin center, open Agents > Settings > User access.
  2. Review whether access is set to All users, Specific users or groups, or No users.
  3. Choose the narrowest population that supports the intended rollout.
  4. Save the setting and record the authorized users or groups.

Think of User access as the upper boundary. If it is limited to a group, an individual connector’s staged rollout cannot grant access to someone outside that group. If User access is set to No users, connector-level settings do not make the connector usable by anyone.

Use a dedicated pilot group where practical. This allows administrators to test connector behavior and permissions before expanding access to a wider population.

Step 3: Review each connector

  1. Open Copilot > Connectors > Your connections in the Microsoft 365 admin center.
  2. Review the connectors currently available in the tenant, including Microsoft-published and approved partner connectors.
  3. Open a connector to check its state and intended audience.
  4. Enable only the connectors approved for the organization; disable a connector to pause it without deleting its configuration.
  5. Use Staged rollout to assign access to selected users or Microsoft Entra ID groups.
  6. For custom connectors, use Delete only when you intend to permanently remove the connector and its configuration.

For each enabled connector, document its business owner, source system, data classification, user group, and reason for approval. A connector that retrieves customer records or can create and modify tickets deserves a different review from one that only searches public reference material.

Step 4: Test the policy as a real user

Do not stop after saving the admin settings. Verify the effective result with a test account in the intended group and, where possible, a second account that should not have access.

  1. Reopen Agents > Settings > Agent and plugin access and confirm the publisher categories.
  2. Check Agents > Settings > User access and confirm the allowed population.
  3. Under Copilot > Connectors > Your connections, check the connector’s enabled state and staged rollout.
  4. Sign in to Microsoft 365 Copilot Chat as the test user.
  5. Open Settings > Sources and check whether the connector appears and can be connected.
  6. Authenticate to the external service using the test user’s own account, if required.
  7. Run a harmless, known-answer test query against non-sensitive data.
  8. Repeat with a user who should be excluded and confirm that the connector is not available to that user.

Microsoft notes that changes can take up to 10 minutes to propagate across Microsoft 365 experiences. Refresh the admin center and allow for propagation before concluding that a setting failed. If access remains inconsistent, check all the control layers instead of repeatedly changing the same setting.

Step 5: Review the security boundary of the connector

Federated connectors use the Model Context Protocol (MCP) to retrieve information from an external source at query time. Unlike synced connectors, they do not index that external content into Microsoft 365. The source system continues to enforce the signed-in user’s permissions.

That does not make every connector automatically safe. Before enabling one, check:

  • Publisher and provenance: Is it published by Microsoft or submitted by a partner and approved for the gallery?
  • Source permissions: Does the user’s external account have access only to the records and actions they need?
  • Data handling: What information is sent to the external service, and what do the provider’s privacy terms say?
  • Write-capable tools: Can the connector create, update, or delete data, or is it read-only?
  • User confirmation: Are write or delete operations configured to require approval, and do users understand what they are approving?
  • Auditability: Can the organization investigate activity in the source system and relevant Microsoft security or compliance tooling?
  • Business continuity: What happens to a workflow if the connector is disabled or its publisher is blocked?

Microsoft’s overview explains that connector capabilities depend on the tools exposed by the publisher. Actions that modify or delete data require user approval under the documented model, and a user’s permissions in the connected system limit what the user can do. Review the official federated connectors overview before approving connectors that can take actions.

For broader context on governing agent access and risk, read our guide to Microsoft’s AI agent security controls and dynamic permissions. If your organization also operates agents that make repeated model or tool calls, our practical guide to controlling AI agent API usage, budgets, and rate limits covers a related reliability control.

Common problems and how to diagnose them

A connector disappeared for users

Check whether its publisher category is blocked, User access excludes the user, the connector is disabled, or staged rollout is set to No users. These controls can combine, so inspect all of them before changing the configuration.

An administrator can see a connector but a user cannot

Administrative visibility does not guarantee user access. Confirm the user is within the User access population and the connector’s staged rollout, and confirm the publisher type is allowed or the connector has been individually enabled.

The saved setting does not appear to take effect

Allow up to 10 minutes for propagation, refresh the admin center, and test with an account whose group membership is clear. Record the time of the change and the exact account used in the test.

A connector works but returns incomplete information

Check the permissions and data scope of the authenticated account in the source system. Federated connectors retrieve data at query time; they do not bypass the source system’s access controls or make unavailable records visible.

A workflow needs a connector that is blocked by default

Review the risk and business need first. If the organization’s policy permits it, enable the specific connector and stage it to the smallest appropriate user group. Do not broadly allow an entire publisher category simply to fix one workflow unless that is the intended policy decision.

Administrator checklist

Before closing the change, confirm each item:

  • The tenant’s intended legacy toggle behavior has been reapplied in the current admin interface.
  • Publisher categories match the organization’s approved policy.
  • User access limits the eligible population appropriately.
  • Each required connector is enabled and staged to the correct users or groups.
  • A test user can access approved data and an excluded user cannot.
  • Write-capable tools and confirmation behavior have been reviewed.
  • Source-system permissions and audit requirements have been checked.
  • The change record includes the settings, test results, owner, and rollback plan.

Frequently asked questions

Is Set-FederatedConnectorToggle still the control administrators should rely on?

No. Microsoft’s current guidance directs administrators to manage availability in the Microsoft 365 admin center. For tenants that previously used the old toggle, the documented transition date is October 20, 2026; verify and reapply the intended policy in the current interface.

Can I manage Agent and plugin access through PowerShell or an API?

Microsoft’s current management guide says there is no PowerShell or API option for the new Agent and plugin access setting. Use the Microsoft 365 admin center for these controls.

Does blocking a publisher category permanently delete its connectors?

No. Blocking a publisher category makes connectors of that type unavailable to users by setting their staged rollout to No users. Existing connectors remain visible to administrators, and individual connectors can be made available where the tenant’s other access controls permit it.

Do federated connectors copy data into Microsoft 365?

Microsoft says federated connectors retrieve information from external systems in real time through MCP and do not index that external content into Microsoft 365. The source system remains the system of record and enforces the user’s permissions.

How long should I wait before testing a change?

Microsoft says changes can take up to 10 minutes to take effect across Microsoft 365 experiences. Refresh the admin center and test with a representative user after allowing for propagation.

Final recommendation

Treat the October 20 transition as a configuration verification task, not merely a date in a changelog. Reapply the intended policy in the current Microsoft 365 admin center, review publisher-level and user-level access together, stage each connector deliberately, and verify the outcome with real test accounts. That process reduces the risk of an old tenant-wide setting no longer expressing the organization’s intended connector policy.

Official references