Copilot connectors: preserve access scope

Copilot connectors can make information from other business systems available within Microsoft 365 Copilot, Microsoft's workplace AI assistant. Federated connectors provide access to external information using the Model Context Protocol, or MCP. If your organisation previously disabled these connectors, check which control will preserve that decision after 20 October 2026.

This is a continuity question for an existing access restriction. The task is to establish that the intended users remain allowed or excluded, while separately approved work continues. It is not a reason to disable every AI feature or assume that every Microsoft 365 account faces the same change.

Microsoft's federated connector management guidance, last updated on 27 August, says a previously disabled setting is honoured until 20 October. The approaching date is an older published product deadline, not a new announcement, legal duty or evidence of a breach.

Find the decision behind the old setting

Ask the responsible administrator whether your environment used the retired command-line toggle to disable federated connectors. The Microsoft page says that toggle retired by 25 August 2026 and directs administrators to update the replacement controls to continue the previous behaviour after 20 October. It also retains older command instructions. Do not treat their presence as evidence that running them now will preserve the restriction.

A saved screenshot or configuration record can explain what someone intended. It cannot establish the effective post-transition setting on its own. Locate the original business decision: which external information was involved, who was meant to have access and why the restriction existed. Record approved exceptions separately rather than assuming a broad description such as "AI disabled" captures the organisation's policy.

If the previous toggle was not used, the specific carry-over deadline may not describe your situation. The administrator should establish the actual controls and policies before commissioning a change. The public notice does not prove that access automatically broadens in every tenant, the organisation's Microsoft cloud environment.

Resolve the documentation mismatch before changing categories

The older connector page calls the destination control "Allowed agent types". Following its link leads to Microsoft's current agent settings guidance, updated on 30 September, which uses the heading "Agent and plugin access". It describes categories for Microsoft, the organisation and external publishers.

That page also describes separate user-access choices: all users, no users, or specific users or groups, subject to existing policies and assignments. A category choice and a user assignment answer different questions. Neither should be assumed to reproduce a particular former connector restriction without checking its actual scope.

The naming difference matters because the current page covers more than the narrow historical toggle. Turning off an entire publisher category may affect an approved tool as well as the connector access under review. The documents do not establish one universally equivalent replacement for every tenant's earlier setting.

Have the administrator or provider identify the actual control shown in your tenant, its scope and the related assignments. If they cannot reconcile the two documents, obtain clarification from Microsoft support through the genuine support route. Do not substitute a broader restriction solely because its label looks familiar, or reuse the old control's timing assumptions for the current setting.

Carry a real business requirement into the review

Consider a fictional engineering consultancy. Its recorded decision is to keep federated connector access disabled while it reviews how external project information may be used. It separately permits a particular supplier's agent for two members of its proposal team. That approved agent is a different workflow from the federated connector restriction.

All people, controls, evidence and test results in this example are hypothetical. They illustrate an acceptance decision, not a finding from a customer tenant or a claim that a named product offers an exact permission combination.

The director owns the business access decision. The IT administrator identifies effective settings and assignments. The external IT provider explains the proposed transition and investigates unresolved product behaviour within its agreed scope. The proposal-team manager owns the approved agent workflow and its alternative if it becomes unavailable.

The director gives the team two acceptance requirements. The excluded population must not acquire the connector access under review. The two authorised proposal staff must retain their separately approved workflow unless the director explicitly agrees a temporary alternative. Staff outside that approved group must not gain its access either.

Access to the external source remains a separate consideration. Being able to use an agent or connector is not a business approval to see every source record. The administrator must account for the source's permissions and the organisation's intended use, without assuming that an agent-category choice answers those questions.

Reject a replacement that breaks an approved exception

The provider's first proposal is to disable a whole publisher category. In this fictional proposal, that category includes the separately approved agent. The proposed change record initially says only that connector access will remain restricted; it omits what happens to the proposal team.

