LearnMicrosoft 365 Copilot › 1 · Foundations

The data boundary: where prompts go and what trains on what

The meeting every admin eventually sits in: 'is our data safe in Copilot?' Here is the boundary, drawn precisely — processing, storage, residency, training — with the proofs, and the places where YOUR configuration decides.

The boundary, drawn

  • Processing: prompts, retrieved content and responses are processed inside the Microsoft 365 service boundary under your existing DPA/product terms — the same contractual perimeter as Exchange and SharePoint themselves. Copilot did not create a new data relationship; it inherited the one you already signed.
  • Training: tenant prompts/content are not used to train foundation models. The model is a stateless component (foundations concept). What "improves" over time is the product around it, not a model fed on your mail.
  • Storage: the durable artifacts are the ones YOU govern — interaction records in mailboxes (retention-scoped), Copilot-created content (Pages, drafts) in your stores, agent knowledge where you put it. Delete-ability follows those stores' rules, not new ones.
  • Residency: processing honours your tenant's commitments (EU Data Boundary where applicable); model capacity is regional. For regulated conversations, cite the current product terms for YOUR geo — terms, not blog posts (the Teams residency concept's rule applies verbatim).

Where configuration moves the boundary

Switch What it changes
Web grounding toggle (org + per-user) Whether prompts may be sent to Bing for web results — the one place data leaves the M365 boundary; off = work-only grounding
Connected experiences / optional connected experiences The classic Office privacy controls still apply around Copilot surfaces
Graph connectors YOU are importing external data INTO the boundary — its index copy inherits M365 governance
Agent actions An API-calling agent sends conversation context to endpoints you registered — the boundary is your review of that manifest (agents module)
DLP for Copilot Sensitivity-labeled content can be excluded from grounding — your boundary within the boundary

The honest framing for the exec meeting: the risk is rarely 'Microsoft sees our data' — it is 'our own users see our own data, faster' (oversharing concept) and 'we wired an agent to something we didn't review' (agent governance concept).

What to watch (proofs)

  • The web-grounding stance: the admin center Copilot settings page value + its audit-log change history — the only boundary-crossing toggle, monitored.
  • The recording reality: one eDiscovery hit on a Copilot interaction — processing produces governable records, shown not asserted.
  • Terms as artifacts: the Product Terms / DPA sections for Copilot saved with date into the compliance file — the citation your regulator conversation needs.
  • Agent egress inventory: the registered endpoints of every deployed agent — the actual list of places conversation context can travel (agents module's registry).

The wire

  • Default: prompt/grounding/response inside the M365 service boundary
  • Web grounding ON: query terms to Bing (the one outbound edge, org-controllable)
  • Agent actions: context -> endpoints YOU registered

Discussion

No messages yet — start the thread.

Sign in with your email to join the discussion — we send a one-time link, no password.