Microsoft 365 Copilot Security Deep Dive: Oversharing, Permissions and Data Protection

Microsoft 365 Copilot can find and summarise anything a user is technically allowed to open, so every overshared SharePoint site, stale group membership and "Everyone except external users" grant becomes a question away from disclosure. Copilot does not create new access, but it removes the obscurity that used to hide bad access. This guide is the product view for Microsoft 365: which permissions Copilot honours, which admin roles control it, how agents and connectors extend its reach, what Purview and SharePoint Advanced Management can restrict, what the audit log records, and a baseline to roll out. For the vendor-neutral risk model that applies to any enterprise assistant, see the Enterprise AI Copilot Security Guide; this page does not repeat it. It is written for Microsoft 365 administrators, identity teams and data protection practitioners. Settings were checked against Microsoft Learn in October 2026; Copilot features change often, so confirm names and licensing in your tenant before enforcing.

Key takeaways

• Permissions are the real control. Copilot grounds answers through Microsoft Graph and the semantic index using only content the user has at least view permission for, so oversharing remediation does more than any Copilot toggle.
• Restricted Content Discovery is a pause button, not a boundary. It hides a SharePoint site from organisation-wide search and Copilot without changing permissions, and Restricted SharePoint Search can no longer be newly enabled from 31 July 2026.
• Labels need the right usage rights. For encrypted content Copilot needs the user to hold both EXTRACT and VIEW rights, and output inherits the highest-priority label, so label design decides what Copilot can summarise.
• Purview DLP has a dedicated Copilot location. It can stop Copilot processing labelled files and emails and block prompts containing sensitive information types, but it does not scan files uploaded into a prompt.
• Agents and external email are the injection path. EchoLeak showed that one crafted email could reach Copilot's context; govern agents in the Agent Registry, consider excluding external email from grounding and watch the XPIADetected and JailbreakDetected audit fields.

How identity and access work in Microsoft 365 Copilot

Copilot has no separate account model. A user signs in with their Microsoft Entra ID identity, and every grounding request runs in that user's security context. Microsoft's privacy documentation states that Copilot surfaces only organisational data the individual user has at least view permission for, that the semantic index honours the user's identity-based access boundary, and that permissions granted to external users through inter-tenant collaboration, such as Teams shared channels, also apply.

• Sign-in: Conditional Access governs Copilot like any Microsoft 365 workload. Microsoft's Zero Trust guidance for Copilot starts with MFA for administrators and all users and blocking legacy authentication (Entra ID P1), then risk-based policies requiring MFA at medium or high sign-in risk (Entra ID P2). See the Conditional Access Guide.
• Devices: the same guidance adds Intune compliance policies and Intune App Protection policies, which keep organisational data inside managed apps and block copy and paste to unapproved apps, including on unmanaged devices.
• Personal accounts: Microsoft advises controlling personal Microsoft account access with tenant restrictions rather than blocking the Copilot endpoint, which would also break the work experience.
• Guests: guest accounts are not licensed to use Copilot, but content guests can reach through sharing still matters because members can find it.

What Copilot can and cannot reach

Two data-handling points matter for risk assessments. Microsoft states that prompts, responses and Graph data are not used to train foundation models, and that Copilot is an EU Data Boundary service; the same page notes that Anthropic models, used as a subprocessor, are currently excluded from the EU Data Boundary. If you enable those models, record the decision.

Admin roles and privileged access

Copilot settings sit across the Microsoft 365 admin center, the SharePoint admin center and the Microsoft Purview portal, so several Entra roles can change what Copilot can see. Keep them separate and time-bound. See the Privileged Identity Management (PIM) Guide.

• Delegated site control: by default only SharePoint administrators can set Restricted Content Discovery. Set-SPOTenant -DelegateRestrictedContentDiscoverabilityManagement $true lets site administrators manage it for their own sites, with a mandatory justification that is written to the Purview audit log. Delegate only if site owners are trained and the audit events are monitored.
• Group owners are access administrators: anyone who can add members to a Microsoft 365 group or Teams team can widen what Copilot returns for those members. Include group ownership in access reviews. See the Access Reviews Guide.
• Break-glass accounts: exclude them from Copilot licensing; an emergency account has no business reason to search the tenant through an assistant. See the Break-Glass Account Guide.

