Microsoft Copilot privacy policy
The policy says "HR data stays in HR". 200 people can open the folder.
A Copilot privacy policy is a statement about permissions, and in a typical tenant the permissions do not match the document: payroll folders shared with the whole company, sensitive sites Copilot indexes, agents nobody registered reading mail. 1Security shows which sites, files and agents Copilot can actually reach, constrains what the policy forbids behind a review window, and keeps the numbers that prove the policy is being kept.
The problem
The policy was written. The permissions were never consulted.
Copilot honours your permissions by design - which means your permissions are the policy. It reads whatever the signed-in user can already open, so every stale sharing link, every over-broad group and every forgotten site is one well-phrased prompt away from a summary. A typical user can already reach hundreds of thousands of files.
A privacy policy that says "Copilot must not surface HR or payroll data" is therefore broken the moment 200 people can technically open the salary review folder - no prompt filtering required. In the tenants we connect to, 20-40% of files with sensitive content carry no sensitivity label, and dozens of Copilot-indexed sites hold card numbers, IDs or health data.
Copilot respects your permissions by design, so the tenant-side half of any privacy policy - what those permissions let Copilot read - is yours to govern. Enforcing the policy means mapping that reach, removing what it should not include, and measuring the gap continuously instead of re-discovering it in a generated answer.
In practice
From a document to an enforced state, in four steps.
How a Copilot privacy policy becomes something you can measure in 1Security.
- 01
Map what Copilot can read today
Open Sites, filter to Copilot enabled + with sensitive info, sort by detections. Open Agents to see every Copilot agent employees built or installed, with its reach in files, sites, users and emails and a sensitive-data flag. Together that is the list of places where the policy and reality disagree - typically 30-80 sites and a handful of agents nobody had on a list.
- 02
Constrain what the policy forbids
Enable the suggested automations: block Copilot org-wide search on the sensitive sites the policy names, expire the anyone and organization-wide links on files with sensitive content, restrict the agents with reach into HR or finance. Each stages a proposal per resource behind a 72-hour review window before anything changes.
- 03
Measure the policy as a number
The prebuilt "Sensitive Data Exposure to Copilot" trend counts exposed sensitive files week over week, and Sensitivity Labels shows real label coverage per label - so "our privacy policy is enforced" becomes a chart the privacy office can put in a report, not a paragraph you hope is true.
- 04
Keep the evidence
Copilot and AI-agent activity are entries in Activity logs, retained for up to three years on standard licenses. When the DPO or a regulator asks what AI touched and who could reach it, the answer is a filter and an export, not an investigation.
What makes it work
Three parts of the platform behind the policy.
Enforcing the privacy policy runs on capabilities you can read about in depth.
Copilot security
Every AI agent inventoried, its reach quantified in files, sites, users and emails - before rollout, not after the first bad answer.
Explore the feature →SharePoint governance
The sites Copilot indexes, ranked by sensitive content and exposure, with staged site-level automations to block Copilot search where the policy says so.
Explore the feature →Reporting
Label coverage, exposure counts and AI activity as live, exportable numbers for the privacy office and the auditor.
Explore the feature →
FAQ
Common questions.
Is this Microsoft's Copilot privacy policy?
No. Microsoft's own documentation is the authority on how Copilot handles prompts, responses and chat history. This page is about the complementary half: governing what Copilot can read inside your own tenant, which is decided by the permissions you already manage.
Does 1Security itself send our content to an AI?
No. File and email content is streamed into analysis and discarded; only the detection type, match count and confidence are kept, and the matched values themselves are never written to the database. Detection is deterministic, and no third-party AI service sees file content in the default configuration.
Copilot already respects permissions. Why is more needed?
Because the permissions are the problem. Copilot only surfaces what the signed-in user can already view, so the risk lives in years of accumulated grants, links and group memberships. Enforcing a privacy policy means fixing that reach, and fixing it needs a map of it.
Do we need a premium license or Purview for this?
No. Sensitive-data detection is 1Security's own engine, on standard Microsoft 365 licenses. If you run Purview, its labels and detections are synced in and shown alongside, and the coverage gap is measured against them.
Make the privacy policy true in the tenant.
Connect read-only and see what Copilot can reach today. Then constrain what the policy forbids, with a review window in front of every change - on standard Microsoft licenses.
Or keep hoping the permissions match the document.