The administrator and business owners review supplied results from a separately authorised representative test arrangement using fabricated identities and records. The excluded user's connector check is denied, but the two authorised proposal users also lose their approved agent workflow. The result fails the agreed acceptance requirements.

A denial for an excluded user is useful evidence for that case. It does not excuse the unapproved interruption or prove the correct treatment of every other assignment. The director rejects the broad change as proposed. The provider must correct the impact assessment before it can be considered again.

The completed review record identifies the distinct findings.

The problem is not solved by allowing the whole category again and assuming the connector restriction will remain. Both the technical scope and the approved exception need an evidenced design.

Correct the plan and give the retest an owner

The provider revises the proposal to distinguish the connector restriction, the approved agent and their user assignments. The administrator must establish which supported controls can implement the intended combination in this tenant. The revised plan records that the public documents alone do not settle it. It does not invent a setting to complete the form.

The director accepts the corrected investigation plan but withholds approval of the broad replacement change. The provider owns clarification of the control mapping. The administrator owns the resulting configuration evidence and a retest against the full intended population. The business owners accept the results for their respective work.

The retest must demonstrate the excluded connector case, both authorised proposal users and the user outside the approved exception. It must also identify other workflows affected by the proposed category and assignment changes. A screenshot showing the category disabled would not answer all those questions. Retain the exact scope, expected result and observed result for each case.

In this example, that retest is not yet complete. The decision record therefore remains "transition not accepted", rather than calling the corrected paperwork proof that the restriction will survive. No one relies on the retired toggle as the permanent fallback.

Plan for unresolved evidence before 20 October

The consultancy sets an internal decision checkpoint on 16 October, leaving time before the vendor's 20 October date. This is a fictional planning choice, not an additional Microsoft deadline. The director requires either accepted replacement-control evidence or an explicit contingency decision at that checkpoint.

The proposal-team manager documents an alternative using the team's existing authorised source applications and manual review. It does not require granting more people source access or copying project records into a new tool. The director accepts that bounded working alternative if the approved agent must temporarily stop, and records who tells the two affected staff and who restores the normal process after acceptance.

That operating alternative does not enforce the connector restriction. The administrator and provider still need to identify a supported, impact-reviewed technical arrangement that prevents the unwanted access when the old setting ceases to be honoured. If that cannot be established before the checkpoint, the director receives the unresolved exposure, affected workflows and available supported options for a specific decision. A message asking staff not to use the feature is not evidence that technical access is blocked.

The contingency may change the earlier continuity requirement for the approved agent, but only through a documented business decision. It does not silently remove the exception from the original requirements. This preserves why the first proposal failed and what the owner has subsequently agreed to tolerate.

The completed outcome is a rejected broad change, an owned corrective assessment and an approved limited work alternative. Technical transition acceptance remains withheld until the evidence supports it. That is more useful than reporting the task complete because a new page of settings has been located.

Keep sign-off tied to the intended access

Before final sign-off, the business approver needs the intended population, effective control and assignment evidence, affected-workflow review, completed results and any expressly accepted restrictions. The administrator should retain the instructions needed to investigate or reverse the approved change through a supported process, including who covers absence.

Set a follow-up after the transition to confirm the intended behaviour remains in place. Record new group membership, connector additions or changed source permissions as reasons to review it again. Approval for one tested scope is not approval for every later connector or agent.

For a separate review of responsibilities between your business and its provider, use the ICT supplier risk management guide. It helps turn missing assurances into owned questions without treating a supplier document as proof of your actual settings.

Bring the control transition to your IT review

Bring the original access decision, current control evidence, approved exceptions and the question your administrator or provider cannot yet answer. The useful outcome is a supported transition that preserves the intended restriction, or an explicitly accepted change to how the business works while that evidence is resolved.

My IT management consulting can help define responsibilities, review supplier proposals and agree priorities with your existing team. Discuss your Copilot control transition with those records and the deadline. We can agree the advisory scope and who owns technical implementation and ongoing checks, without assuming a software subscription includes that work.