SELINA.ai
Sign in

Is Copilot Safe? What It Actually Accesses, Retains, and Exposes

If you're an IT or security lead evaluating Microsoft 365 Copilot, the question "is copilot safe" probably lands somewhere between your third and fifth agenda item. It shouldn't. Copilot doesn't introduce new permissions. It does something worse: it makes your existing permission mistakes instantly queryable by every employee with a license. The gap between what Microsoft's marketing implies and what the architecture actually does is worth understanding before you flip the switch. We build a privacy-focused AI assistant ourselves, so we think about these tradeoffs constantly. Some of what follows is sourced from public research and CVE disclosures. Some of it comes from watching the same design tensions play out in our own product.

Key Takeaways

What Does Copilot Actually Access?

Copilot queries the Microsoft Graph on behalf of the signed-in user. That means every SharePoint site, every OneDrive folder, every Teams message, every email thread the user's Entra ID token can reach. Copilot doesn't grant any new access. It inherits whatever already exists. This is the core architectural choice, and it's worth sitting with for a moment.

Before Copilot, overshared data was a latent problem. A finance spreadsheet shared org-wide sat in a SharePoint library that nobody outside finance ever navigated to. The practical obscurity of bad permissions acted as a de facto control. Copilot removes that obscurity. An employee types "what were Q3 margins?" and Copilot dutifully retrieves the spreadsheet, because the permissions say it can.

Concentric AI's Data Risk Report found that 16% of business-critical data is overshared, with an average of 802,000 files at risk per organization. Metomic's research corroborates this from a different angle: over 3% of business-sensitive data was shared organization-wide without any assessment of whether it should have been. These numbers existed before Copilot. Copilot just made them exploitable at natural-language speed.

Does Copilot Use Your Data to Train Models?

No, per Microsoft's stated policy. Microsoft's Enterprise Data Protection documentation commits that prompts, responses, and Graph-accessed data are not used to train foundation models. This is a contractual and policy commitment. It is not an architectural constraint of the AI system itself. The distinction matters. A policy can be updated. An architectural constraint requires a redesign.

We think about this same tension in our own product. Selina runs on a stack of frontier models, routed per task, via API. That means a slice of each request reaches a frontier provider at inference time. Memory is encrypted at rest, but it is not end-to-end encrypted, because the inference step requires the provider to process the content. We state this plainly because the alternative is letting users assume something stronger. Microsoft's EDP framework is more detailed than most vendors offer, but it's still a promise layered on top of a system that structurally requires data to flow through a model provider.

What Happens When Sensitivity Labels Meet Copilot?

They degrade. Copilot outputs don't consistently inherit the sensitivity labels of their source documents. A summary generated from a "Confidential" document may arrive with no label at all. The burden of catching this falls on the employee, which in practice means it doesn't get caught.

This is a proxy for a deeper architectural question that applies to every AI system, ours included: does provenance survive transformation? When a model reads a classified source and produces a derivative output, does the output carry forward the data lineage and classification of the input? In most current architectures, the answer is no. The model generates tokens. It doesn't stamp them with the metadata of every document that influenced the generation. Microsoft's labeling infrastructure (Purview, sensitivity labels) is more mature than what most vendors offer, but the gap between "labels exist on source documents" and "labels persist through AI-generated derivatives" is real and largely unsolved across the industry.

How Bad Are the Vulnerabilities?

Bad, and patterned. This is not a story about isolated bugs. It's a recurring architectural tension between "broad standing access" and "untrusted content flowing through the same channel."

EchoLeak (CVE-2025-32711), disclosed in June 2025, was a zero-click vulnerability triggered by a single inbound email. No user interaction required. The email's content was enough to cause Copilot to exfiltrate data.

SearchLeak (CVE-2026-42824), disclosed roughly a year later, chained three separate flaws into one exfiltration path: a prompt injection, a rendering race condition, and a server-side request forgery. One click was enough to steal emails, files, and MFA codes.

In between, a zero-click Excel/Copilot Agent exfiltration bug (CVE-2026-26144) used a cross-site scripting flaw to cause Copilot Agent mode to exfiltrate data via unintended network egress. No user action needed.

