Guide

Rolling out Microsoft 365 Copilot securely: risks and configuration

By Lucas Weber, CyberSec42 · Updated 28 Oct 2026

Microsoft 365 Copilot only shows each person content they could already open. The biggest security risk is therefore usually not Copilot itself, but overly broad permissions in SharePoint, OneDrive and Teams that Copilot surfaces in seconds. A secure rollout starts by cleaning up permissions, classifying confidential data with sensitivity labels, restricting agents and connectors and turning on audit logging before licences are handed out widely.

How Copilot reaches your data

Microsoft 365 Copilot (which Microsoft has since renamed "Microsoft Copilot") connects a language model to the content a person can access in Microsoft 365: email, chats, meetings, files in SharePoint and OneDrive. Microsoft states the principle plainly: Copilot only surfaces organisational data to which the individual user has at least view permissions. According to Microsoft, prompts, responses and data accessed through Microsoft Graph are not used to train the underlying foundation models.

For a security assessment this means Copilot grants no new rights. It does, however, exploit existing rights faster and more thoroughly than any person could. A salary spreadsheet that has sat for years in a Teams folder shared with the whole company was practically invisible. With Copilot, a question about "sales team salaries" is enough.

The layers that shape a Copilot answer

The bottom layer matters most. What is too open there can only be softened in the layers above, not fixed.

1. Permissions and oversharing

Oversharing is the most common reason Copilot rollouts stall. Typical causes are "People in your organization" sharing links, the "Everyone except external users" group on entire sites, broken permission inheritance in libraries, ownerless sites and old project folders that nobody maintains.

Microsoft's deployment guidance recommends a three-step approach that also works well for smaller companies:

• Find the risk. The data risk assessments in Microsoft Purview Data Security Posture Management (DSPM) show overshared sites with sensitive data and risky sharing links. The Content Management Assessment in SharePoint Advanced Management finds sites with oversized audiences, broken inheritance, no owner or no activity. According to Microsoft, SharePoint Advanced Management is included with the Copilot licence.
• Shield in the interim. Restricted Content Discovery removes individual SharePoint sites from organisation-wide search and from Copilot responses. Note that it does not change permissions. People with access keep it. Microsoft explicitly describes it as a temporary control until permissions are cleaned up.
• Fix permissions for good. Delegate site access reviews to site owners, replace organisation-wide links with shares to specific people or groups, repair inheritance and assign an accountable owner to every site.

To stop the problem from growing back, add secure defaults: restrict or disable "Anyone" links at tenant level, apply Restricted Access Control to business-critical sites at creation, and require a sensitivity label for every new site.

2. Data classification and sensitivity labels

Permissions decide who may open a file. Sensitivity labels from Microsoft Purview Information Protection add how confidential a file is, and can encrypt it. For encrypted content, Microsoft states that Copilot honours the usage rights granted to the user.

Three building blocks are particularly effective for Copilot:

• A small, understandable label scheme. For example Public, Internal, Confidential, Highly Confidential. More levels are rarely applied correctly in practice.
• Default and automatic labelling. New documents receive a default label, and typical sensitive content is detected and labelled automatically. Without automation, most of the existing data stays unlabelled.
• DLP policies for Copilot. Microsoft Purview has a dedicated DLP location, "Microsoft 365 Copilot and Copilot Chat". It lets you prevent Copilot from processing files and emails with specific labels when generating responses. Such items may still appear as citations, but their content is not used in the answer. A second rule type stops Copilot from responding to prompts that contain certain sensitive information types, such as card numbers. Microsoft lists this prompt check as preview.

One limitation is worth knowing: according to Microsoft, DLP cannot scan the content of files uploaded directly into a prompt. Only the typed prompt text is checked. That belongs in your usage policy and training.

3. Prompt injection through documents and emails

Copilot reads not only your own content, but also external emails, documents shared by partners and web content. These can hide instructions aimed at the language model rather than the human reader. We cover the mechanism of indirect prompt injection and the structural countermeasures in our guide to prompt injection and tool poisoning. This section focuses on what matters specifically in Microsoft 365.

Germany's Federal Office for Information Security (BSI) warned about indirect prompt injection as an intrinsic vulnerability of application-integrated language models as early as July 2023. Its assessment: language models have no clear separation between data and instructions, and there is no known reliable mitigation that does not also significantly limit functionality.

A publicly documented case shows that this applies to Copilot as well: CVE-2025-32711, published by Microsoft in June 2025 as "M365 Copilot Information Disclosure Vulnerability". Microsoft describes it as AI command injection that allowed an unauthorised attacker to disclose information over a network, and rates it CVSS 9.3 (critical). The researchers who found it published it as "EchoLeak" and described an attack path via a crafted email. According to MSRC, Microsoft fully mitigated the flaw on the service side, customers had no action to take, and the advisory lists no known exploitation.

The takeaway for your rollout is not that Copilot is insecure, but that the trust boundary between external content and your data needs deliberate design:

• Treat external email as untrusted. Microsoft Purview offers a DLP rule that excludes emails from senders outside your accepted domains from Copilot processing. Microsoft explicitly names reducing prompt injection risk as its purpose. The feature is currently in preview. Whether it fits depends on how heavily your team uses Copilot for customer correspondence.
• Know Copilot's own safeguards. Microsoft states that it uses classifiers against jailbreaks and cross-prompt injection attacks (XPIA). The audit log has dedicated fields for them. These safeguards complement your configuration; they do not replace it.
• Review output before acting on it. Answers and drafts based on external content should be checked before they are sent or approved, especially when they contain links, payment details or calls to action.

4. Copilot Studio, agents and connectors

