How to Manage Federated Copilot Connectors in the Microsoft 365 Admin Center

The short version for admins: allowing connectors now happens in layers inside the admin center. Microsoft's current documentation says the Agent and plugin access setting can't be managed with PowerShell or an API. That matters if you built a runbook around the earlier PowerShell approach.

What federated connectors are and why they need their own controls​

In Microsoft's documentation, federated connectors let Microsoft 365 Copilot pull data from outside services at runtime using the Model Context Protocol (MCP). Synchronized connectors index outside content into Microsoft Graph. Federated connectors fetch it live each time, and the data is never copied into Microsoft 365.

Microsoft's Tech Community announcement says these connectors ship out of the box. They are built and maintained by Microsoft in partnership with leading SaaS and data providers, and enabled by default with admin controls. The Connectors Gallery is now large. Microsoft Learn lists sources across finance, CRM, legal, health, project management and productivity, including HubSpot, Notion, Asana, Box, Gmail, Google Calendar, Canva and many others.

The governance stakes go up because connectors are no longer read-only. Microsoft says that when a connector provides the right tools, Copilot can create, update or delete data in the connected system for the user, with the user's approval. Those actions run under the user's own identity and permissions in the third-party service. Copilot can only change what the user could already change. The connector publisher decides which tools exist, though, and publishers can add or change tools over time.

Section summary: Federated connectors are live, user-authenticated, MCP-based links to outside services, and some of them can write data. That's why default-on behavior needs a proper control plane.

The control surfaces, one by one​

Microsoft Learn spreads connector governance across several admin center locations. Administrators can manage Microsoft 365 Copilot connectors, synchronized connectors, federated connectors, and supported Cowork plugins from a single location: Copilot connectors > Your connections. Bulk policy sits under the Agents section.

Some details worth knowing:

• Publisher types: There are three categories: Microsoft, your organization (custom connectors) and external publishers (partner connectors). If you clear a category, existing connectors of that type stay visible to admins but their staged rollout changes to No users. Connectors of that type released later are blocked as well.
• Individual overrides: Microsoft says a setting made on an individual connector takes precedence over the bulk publisher-type setting. You can keep external publishers blocked and still turn on one vetted partner connector from Your connections.
• User access always applies: It has three options: All users (the default), Specific users or groups, and No users. Staging can narrow that population but can't widen it. Microsoft also notes that a connector whose details pane says "Everyone" is still unavailable to users excluded by User access.
• Disable vs. delete: Disabling keeps the configuration. Deleting a custom connector removes it permanently. Use the pause option when you're unsure.

Section summary: Think of it as nested limits. User access is the largest boundary, publisher type is next, and per-connector enablement and staging decide the rest.

The visibility checklist: when does a user actually see a connector?​

Microsoft's overview says a user sees a federated connector in Copilot only when all of these are true:

1. The connector's publisher type is allowed in Agent and plugin access, or an admin turned the connector on individually.
2. The connector is enabled.
3. The user is included in User access.
4. The user is included in the connector's staged rollout.
5. The user has a Microsoft 365 Copilot license.

The documentation also says the "Installed for" and agent-sharing settings don't apply to federated connectors. Write, update and delete tools are part of the connector and can't be enabled separately. If a connector is allowed, its write tools come with it, and the guardrail is the per-action user approval.

Step-by-step: a sensible rollout​

Microsoft's documentation lists Global Administrator and Search Administrator as the roles that can manage federated connector availability. Then:

1. Set publisher policy. Go to Agents > Settings > Agent and plugin access. Clear the publisher categories you don't want on by default, then select Save. Many organizations will keep Microsoft-built connectors and block external publishers until they've reviewed them.
2. Set the user limit. Under Agents > Settings > User access, choose All users, specific users or groups, or No users.
3. Vet each connector. Before allowing a connector, Microsoft advises reviewing its capabilities, privacy terms and third-party agreements against your security, compliance and acceptable-use requirements. This matters most for connectors with write, update or delete tools.
4. Inspect the tools where you can. Open the connector in Copilot connectors > Your connections, go to the Tools section, and sign in to the third-party service. Viewing tools in the admin center isn't available for all connectors. Microsoft labels this feature "coming soon." The tool list reflects the permissions of the account you sign in with, so use a well-privileged account. Signing in here may also sign you in to that connector in Copilot.
5. Enable and stage. Turn the connector on and use Add staging in the Staged rollout column to target a pilot Entra group.
6. Update user guidance. Microsoft recommends telling users and help-desk staff that connector actions run with users' own permissions in the third-party service.
7. Verify. Changes can take up to 10 minutes to take effect across Microsoft 365 experiences. Refresh the Microsoft 365 admin center to see updated connector states, including staged rollout. Then sign in as a test user and check Settings > Sources in Copilot Chat.