Integrations, API tokens and service accounts

Out of the box Copilot acts with the user's delegated access. Agents, connectors and Copilot Studio change that picture, because each one adds a new identity, a new data source or a new path for untrusted content.

• Agent Registry: agent management is on by default in Copilot-licensed tenants. Admins review agent requests and publish or reject them, and users reach only agents the organisation allows, through the Agent Store. Microsoft lists five agent types: published by your organisation (admin approval required), shared by creator (Copilot Studio or Agent Builder), Microsoft agents, external partner agents and frontier agents. The same Copilot Studio agent can appear twice with different publisher states, which is by design.
• Shared-by-creator agents: these spread without admin publishing. Review the Agents page for name, creator, host products and status, and block unsafe or non-compliant ones. See the Securing Microsoft Copilot Studio Agents Guide.
• Consent and OAuth: agents that sign users in to other services create OAuth grants. The CoPhish technique documented by Datadog Security Labs used a Copilot Studio agent's login setting to wrap an OAuth consent phishing page in a Microsoft domain. Restrict user consent and require admin approval for sensitive Graph permissions. See the Entra ID Applications and Consent Guide.
• Copilot connectors: third-party content indexed through connectors is returned only if the connected source's permissions allow it. The risk is the connector's own service credential: it usually has tenant-wide read access to the source. Store it in a vault, scope it to the content you intend to index and assign an owner.
• Agents and encryption: Microsoft notes that encryption can exclude programmatic access, which limits what an agent can read. For highly confidential labels, consider whether agent access should be allowed at all.

Treat every published agent and connector as a non-human identity with an owner, a scope and a review date. See the Agentic AI Identity Guide.

Logging and detection

Copilot interactions from Microsoft-built copilots are recorded in Audit (Standard) with no extra configuration, under the record type and operation CopilotInteraction. Interactions with non-Microsoft AI apps use pay-as-you-go audit with 180-day retention. The audit page does not state that prompt or response text is in the audit record; retrieve content through eDiscovery instead, and check a sample record in your own tenant.

• Purview analytics: DSPM for AI provides recommendations and one-click policies; the Insider Risk Management "Risky AI usage" template covers prompt injection attempts and access to protected material; Communication Compliance can be configured for generative AI interactions.
• eDiscovery: search mailboxes with the condition Type contains Copilot activity. Interaction data is copied to a hidden folder in the user's mailbox, which is why mailbox holds affect it.
• Configuration changes: Restricted Content Discovery changes and justifications are Purview audit activities; alert on removals.
• Inbound injection: Microsoft lists prompt injection detection in inbound email as a Defender for Office 365 Plan 2 capability. Stream audit and Defender events to the SIEM. See the SIEM Guide.

Metrics that show it is working

• Number of sites with "Everyone except external users" or organisation-wide sharing links, from data access governance reports, trending down before each licence wave.
• Percentage of sensitive sites (HR, legal, finance, M&A) with a default sensitivity label, an owner and a completed site access review.
• Copilot interactions whose AccessedResources include a highly confidential label, per 1,000 interactions.
• Count of XPIADetected and JailbreakDetected events and median time to triage.
• Agents in use that are not "published by your organisation", and agents without a named owner.

Hardening baseline

Microsoft's deployment blueprint groups the work into three pillars: remediate oversharing, set up guardrails, and meet regulations, using Purview and SharePoint Advanced Management (SAM). Microsoft states that SAM is included with the Copilot licence. The table below turns that into settings.

Rolling out the baseline

1. Inventory: run the data access governance reports and list sites with EEEU grants, organisation-wide links and no owner. Prioritise HR, legal, finance, M&A, executive and customer data.
2. Restrict while you fix: apply Restricted Content Discovery to the highest-risk sites and record each one with a review date. Do not plan on Restricted SharePoint Search: its 100-site allow list was always temporary and new enablement is blocked from 31 July 2026.
3. Pilot ring: license a small group from several departments. Put Copilot DLP rules in simulation mode and review matches for two to four weeks.
4. Remediate: remove broad grants, run site access reviews with owners, apply default labels to sensitive libraries and fix group ownership.
5. Enforce: switch DLP rules to block, lift Restricted Content Discovery site by site as permissions are fixed, and enable agent approval for the wider population.
6. Expand in waves: repeat the reports before each licence wave. Roll back by removing licences from a group, re-applying Restricted Content Discovery to a site, or setting a DLP rule back to simulation; none of these change underlying permissions, which is why they are safe to reverse.

