Phase 2 · Microsoft Copilot · Level 3 · Power User
What Copilot can and can't see, and the conversation to have with IT
By the end, you'll be able to…
- Explain what Copilot can and cannot access, and why it can never show you more than you could already open
- Name the three governance levers IT controls: permissions, DLP and external-content restrictions
- Have an informed conversation with IT about making Copilot and your agents safe to roll out
Why it matters
As soon as you build agents other people will use, you stop being just a user and become someone who has to think about safety. The good news is that Copilot's core safety model is simpler and stronger than most people assume: it can't show anyone anything they couldn't already open. The catch is that this makes existing permission sloppiness suddenly visible. This lesson gives you the accurate mental model and the exact questions to raise with IT before you roll anything out.
The one rule that governs everything
Start with the single most important, most reassuring fact, because almost every worry about Copilot dissolves once you hold it clearly: Microsoft 365 Copilot only ever shows a person data that that person already has at least permission to view. It works inside your organisation's existing permissions and access controls, the same ones that decide what you can open in SharePoint, Teams, Exchange and OneDrive. The underlying grounding process honours your identity's access boundary, so it reaches only content you're authorised to reach.
In plain terms: Copilot is not a magic key. It cannot conjure a document you couldn't already find, read a mailbox you can't open, or surface a file that's locked away from you. If you can't see it, neither can Copilot on your behalf. That's true for the agents you build too: a declarative agent grounded on a SharePoint site can only show a given user what that user was already allowed to see.
So why does Copilot raise governance concerns at all? Because it doesn't widen access; it makes existing access efficient. Content that was technically open to you but buried five folders deep, or in a site nobody remembered you'd been added to, was always accessible; you just never stumbled on it. Copilot finds it in seconds. It doesn't break the permission model; it shines a bright light on wherever that model was already too loose. This is why the phrase to remember is: Copilot turns latent oversharing into visible oversharing. The fix is not to distrust Copilot; it's to tidy the permissions that were always a bit too generous.
Licence note: the governance controls below are largely admin and Microsoft Purview features your IT team manages, and the Copilot experiences they govern generally need a Microsoft 365 Copilot licence. You won't configure most of this yourself. The goal of this lesson is to let you have the conversation, not to run the console.
The three levers IT controls
When you talk to IT about rolling out Copilot or an agent, three levers cover most of what matters. Knowing their names turns a vague "is this safe?" into a specific, productive conversation.
1. Permissions: who can see what
This is the foundation, and it's the one your work touches most directly. Because Copilot respects existing permissions, the quality of those permissions is the quality of your Copilot safety. The questions worth raising:
- Are there SharePoint sites or shared libraries with far broader access than they should have, such as "the whole company" on something that should be one team?
- Before pointing an agent at a site, has anyone checked who can already see that site's content?
- Is there a review of oversharing, such as old links shared with "anyone" or sites with sprawling membership, before a wide Copilot rollout?
You don't fix these yourself, but flagging them is exactly the kind of thing a Copilot champion is placed to notice.
2. Data Loss Prevention: content Copilot must not use
DLP (Data Loss Prevention), delivered through Microsoft Purview, lets IT set rules about how sensitive content is handled. For Copilot specifically, a DLP policy can tell Copilot not to use certain content when generating answers, for example files carrying a particular sensitivity label. Such an item may still appear as a citation, but its actual content isn't read into the response. DLP can also block external web search as a grounding source when a prompt itself contains sensitive information types like card or passport numbers. The questions for IT:
- Do we have sensitivity labels, and should Copilot be blocked from using the most sensitive ones in its answers?
- Are the DLP policies that apply to the rest of Microsoft 365 extended to cover Copilot and Copilot agents?
3. External-content restrictions: the walls around the outside world
The third lever governs the boundary between your internal, grounded content and the open web (and other external sources). IT can restrict when Copilot reaches out to the web, and SharePoint controls such as restricted content discovery can keep specific sites out of Copilot's reach even for people who technically have access. The questions:
- Should web grounding be limited for sensitive workflows or particular groups?
- Are there sites whose content should be excluded from Copilot discovery even though permissions technically allow it?
- For an agent shared beyond our team, what external content, if any, should it be allowed to touch?
A worked example: rolling out the policy agent safely
Take the Remote-Working Policy agent from the first lesson. It's harmless-looking, just one public-ish policy document, but the governance thinking is identical for anything bigger, so it's a good rehearsal. Here's the prompt you'd use to prepare for the IT conversation, treating Copilot itself as a thinking partner:
I'm about to share a Copilot agent grounded on a SharePoint site with my whole department. Draft me a short pre-rollout checklist to review with IT, organised under three headings: permissions (who can already see the source content), data loss prevention (sensitivity labels and DLP policies that should apply), and external-content restrictions (web grounding and site discovery). Keep it to questions I can actually ask in a 20-minute meeting.
Why this works: It turns a vague 'is this safe?' worry into a concrete, ordered checklist you can walk through with IT, naming the three levers explicitly so nothing important is left to memory in the meeting.
The output gives you a structured agenda. The point isn't that Copilot decides your governance. It's that you walk into the IT meeting with the right three headings and specific questions under each, rather than a general unease. Then you do the human part: confirm who can see the grounding site before you widen the share, because the agent will faithfully respect whatever those permissions currently are, generous or tight.
More example prompts
I'm about to enable Copilot more widely for my team. Help me spot oversharing risks first: what questions should I ask about SharePoint sites and shared libraries that might have far broader access than intended, old "anyone with the link" shares, and sites with sprawling membership? Frame them as things I can raise with IT, and explain why each matters specifically because Copilot makes accessible-but-buried content easy to find.
Why this works: It asks the questions that catch loose permissions, the real risk Copilot exposes, so you review access before a rollout makes buried content findable, not after.
Draft a short, reassuring explanation for my colleagues about what Microsoft 365 Copilot can and can't see. Make clear it only shows each person content they already have permission to open, that it can't access files they couldn't already find, and, honestly, that it can make already-overshared content easier to stumble on, which is why we're tidying permissions. Plain UK English, about 120 words, no jargon.
Why this works: A clear, reassuring explanation for colleagues heads off both the 'it can read everything' fear and the opposite complacency, grounding the message in the real permission rule.
Try it now
Common mistakes
- Believing Copilot can leak data it wasn't given access to. It can't; it works strictly within your existing permissions. The real risk is the opposite: it efficiently surfaces content that was already overshared.
- Assuming a clean rollout needs no permission review. Because Copilot makes buried-but-accessible content findable, a rollout onto messy permissions exposes that mess fast. Review access before, not after.
- Treating DLP and labels as IT's problem alone. You don't configure them, but as the person building and sharing agents you're best placed to flag which content should never be used in answers. Raise it.
- Over-trusting an agent to be "safe because it's internal". Internal and grounded is not the same as governed. An agent shared widely with no permission or DLP review can confidently serve sensitive content to people who merely happened to have loose access, and it will do so fluently, giving no sign anything is wrong. The safety is in the governance you set up front, not in the agent's good manners.
Keeping current
Purview, DLP-for-Copilot and SharePoint discovery controls evolve steadily, and admin capabilities in particular change release to release. Treat specifics as a July 2026 snapshot and confirm current behaviour with your own IT team. Microsoft's reference points are Data, Privacy, and Security for Microsoft 365 Copilot, Security for Microsoft 365 Copilot and Microsoft Purview DLP for Microsoft 365 Copilot. Accurate as of 13 July 2026.