What success looks like: a pilot user opens Copilot Chat, selects the ellipsis menu, then Settings > Sources, finds the connector, selects Connect, and completes authentication with their own credentials. Users outside the pilot group shouldn't see it at all.

Troubleshooting the usual failure points​

• The connector is enabled but a user can't see it. Go through the five-item checklist above. The usual causes are User access set to specific groups, the user missing from staging, or no Microsoft 365 Copilot license.
• You cleared a publisher type and a connector disappeared. That's expected. Its staged rollout was reset to No users. Open it in Your connections and stage it again for the right groups.
• Changes don't seem to apply. Wait about 10 minutes and refresh the admin center before changing anything else.
• You can't see a connector's tools in the admin center. That view isn't supported for every connector. Microsoft's fallback is to sign in to Copilot as a user, go to Settings > Sources, select the connector, and expand Write/Delete tools.
• Your MCP server blocks Copilot traffic. If a custom MCP server restricts inbound traffic by IP address, Microsoft says to allow the static egress IP addresses that Microsoft 365 Copilot uses. Static egress is on by default for MCP-based federated connectors.

How this differs from the spring 2026 launch​

Part of what's new is how much the model has changed in a few months. When federated connectors first reached tenants, admins began seeing them in the Microsoft 365 admin center starting on April 20, 2026, and Microsoft-published federated Copilot connectors (connector type: MCP) appeared under Microsoft 365 admin center → Copilot → Connectors, enabled by default.

The bulk off switch back then was PowerShell. Microsoft's Tech Community announcement said admins could also use PowerShell to disable all default federated connectors across the tenant and selectively reenable individual connectors as needed. In practice it was clunky. Consultant Andrés Gorzelany wrote that the Connector.Cmd cmdlet only worked for him once he disabled at least one federated connector using the UI.

Microsoft's current "Manage federated connector availability" page, last updated in October 2026, tells a different story. Asked whether there's a PowerShell or API option for Agent and plugin access, the answer is "Not currently," followed by an instruction to use the admin center. Bulk control has moved into the GUI under Agents > Settings and is now split by publisher type rather than a single on/off switch for all defaults.

Older guidance doesn't always match the current docs, so watch for these:

• Roles: Some third-party guides from April said management required the AI Administrator role. Microsoft's current documentation names Global Administrator and Search Administrator.
• Licensing: Microsoft's May announcement said federated connectors were available to Copilot Chat users without a Microsoft 365 license, as well as to Microsoft 365 Copilot customers. The current overview lists a Microsoft 365 Copilot license as a condition for seeing a connector. Treat the Learn page as current and test with both license types if it matters to you.
• Dates: The roadmap gives a February 2026 GA date, but connectors started appearing in tenants in late April. The roadmap is a status tracker, not a precise changelog.

Analysis: good controls, but the defaults still deserve attention​

This is a real improvement. Publisher-type gating with per-connector overrides is how most IT teams already handle app consent, and the admin center now spells out the layers clearly. Moving bulk control into the GUI also removes a fragile script from the process.

Two caveats remain. First, Microsoft-built connectors are still available by default whenever the Microsoft publisher category is allowed and users fall within User access. Teams that haven't looked at Agents > Settings since spring should check what's been live in their tenant. Second, the lack of PowerShell or API support for this setting is a gap for organizations that manage configuration as code or audit settings drift across many tenants. On the audit side, Microsoft does say connector activity can be reviewed in Microsoft Purview.

Neither caveat outweighs the main gain: admins now have documented, layered controls over which connectors users get, and those controls sit in the admin center rather than a script.