"Can Copilot read my emails?" is the question staff actually ask when Microsoft 365 Copilot arrives, and the news cycle has made it harder to answer, not easier. The accurate answer is short: yes, Copilot can read your mailbox, because you can, and that is the whole rule. It works with your identity and your permissions. It cannot open anything you cannot open, and a colleague's mailbox is invisible to it unless that mailbox was shared with you. The rest of this piece unpacks how that boundary works, what the February 2026 bug was and why it made headlines, and the controls that narrow what Copilot can reach.
The one rule: your permissions are the boundary
Microsoft 365 Copilot answers questions by retrieving your organisation's content through Microsoft Graph, the same layer Outlook and SharePoint themselves use. Retrieval happens at the moment you ask, under your signed-in identity, and Microsoft's permission model applies at that moment: Copilot can only surface data the signed-in user is already authorised to see. It has no separate account, no master key and no standing copy of the mailbox. Ask it to summarise your unread mail and it reads your inbox the way you would; ask it what your colleague was emailed yesterday and it has nothing to retrieve.
The same rule answers the common variants. Shared mailboxes you are a member of: visible, because you have access. A mailbox delegated to you by your manager: visible, for the same reason. A meeting you were not invited to: the recording and transcript are invisible unless someone shares them with you. Prompts and responses stay inside the Microsoft 365 service boundary, and Microsoft does not use them to train its foundation models.
The honest caveat is on the other side of the boundary: in most tenants, "what you can open" is more than anyone remembers granting. Years of "anyone in the organisation" sharing links and open SharePoint sites mean Copilot sometimes surfaces things a user technically could always see but never went looking for. That is a permissions problem wearing an AI costume, and Frontrow has covered it in detail at /insights/how-copilot-inherits-sharepoint-permissions.
What the February 2026 bug actually was
In February 2026 Microsoft confirmed a bug, tracked for admins as CW1226324, in which draft and sent emails carrying a confidential sensitivity label were incorrectly processed by Microsoft 365 Copilot Chat. The behaviour had been occurring since January, and it happened even in organisations with data loss prevention policies configured to keep labelled content away from Copilot. In plain terms: a control customers had deliberately switched on was not being honoured for those items. Microsoft rolled the fix out through February 2026 and the incident is resolved.
Two things are worth keeping separate. The bug was not Copilot reading other people's mail; the permission boundary above was never what failed. What failed, temporarily, was a refinement layer on top of it, the one that tells Copilot to leave certain of your own items alone. That distinction matters for drawing the right lesson: the answer to "whose email can Copilot see" did not change, and the incident is instead the strongest argument for the section that follows, because controls you rely on deserve layers and verification, not assumption.
How to limit what Copilot can reach
For a business that wants Copilot's usefulness with a narrower reach, the controls stack, and each covers a different failure mode:
- Sensitivity labels with encryption. Content labelled so that a user lacks extraction rights is off limits to Copilot for generating answers, even when the user can open the item. This is the strongest per-item control because it travels with the content.
- Purview data loss prevention. DLP policies can keep items carrying particular labels out of Copilot processing, tenant-wide, without touching who can open what.
- Restricted Content Discovery. For SharePoint sites too sensitive or too messy for AI retrieval, RCD flags the site so its files stop surfacing through Copilot and organisation-wide search, while people with access can still open them directly.
- Permissions hygiene. The controls above refine the boundary; the boundary itself is who can access what. Cleaning up open sites and stale sharing links shrinks what Copilot can reach for every user at once.
The order matters. Labels and DLP assume someone has decided what is sensitive; RCD buys time for the sites nobody has classified yet; permissions hygiene is the floor under all of it. Frontrow's broader treatment of the data-security question sits at /insights/is-microsoft-365-copilot-safe-company-data.
What your employer can and can't see of your prompts
The question runs the other way too: staff want to know whether managers are reading their Copilot conversations. The practical answer: there is no live feed. The admin reporting managers see shows usage, which features and how often, not the text of prompts. Your prompt and response history is stored with your mailbox data, and its contents are reachable by the organisation only through compliance tooling, Purview audit and eDiscovery, which requires specific privileged roles and leaves its own audit trail. In other words, your Copilot history has roughly the discoverability of your email itself: private from casual view, producible in an investigation. The sensible working assumption in any workplace is the one that has always applied to work email.