Your Copilot Is About to Get Delete Permissions in Someone Else’s SaaS

A user types “clean up the stale tickets in that project” into Copilot Chat. Twelve tickets vanish from Jira. The person who ran the prompt couldn’t tell you which API call did it, and neither can you, because the record of what happened lives in a system your tenant doesn’t own.

That scenario is not possible today. It becomes possible under Microsoft 365 Roadmap ID 570964, which says federated Copilot connectors — the Model Context Protocol kind — will support create, update, and delete actions in third-party services. Today they read. Soon they write. That’s the whole story, and it’s bigger than it looks.

What’s live now: read-only, and that matters more than it sounds

First, the distinction that trips people up. A Microsoft Graph connector indexes external content into your tenant so search and Copilot can retrieve it. It’s a librarian — it brings copies home and stands them on a shelf. A federated MCP connector is a remote control: the third party exposes functions, Copilot invokes them, and the third party runs them. The action executes over there, not here. That architectural difference is the entire risk conversation.

Right now those federated connectors retrieve. Copilot can summarise a Salesforce opportunity or pull a Jira status. It cannot change either. That read-only posture is doing a lot of governance work you probably haven’t clocked, because “worst case, Copilot reads something it shouldn’t” is a data-exposure problem you already have controls for. It is not the same class of problem as “Copilot deleted production data on a hunch.”

The next beat: 570964 moves the boundary

Write, update, and delete in external services, invoked from Copilot Chat. The roadmap describes the capability; at time of writing it does not pin a GA date or spell out the exact licensing tier, so don’t quote one to your CISO. Treat it as “coming,” not “shipped.”

Because the roadmap gives you the what and almost none of the how, the honest move is to turn the gaps into questions and answer them from documentation as it lands — not to guess. Two you need answered before this reaches your tenant:

• The approval model. Federated connectors are meant to be deployed and governed by admins, not self-served by users from chat. Check where that governance actually lives — which admin center, which role. And confirm whether a connector’s write scope requires a separate consent step from its read scope, because “approved to read” should never silently become “approved to delete.”
• The audit trail. Confirm what your tenant actually captures when Copilot triggers a connector action, and where — Copilot activity logs, Purview, or nowhere useful. Then remember the destructive action itself executes in the third-party service and gets logged there, under whatever identity the connector authenticates as. If that’s a shared connector identity, your Jira log says “the integration did it,” full stop. Attribution back to the human who typed the prompt and the effect in the SaaS are two separate records. Assume nobody stitches them together for you.

The pre-work is boring and correct: enumerate your federated connectors and establish exactly what Copilot activity your tenant is already logging, before write scopes arrive.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# Illustrative starting point: this is NOT confirmed to be where Copilot
# connector activity surfaces. Sign-in logs may not capture connector
# invocations at all. Use it to explore your baseline, then replace with
# the correct workload once documented. Requires AuditLog.Read.All.
Connect-MgGraph -Scopes "AuditLog.Read.All" -NoWelcome
​
$start = (Get-Date).AddDays(-7).ToString("o")
$uri   = "https://graph.microsoft.com/v1.0/auditLogs/signIns?`$filter=createdDateTime ge $start"
​
try {
    do {
        $page = Invoke-MgGraphRequest -Method GET -Uri $uri -ErrorAction Stop
        $page.value | Where-Object { $_.appDisplayName -match 'Copilot' } |
            Select-Object createdDateTime, userPrincipalName, appDisplayName, clientAppUsed
        $uri = $page.'@odata.nextLink'
    } while ($uri)
}
catch {
    Write-Error "Audit query failed: $($_.Exception.Message)"
}

The next dated beat is 570964 flipping from “in development” to “rolling out.” When it does, the question your incident review will ask is not did Copilot have access — it’s who authorised the delete, and can you prove it from your own logs. Have that answer written down before the connector does.