In May 2026, Microsoft patched three more critical information-disclosure CVEs in Copilot and Copilot Chat in Edge in a single batch. These were mitigated at the service layer, so enterprises didn't need to install anything, but Microsoft still advised reviewing Copilot's data access permissions and enforcing least-privilege principles.

The pattern is clear. Each patch addresses one link in a chain. The underlying architecture (standing access combined with untrusted content flowing through natural-language processing) keeps producing new exploit paths.

Is Prompt Injection a Permanent Vulnerability Class?

For agentic systems with broad standing access, yes, it likely is. Capsule Security's research explicitly frames prompt injection in agent platforms as a vulnerability class that patches alone cannot eliminate. Microsoft's decision to assign a CVE to a prompt injection in Copilot Studio (CVE-2026-21520) was called "highly unusual" by the researchers, and for good reason. If that precedent extends to agentic systems broadly, every enterprise running agents inherits a vulnerability class that cannot be fully patched away.

The structural issue: an agent that can read arbitrary documents and take actions based on their content is, by design, executing instructions from potentially untrusted sources. You can filter known injection patterns. You can sandbox certain actions. But the fundamental tension between "read everything the user can read" and "don't execute malicious instructions embedded in what you read" is not something a patch resolves. It's a design tradeoff.

This is why, in our own architecture, we scope context windows tightly and treat any state-changing action with more friction than a passive query. Not because we've solved prompt injection (nobody has), but because minimizing standing access and requiring explicit consent for actions reduces the blast radius when an injection does land.

What Does "Agentic Copilot" Change About the Risk?

It raises the stakes from information disclosure to autonomous action. Standard Copilot responds to queries and surfaces existing overpermissioned data but does not act autonomously. An agent built in Copilot Studio executes tasks without continuous human involvement. It can act on permission gaps, modify data, or trigger workflows.

Same permission surface. Higher potential impact. If a passive Copilot query can leak a confidential spreadsheet, an autonomous agent operating on the same permissions can forward that spreadsheet, update it, or feed it into a downstream workflow. The risk isn't theoretical. The Excel zero-click bug already demonstrated Copilot Agent mode exfiltrating data via network egress without user interaction.

Several Purview governance capabilities relevant to agents (DLP for Copilot prompts, DSPM agent observability, Insider Risk Management for Agents) are still in preview as of mid-2026. Preview features may change before general availability and aren't covered by production SLAs. If you're deploying agents today, you're governing them with tools that Microsoft itself considers pre-release.

What Should You Do Before Turning Copilot On?

Fix your permissions. This is boring advice and it is the only advice that matters.

SharePoint Advanced Management (SAM) is now bundled with a Copilot license and is Microsoft's primary recommended remediation path. It gives you site access reviews, Restricted Content Discovery, and baseline oversharing reports. Without SAM or equivalent tooling, you're deploying a natural-language search engine on top of a permission structure you haven't audited.

Microsoft 365 E5 alone provides Data Access Governance reports capped at 10,000 sites with no remedial actions. SAM adds the ability to actually do something about what you find. The gap between "visibility" and "remediation" in the E5-only tier is significant.

Concrete steps, in order of priority:

  1. Run a SharePoint oversharing audit. Identify sites, libraries, and files shared org-wide or with "Everyone except external users." The numbers will be worse than you expect.
  2. Enforce least-privilege on Entra ID. Review group memberships, remove stale access, and move from broad security groups to scoped access policies.
  3. Enable and enforce sensitivity labels on your highest-risk document libraries before Copilot goes live. Know that labels on outputs remain unreliable, but labels on source documents at least limit initial access.
  4. Scope your Copilot rollout. Start with a pilot group whose permissions you've actually audited. Treat org-wide deployment as a milestone, not a starting point.
  5. Monitor for prompt injection attempts. This is an emerging practice and tooling is immature, but logging Copilot interactions through Purview (where available) gives you at least a detection surface.

How Does Microsoft's Data Protection Compare to Running Your Own AI Stack?

