Back to Blog

The connectors that do not exist yet are already approved in your Microsoft 365

The connectors that do not exist yet are already approved in your Microsoft 365

It sits in one FAQ line of Microsoft's documentation, and it is the most important sentence in this whole affair: "If the option stays selected, new connectors of that type follow the default rollout and are available to everyone included in User access". Translated: if you leave a publisher-type box selected, connectors of that type that do not exist yet will arrive already available to everyone. And User access ships set to All users.

What changes on 30 October, and for whom

The notice is MC1454973 in the Microsoft 365 message centre. It says that from 30 October 2026 "the Copilot Connectors page will honor the Allowed agent types setting for all tenants" and that "connector governance will no longer rely on the separate setFederatedConnectors CLI control". That command-line toggle was deprecated on 25 August. And the notice carries one sentence worth quoting in full, typo and all, because it bounds who this is for: "If you organization is not using the setFederatedConnectors CLI toggle you can safely disregard this message".

That sentence deserves to be taken seriously: if nobody in your shop has ever touched that toggle, the notice asks nothing of you. Inflating the affected population is the oldest trick in this genre and we are not going to use it. What does deserve ten minutes from anyone running a Microsoft 365 tenant with Copilot licences is the screen that inherits the job, for a reason that is not in the notice but in the documentation. And while we are here: the date has already moved once. The message was published in August carrying an earlier date, and on 23 October Microsoft added "Updated October 23, 2026: We have updated the timeline. Thank you for your patience".

The setting is no longer called what the notice calls it

A practical detail that took us a while: the notice tells you to look for Allowed agent types. In today's live documentation that section is called Agent and plugin access, under Agents > Settings, and its three options are "Allow agents and plugins built by Microsoft", "...built by your organization" and "...built by external publishers". If you go looking for the notice's label on the screen, you will not find it. And the rename is not cosmetic: the documentation defines plugins as explicitly including connectors and MCP servers, and that is why this setting can govern them.

A ticked box is standing consent

The documentation says, of those three boxes: "When you clear an option, connectors of that type aren't available to users, including connectors released in the future". The symmetry of that sentence is what matters — because if clearing it reaches into the future, so does leaving it ticked. And the FAQ confirms it without ambiguity: leaving the option on means new connectors of that type "follow the default rollout and are available to everyone included in User access". The controls table closes the loop: User access is the population ceiling and its options are All users — marked (default) —, specific users, or nobody.

Add it up: a ticked box plus the default ceiling amounts to a standing, advance approval for a catalogue that grows without you. Nobody will send you a notice the day connector number two hundred shows up. There is no "approve this connector" step in between. It is a decision you took once, probably while thinking about whether people could install agents from a store, and it keeps signing things in your name.

What is actually in that gallery

