You ask, we answer · 09 October 2026
Federated Copilot connectors can write to ServiceNow and CRM — how do we stop that becoming a free-for-all?
We’re told federated Copilot connectors will soon create, update and delete records in third-party systems from Copilot Chat. Security liked them when they were read-only. Can admins turn off write tools without killing read grounding, and what should we tell people before October?
Grounded with: Microsoft 365 Roadmap 570964 Federated Copilot Connectors will support write, update and delete actions (In development, GA October 2026); Microsoft Learn — Federated connectors overview (write/update/delete, confirmation options, admin tools list, Allowed agent types); Manage federated connector availability; public practitioner threads on Copilot agents acting vs narrating (r/Copilot)
DIGITAL SKILL WORKS LTD / 12 PANES
You’re right to treat “read the ticket” and “change the ticket” as different animals. Practitioner threads keep asking for agents that do things rather than describe them; Security hears that and correctly asks who approved the do button. Write access from Copilot is useful — and it’s also how a casual “Always allow” turns into a quiet CRM edit.
Here’s what’s going on. Roadmap 570964 says federated Copilot connectors (MCP type) that today read third-party data in real time will unblock create, update and delete tools in Copilot Chat, with general availability targeted for October 2026. Learn’s Federated connectors overview matches that: support for write, update and delete begins rolling out in early October 2026. Copilot acts with the signed-in user’s own account and permissions in the source system; nothing is indexed into Microsoft Graph; and every create/update/delete initially needs the user’s explicit confirmation before anything is sent. Declined actions do nothing. Researcher stays read-only for these connectors.
The confirmation UX matters more than the brochure. Learn documents Allow once, Allow for conversation, Always allow, and Cancel. “Always allow” sticks until the user resets it or the publisher changes the tool. Users manage that under Settings → Sources, where Write/Delete tools are grouped separately from always-allowed Read tools. New or changed write tools default back to Needs approval.
Now the admin catch: write tools aren’t a separate tenant switch. Learn is explicit — they’re part of the connector. Your controls are enable/disable the connector, staged rollout to Entra groups, and the tenant-wide Allowed agent types setting (Agent 365) that can keep Microsoft-published and third-party connectors off by default so you enable them one by one. Admins should review each connector’s Tools list in Copilot connectors → Your connections (sign in with a high-privilege account so you see the full write/delete set). Partner connectors still need admin approval before enablement; Microsoft-published ones default on unless you disable them.
This is Schofield’s Third Law with a purchase order attached: the easier it is for people to reach a system from Copilot, the easier it is for them (or a hasty “Always allow”) to change it. Steady before scale puts the Security pane in front of “just turn on HubSpot.”
Options that actually work:
- Inventory, then stage. List every federated connector already on, open Tools, note which expose Write/Delete, and stage only the ones Legal and the data owner signed off — with a named owner and a rollback plan. Best Steady default.
- Deny by default, enable by exception. Deselect Microsoft-published and third-party options under Allowed agent types, then enable approved connectors for a pilot Entra group. Moderate effort; stops surprise gallery arrivals.
- Train hard on confirmation. Ban “Always allow” for CRM, finance and ITSM write tools in the house rules; keep Needs approval and expand the confirmation card before clicking. Complements admin controls; doesn’t replace them.
- Leave everything on and hope people read the card. Fast, and how “create an issue” becomes “delete a record” with a cheerful toast.
12 Panes action / comms: Tell Security and Legal: Write tools ride with the connector; our control is which connectors exist, for whom, and with which house rules on Always allow. Tell helpdesk: Actions run as the user in the third-party system — reset their Source permissions if a tool stuck on Always allow. Tell makers and power users: Read freely where approved; for writes, Allow once until you’ve checked the parameters. Leadership: This is productivity with a change-control story, not a free automation layer.
Benefits / risks: People finish work in Copilot without swivel-chairing into five apps; actions respect source ACLs and need confirmation by default; Always allow and conversation-scoped allow reduce friction and raise blast radius; there’s no documented per-tool admin kill-switch separate from disabling the connector; Purview audit of connector activity is the compliance backstop — verify it for your SKUs before you call the risk closed.
I’d suggest a half-day tabletop this month: pick one CRM or ITSM connector, walk Security through the Tools list and a live confirmation card, write the Always-allow rule into the acceptable-use guide, and only then expand staged rollout. Once people have seen what “Allow once” actually sends, the Steady habit tends to stick.
DIGITAL SKILL WORKS LTD / 12 PANES · You ask, we answer