With Copilot Studio, business teams build their own agents that use knowledge from SharePoint, websites or databases and take actions through connectors, REST APIs or MCP servers. That turns an assistant that reads into a system that acts. Our overview of AI agent security covers the general risks of acting agents. For Copilot Studio, four settings are decisive:

• Agent sign-in. Copilot Studio offers three options: "No authentication", "Authenticate with Microsoft" and "Authenticate manually". With no authentication, Microsoft notes that anyone who has the link can chat with the agent. For internal agents, sign-in through Microsoft Entra ID should be the default.
• Whose credentials a tool uses. Each tool runs either with the user's credentials ("End user") or with the author's credentials ("Maker-provided"). In the second case, everyone allowed to use the agent effectively gets the author's rights for that tool. This is the most common source of unintended data exposure in home-built agents.
• Confirmation before actions. According to Microsoft, the option to ask the user before running a tool is set to "No" by default. For tools that write, send or delete, it should be on.
• Data policies in the Power Platform admin center. Admins control which connectors, knowledge sources, HTTP requests, channels and triggers agents may use, and whether sign-in is mandatory. Publishing agents with generative AI features can also be switched off tenant-wide until the rules are in place.

For third-party agents in Microsoft 365 Copilot, admins can review the requested permissions, terms of use and privacy statement under "Integrated apps" in the Microsoft 365 admin center and decide which agents are allowed. Data brought in from other systems through Microsoft Graph connectors only appears in answers if the user has access to it. That makes it all the more important that connector permissions accurately mirror the rights in the source system.

5. Web search, data flows and privacy

When web search is enabled, Copilot derives a short search query from the prompt and sends it to Bing. According to Microsoft, it contains neither the full prompt (except for very short prompts) nor whole documents or Microsoft Entra ID identifiers. These generated queries are, however, governed differently from the rest of your Microsoft 365 data: Microsoft's documentation states that the Data Protection Addendum and the EU Data Boundary do not apply to them and that Microsoft acts as a data controller for them.

That leads to three decisions you should make deliberately:

• Allow, restrict or disable web search. This is done with the "Allow web search in Copilot" policy in the Cloud Policy service for Microsoft 365. If the policy is not configured, Microsoft states that web search is available.
• Exclude sensitive prompts from web search. A DLP rule can block web search for prompts that contain certain sensitive information types. Copilot then answers from internal sources only.
• Review model choice. Microsoft also offers models from other providers in Copilot. According to Microsoft, models provided by Anthropic as a subprocessor are currently excluded from the EU Data Boundary. Admins decide whether to allow them.

For EU users, Microsoft states that Copilot traffic stays within the EU Data Boundary. Involve your data protection officer early all the same: your configuration of web search, models and retention determines which data flows you need to document.

6. Logging and audit

According to Microsoft, Copilot interactions are logged automatically as part of Audit (Standard) in Microsoft Purview, provided auditing is enabled in the tenant. CopilotInteraction records show who used Copilot, when and in which app, and reference the files, sites and emails Copilot accessed to answer, including their sensitivity label. Interactions with custom Copilot Studio agents appear there too.

• Check auditing. Make sure auditing is switched on in the tenant and decide how long audit logs are retained.
• Review with intent. Look for access to content with high sensitivity labels, records with detected jailbreak or XPIA attempts and interactions where Copilot used web search. The latter carry the plugin entry BingWebSearch.
• Set retention for content. Prompts and responses are stored in Microsoft 365. Purview retention policies decide how long they are kept, and eDiscovery makes them searchable.
• Verify the effect. After every measure from sections 1 and 2, check in the audit log that Copilot really no longer uses the shielded content. Microsoft explicitly recommends this validation.

The rollout checklist

A phased rollout has proven itself: first a pilot group whose storage you know well, then the departments whose permissions are cleaned up, and finally everyone else. That way usage does not outpace the clean-up.

What configuration alone cannot answer

The settings on this checklist can be checked in the admin portals. Whether they hold up together only shows in behaviour: does a crafted email reach an agent that writes to another system with the author's rights? Does a connector expose data that only a few people can see in the source system? Does Copilot give a test user content from a site that is supposed to be shielded? No automated scan answers these questions, because the weakness does not sit in a single setting but in the path between external content, model and tool.

That is where our AI and MCP security testing comes in. Within a scope agreed in writing and using test accounts in your tenant, we test your Copilot configuration, your custom agents and their connectors for the attacks an automated scan misses, and back every finding with a reproducible proof of concept. If you also need evidence for customer questionnaires, ISO 42001 or the EU AI Act, see our compliance readiness service.

Frequently asked questions

Further reading

• AI Agent Security: A Practical Overview
• MCP Prompt Injection and Tool Poisoning
• The OWASP Top 10 for Agentic AI, explained
• Service: AI and MCP security testing

Sources

• Microsoft Learn: Data, Privacy, and Security for Microsoft Copilot
• Microsoft Learn: Configure a secure and governed foundation for Microsoft Copilot
• Microsoft Learn: Restrict discovery of SharePoint sites and content
• Microsoft Learn: Microsoft Purview DLP for Microsoft 365 Copilot
• Microsoft Learn: Data, privacy, and security for web search in Microsoft Copilot
• Microsoft Learn: Audit logs for Copilot and AI applications
• Microsoft Learn: Security and governance in Copilot Studio
• Microsoft Learn: Configure user authentication in Copilot Studio
• Microsoft Learn: Add tools to custom agents
• MSRC: CVE-2025-32711, M365 Copilot Information Disclosure Vulnerability
• NIST NVD: CVE-2025-32711
• BSI: Indirect Prompt Injections, Intrinsic Vulnerability in Application-Integrated AI Language Models (2023)