It is worth looking at the actual catalogue before deciding this is abstract. The federated connector gallery Microsoft publishes is organised by category, and among them sit Legal + HR and recruiting (iManage Work, NetDocuments US, Relativity, Everlaw, Litera, Harvey, Gusto, ZipRecruiter), Accounting and finance (Xero, Square, Moody's, Morningstar, LSEG, FactSet, Zoho Books), CRM (HubSpot, Intercom, Clarify), Files and documents (Box, Egnyte), Collaboration (Gmail, Trello, Miro, Linear) and Productivity (Notion, Airtable, Google Calendar, Google Contacts, Fireflies). Inside that list are the contracts, the payroll and the books of any small company you care to name.

And they are not read-only. The documentation spells it out: where the connector provides the tools, Copilot can "create, update, or delete data in the connected system on the user's behalf". Read tools never ask for permission: "Read tools are always allowed and don't require approval". Write and delete tools default to Needs approval, meaning they ask every time; but in that dialogue, from the menu next to Allow once, the user can pick Always allow, and then they stop asking. That choice applies to the individual tool, not to the whole connector. The administrator is not left without levers — there is the block under Agents > Tools, which reaches tool level — but the prior veto, by default, is not theirs.

What this is NOT

A federated connector gives nobody data they could not already see. The documentation is explicit: they access data "using the user's identity and permissions", "the source system enforces all permissions" and "no data is indexed into Microsoft 365". There is no privilege escalation, no copy of your data going anywhere and no hole to patch. Nor is it a vulnerability or an incident: it is an announced change of governance, with its notice, its date and its documentation.

What grows on its own is not access: it is surface. How many third-party services your people can wire into Copilot, and act through, without anyone on your side making a decision about each one. That is not fixed with a patch, it is decided. It is exactly the mechanism we wrote about four days ago regarding how the retention that covered Copilot switched itself off, and the same one behind the connected apps that get in with a token and never see MFA: nobody is getting in, it is that the configuration you took for granted stopped meaning what you thought.

The six controls, and which one decides in advance

Microsoft publishes the table and it is worth reading in full, because it dismantles the idea that everything hangs on one checkbox:

Control What it does for connectors
Agent and plugin accessThe only one that groups by publisher type and reaches into the future, "including future connectors". Clearing a type sets its staged rollout to No users.
User accessPopulation ceiling for everything. All users (default), specific users or groups, or nobody.
Enable / DisableTurns an individual connector on or pauses it without removing its configuration.
Staged rolloutWhich users get an individual connector, always within the User access ceiling.
Tools block / unblockTool-level and connector-level blocking, under Agents > Tools.
DeletePermanently removes a custom connector and its configuration.

There is an individual escape hatch, and it matters to say so: even if you clear an entire type, "you can still turn on individual connectors from Copilot connectors > Your connections". For a user to see a federated connector, five conditions must hold at once: publisher type allowed (or the connector switched on by hand), connector enabled, user within User access, user within the staged rollout, and a Copilot licence. Five gates, not one — worth saying, because it disproves the alarmist version of all this. The catch is that the other four arrive open: that is precisely what default rollout means. Only two of the five are decided connector by connector, and neither has to be touched for a new connector to turn up switched on.

The six things we check before a date like this

  • Whether anyone used setFederatedConnectors, and what it switched off. It is the single question that decides whether the notice applies to you. If the answer is "nobody", the rest is hygiene, not urgency.
  • A dated screenshot of Agent and plugin access and User access, today. The three boxes and the ceiling, as they stand. It is the only document that will later tell what you inherited from what you chose.
  • Whether User access is still on All users. It is the factory value and the ceiling for everything else. Dropping it to a group is the change that cuts the most reach for the least effort.
  • The Your connections list, connector by connector, with its state and its staged rollout. And for each, whether it is synced or federated: only the synced kind copies data into the Graph index.
  • For the synced ones, whether external item security is restricted. In that family the documentation warns that "deployed connectors are tenant-wide unless external item security is restricted". It does not apply to federated ones, which run on the user's permissions.
  • The date somebody opens that screen again, with a named person attached. Quarterly is enough. With no owner, a year from now the setting will be called something else and we will write this post again.

Where this fits into what we do

When we set up automation and AI in a company, the part that eats the hours is not connecting anything: it is deciding what goes in, with what reach and who approves it, and writing it down so somebody can read it six months later without asking. A connector is a decision about data and applications dressed up as an integration, and data decisions age badly when the only record is the memory of whoever made them. The same holds for the rest of the Microsoft 365 tenant: settings nobody reopens end up meaning things nobody decided. If you want us to look with you at what you have set today and what changes in your case, let us talk.

Sources. Quotations are left in the original English on purpose, so they can be searched verbatim. The notice: MC1454973 in the Microsoft 365 message centre ("Manage Copilot connectors (Global setting) from Agent 365 — SetFederatedConnectors CLI toggle is retiring"), consulted on 29 October 2026, source of 30 October 2026 as the enforcement date, the two quoted sentences, the toggle's deprecation on 25 August 2026, the exemption "If you organization is not using the setFederatedConnectors CLI toggle you can safely disregard this message" — the "you organization" typo is in the original —, the recommended action "review and validate your Allowed agent types configuration…" and the note "Updated October 23, 2026: We have updated the timeline. Thank you for your patience", which is where the moved date comes from. The controls, the defaults and the future: Federated connectors overview (dated 19 October 2026), source of the "Which setting controls what" table with its six controls, the (default) on All users in User access, the sentence "when you clear an option, connectors of that type aren't available to users, including connectors released in the future", the escape hatch "you can still turn on individual connectors…", the FAQ line "if the option stays selected, new connectors of that type follow the default rollout and are available to everyone included in User access", the five conditions for a user to see a connector, the gallery by category with the names quoted, the write actions "create, update, or delete data in the connected system on the user's behalf", the "read tools are always allowed and don't require approval", the Always allow button, and the security section guarantees: "access data using the user's identity and permissions", "the source system enforces all permissions" and "no data is indexed into Microsoft 365". The setting's name and synced connectors: Copilot connectors overview, source of "deployed connectors are tenant-wide unless external item security is restricted" — a sentence that sits in the synced connector section, not the federated one —, and the Agent settings page, which today titles the section Agent and plugin access while the notice still calls it Allowed agent types. Ours, and therefore arguable: the reading that a ticked box amounts to advance consent (Microsoft describes the mechanism; the name is ours), the observation that the notice's label no longer exists on the screen, the idea that what grows is surface rather than access, and the six checks. Photo: "Fukuoka Daimyō Garden City Tower, the turnstiles on the 3rd floor" by Hirho, Wikimedia Commons, CC BY-SA 4.0.

Tags: Microsoft 365 IA Automation Data Suppliers

Subscribe to our newsletter

To receive IT stories, everyWAN news and exclusive subscriber offers, sign up to our mailing list

Minorisa de Sistemas Informaticos y Gestión S.L. © 2026
everyWAN
everyWAN