You ask, we answer · 11 September 2026
Are Copilot Graph connectors safe to turn on?
Vendors and makers want ServiceNow, Jira, and file-share connectors so Copilot can ‘see everything’. Security hears ‘we’ll index our crown jewels into Microsoft Graph’. Is that amplification risk — or the controlled grounding path Microsoft intends?
Grounded with: Microsoft Learn — Data privacy and security for extending Microsoft 365 Copilot; Microsoft 365 Copilot connectors overview; Configure connectors in the Microsoft 365 admin center; Federated Copilot connectors overview
DIGITAL SKILL WORKS LTD / 12 PANES
You’re right to flinch when someone says “just connect the CRM.” Copilot connectors are powerful precisely because they widen what grounding can see — and Schofield’s Third Law (historically attributed) reminds us that easier access for you is easier access for someone else if the ACL is wrong.
Here’s what’s going on. Synced Microsoft 365 Copilot connectors ingest external content into Microsoft Graph inside your tenant. Copilot (and Search) then ground on that content using the same user-identity access boundary as the rest of Microsoft 365 — Graph only returns items the signed-in user is allowed to see, driven by the ACL you associate (Entra users/groups or external groups). Prompts, responses, and Graph-accessed data aren’t used to train foundation LLMs. Admins must create and enable connectors; makers can’t silently index the estate. Federated connectors (where available) fetch live without copying into Graph and enforce permissions in the source system — different trust shape. Agents that call your APIs are another pattern again: that data stays in your app unless you chose a synced connector.
So the risk isn’t “Microsoft trains on our Jira.” The risk is indexing oversharing: a connector identity that can read too much, ACLs mapped to Everyone, or a connection enabled tenant-wide before you’ve sampled results.
Practical options:
- Pilot one connector with tight ACLs and a named admin owner. Prefer a low-sensitivity knowledge base first. Verify in Copilot Search/Chat that User A sees item X and User B does not. Best Wave 0 move.
- Treat connector enablement like a change record. Who approved the source system scopes, crawl account, item quota, and semantic labels? Keep an inventory next to your agent register. Moderate effort; stops “helpful” shadow connections.
- Prefer federated or Power Platform real-time connectors when you must not copy data into Graph — accepting source-system latency and auth complexity. Use when Legal won’t accept a second copy of the dataset.
- Turn on everything in the gallery because adoption metrics. Maximises grounding theatre and maximises blast radius when one ACL is wrong.
The caution: deployed synced connectors are often tenant-wide unless item security is restricted correctly — “configured” ≠ “safe.” Indexing quota and freshness matter for answer quality; garbage in still becomes confident garbage out. Declarative agents that ground on untrusted ticket text bring prompt-injection risk Microsoft documents explicitly — don’t wire high-privilege actions to messy external content without human gates. And connectors for Copilot Studio knowledge still need the admin connection present plus the right auth scopes on publish.
I’d suggest a Steady Security rule: no new synced connector without an ACL test plan, a data-owner sign-off, and a rollback owner. That is Steady before scale — grounding earns trust; it doesn’t inherit it from the vendor brochure.
You’re asking the right questions. Once you understand the Graph copy + ACL model, you’ll spot the pattern every time someone proposes “one more source.”