Decision guidance

• Restricted Content Discovery or permission fix: use Restricted Content Discovery when a site is sensitive and the clean-up will take weeks; fix permissions when the problem is a handful of links. Restricted Content Discovery does not stop a user opening the file directly, so it never replaces the fix.
• Label exclusion or encryption: a DLP label rule keeps content out of answers but leaves the file accessible; encryption without EXTRACT also blocks copying elsewhere. Use DLP where users need the document but not AI summaries, encryption where the content itself is restricted.
• Small tenants: with few sites, a manual review of sharing and group membership plus DLP label rules may be enough. Large tenants need SAM reports, delegated site owner reviews and agent approval workflows, because the volume of sites makes manual review impractical.

Common misconfigurations

• Licensing before clean-up: Copilot is switched on for a department before the "Everyone except external users" grants are found, and users discover HR or M&A folders by asking ordinary questions.
• Treating search controls as a boundary: Restricted Content Discovery and Restricted SharePoint Search do not change permissions, do not cover OneDrive, and leave content users own, recently used or had shared with them visible.
• DLP gaps: a single rule that tries to combine label and sensitive information type conditions, an assumption that files uploaded into the prompt are scanned (they are not), or an expectation that calendar invites are covered by label rules (they are not).
• Trusting inbound content: external email and shared files reach Copilot's context. In EchoLeak (CVE-2025-32711), Aim Labs showed that a single crafted email could lead Copilot to place internal data in a link or image and bypass the injection classifier, link redaction and Content Security Policy. Microsoft fixed it server side and reported no exploitation, but the pattern remains: decide whether external email should ground answers at all for sensitive users.
• Unreviewed agents: shared-by-creator agents and external partner agents are allowed by default policy settings that nobody revisited, and their connector credentials have no owner.
• Retention by accident: no retention policy for Copilot interactions, or a legal hold that silently keeps interaction data in SubstrateHolds longer than the privacy notice says.

Framework mapping

Practitioner checklist

• Run SAM data access governance reports and remove EEEU and organisation-wide grants on sensitive sites before each licence wave.
• Apply Restricted Content Discovery only as a dated interim measure, and track every restricted site to a permission fix.
• Make AI Administrator, SharePoint Administrator and Purview roles PIM-eligible and separate; keep Global Administrator for emergencies.
• Check encrypted labels: withhold EXTRACT where Copilot should not summarise, and test with a pilot user.
• Create a Copilot DLP policy with separate label and sensitive information type rules, run it in simulation, then enforce.
• Decide on web grounding and external email grounding for regulated and executive groups.
• Require Agent Registry approval for agents used by sensitive departments, review shared-by-creator agents monthly and restrict user consent.
• Stream CopilotInteraction events to the SIEM and alert on XPIADetected, JailbreakDetected and highly confidential labels in AccessedResources.
• Set a retention policy for Microsoft Copilot experiences that matches your privacy notice and legal hold process.

Standards and references

• Microsoft Learn: Data, Privacy, and Security for Microsoft 365 Copilot
• Microsoft Learn: Microsoft 365 Copilot data protection and auditing architecture
• Microsoft Learn: Restricted Content Discovery
• Microsoft Learn: DLP for Microsoft 365 Copilot and Copilot Chat
• Microsoft Learn: Audit logs for Copilot and AI applications
• Microsoft Learn: SharePoint Advanced Management
• Microsoft Learn: Microsoft Copilot prompt defense in depth
• OWASP: Top 10 for LLM Applications 2025

Related NHI Mgmt Group resources: Enterprise AI Copilot Security Guide · Microsoft 365 Security Guide · Generative AI Data Loss Prevention Guide · Prompt Injection Guide · SaaS Security Guide