You ask, we answer · 17 September 2026

Why does Copilot Studio block Knowledge uploads with a data policy error?

Makers say they can’t upload a PDF or add SharePoint knowledge in Copilot Studio — everything says blocked. What do we tell them, and which connectors does Security actually need to allow?
agentsgovernancesecuritycopilot-studiowave-0

Grounded with: Microsoft Learn — Configure data policies for agents; Troubleshoot data policy enforcement; Add unstructured data as a knowledge source

DIGITAL SKILL WORKS LTD / 12 PANES


You’re right to treat this as an admin policy problem, not a maker skill gap. When Knowledge lights up red overnight, it’s almost always a data policy — not a broken upload button.

Here’s what’s going on. Copilot Studio enforces Power Platform data policies in real time for all tenants (Message Centre MC973179; exemptions ended). Knowledge isn’t one switch: Learn maps each source to a named connector — Knowledge source with documents in Copilot Studio for local file uploads, Knowledge source with SharePoint and OneDrive in Copilot Studio for SharePoint/OneDrive via Upload files, and Knowledge source with public websites and data in Copilot Studio for public sites. Blocking Documents only stops local uploads; SharePoint/OneDrive still need their own connector allowed (and in the same data group as other connectors the agent uses). Connectors often land in the default Non-business group, which many tenants auto-block. Makers see an error banner; on Channels they can Download a workbook listing the policy name, blocked connector, and violation type. Publish stays unavailable until the policy or the agent aligns.

This is Third Law for agent grounding: the easier it is to paste any file into Knowledge, the easier it is for that content to leave via generative answers. Steady before scale means Pane 04 Security designs which knowledge paths are Business — then makers follow a request path instead of arguing with a red banner.

Options that actually work:

  1. Allow named Knowledge connectors in governed environments. Put Documents and/or SharePoint+OneDrive in Business for production/sandbox environments that own approved agents; keep them Blocked in Default and open maker playgrounds. Best Steady default.
  2. Endpoint filtering instead of a blanket allow. For SharePoint or public websites, configure connector endpoints so only approved site patterns work. More work; less blast radius.
  3. Tell makers to “just use SharePoint” while Documents stays blocked. Fine if intentional — Learn is explicit that blocking Documents does not block SharePoint/OneDrive. Document that so tickets stop bouncing.
  4. Ignore production agents after a tenant-wide Non-business block. Quiet until published agents throw DataLossPreventionViolation for end users. Don’t.

12 Panes action / comms: Give makers a one-pager: download the Channels workbook → send policy name + connector to the AI admin alias. Leadership line: we’re not anti-Knowledge — we’re choosing which grounding paths are Business before seat spray.

Benefits / risks: Clear connector allow-lists stop accidental public-web grounding and mystery blocks; over-blocking every Knowledge connector freezes useful agents and drives shadow tools. Tenant-scope policies hit every environment — review production agents after any change.

I’d suggest this week: open Power Platform admin centre → Security → Data and privacy → Data policy, search the three Knowledge connectors, decide Business vs Blocked per environment group, then ask makers to re-test and re-download Channels if Publish is still grey. You’ll have a calmer maker queue when the policy matches the architecture.

DIGITAL SKILL WORKS LTD / 12 PANES · You ask, we answer

All answers Ask a question