Microsoft's EDP framework is more explicit than what most enterprise AI vendors publish. The privacy documentation states clearly that prompts and responses are not used for model training, that data is processed within the Microsoft 365 compliance boundary, and that existing tenant-level controls (retention policies, eDiscovery, audit logs) apply to Copilot interactions. This is genuine, and it's more than many competitors offer in writing.

The gap is structural, not contractual. Copilot's design philosophy is "inherit ambient permissions and make everything discoverable." If your org has clean permissions, this is powerful. If your org has the typical 802,000 overshared files, this is a searchable exposure surface.

We made different tradeoffs with Selina. The assistant remembers you across conversations (adaptive memory, encrypted at rest), but it doesn't have ambient access to an entire corporate document graph. Context is scoped per conversation. Files shared through SelinaSEND use zero-knowledge encryption. These are architectural choices, not just policy commitments, and they come with their own costs: Selina can't do what Copilot does in terms of cross-referencing your entire tenant. The tradeoff is real in both directions.

What's the Honest Assessment?

Copilot is not unsafe by design. It is unsafe by default in most real environments, because most real environments have oversharing problems that predate Copilot by years. The product faithfully respects the permissions you've set. The problem is that the permissions you've set are probably wrong.

The vulnerability pattern (EchoLeak, SearchLeak, the Excel zero-click, the May 2026 batch) suggests that prompt injection in systems with broad standing access will keep producing novel exploit chains. Microsoft patches them quickly. But "quickly" still means there's a window, and the next variant is already being researched by someone.

The agentic direction raises the stakes further. An agent that can act on overshared data is categorically more dangerous than a chatbot that can surface it. If you're evaluating Copilot Studio agents, treat the governance tooling maturity as a blocking concern, not a nice-to-have.

The sensitivity-label inheritance gap is underappreciated. Even if you've invested heavily in Microsoft Information Protection, Copilot-generated outputs can silently bypass your classification scheme. This is not a solved problem, and it's not unique to Microsoft. Any system that transforms classified content into derivative outputs faces this. But Microsoft's labeling ecosystem is mature enough that users reasonably expect it to work end-to-end, and it doesn't.

If you're deploying Copilot: fix permissions first, scope the rollout, and treat agent features as a separate risk tier requiring separate approval. If you're comparing architectures, look at whether the product inherits ambient permissions or requires explicit scoping. That single design decision drives most of the risk differential.

If you want to see how we handle the same tradeoffs differently: start a free 7-day trial, no card required.

Frequently Asked Questions

Does Copilot create new security permissions or access paths?

No. Copilot inherits the existing Microsoft 365 and Entra ID permissions of the signed-in user, querying the Microsoft Graph for whatever SharePoint, OneDrive, Teams, and email content that user can already reach. It simply makes existing overshared or misconfigured permissions instantly queryable at conversational speed.

Does Microsoft use Copilot data to train its AI models?

No, per Microsoft's stated Enterprise Data Protection policy, prompts, responses, and Graph-accessed data are not used to train foundation models. However, this is a contractual and policy commitment rather than an architectural constraint built into the system itself.

Do sensitivity labels carry over to Copilot-generated content?

Not reliably. A summary generated from a document labeled 'Confidential' may come out with no label at all, since Copilot doesn't consistently stamp outputs with the classification metadata of the source documents that informed them.

How serious are the known Copilot security vulnerabilities?

Serious and recurring, including EchoLeak, SearchLeak, and a zero-click Excel exfiltration bug, which chained prompt injection, rendering flaws, and server-side request forgery to exfiltrate data with little or no user interaction. These form a pattern showing that broad standing access combined with untrusted content flowing through the same channel keeps producing new exploit paths.

Can prompt injection in Copilot ever be fully patched away?

For agentic systems with broad standing access, likely not entirely. Researchers frame prompt injection as a persistent vulnerability class rather than a one-time bug, since an agent designed to read arbitrary content and act on it is inherently exposed to executing malicious instructions embedded in that content.

Sources & References

Michael C.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

Learn more about Selina.ai