Microsoft 365 Copilot in the Enterprise: How to Use It Safely, the Governance Controls You Need, and What APRA Expects

Microsoft 365 Copilot is now embedded in Word, Excel, Outlook, Teams, and SharePoint across most enterprises. Copilot operates within Microsoft 365 boundaries and your data is not used to train foundation models — but that does not mean it is safe by default. The governance controls organisations need before allowing Copilot to access company data, and what APRA and ASIC expect from regulated entities.

Key Takeaways

Microsoft 365 Copilot offers Enterprise Data Protection (EDP) by default — prompts and responses stay within tenant boundaries and are not used to train foundation models.
Copilot inherits existing Microsoft 365 permissions — if data is overshared in SharePoint, Copilot will surface it to users who shouldn't see it.
The 2025 EchoLeak vulnerability (CVE-2025-32711) demonstrated that even tenant-bound AI tools have novel attack surfaces.
Microsoft Purview provides AI governance controls: discovery, classification, DLP, audit logging, eDiscovery, and retention policies.
For APRA-regulated entities: Copilot deployment requires AI inventory documentation, risk classification, and human oversight controls per the April 2026 industry letter.
Shadow Copilot is real — employees enabling personal Copilot in browser extensions bypass enterprise governance.

"情報提供のみを目的としています。この記事は法律、規制、財務または専門的なアドバイスを構成するものではありません。具体的なアドバイスについては、資格を持つ専門家にご相談ください。"

Microsoft 365 Copilot is the most widely deployed enterprise AI tool in the world. By mid-2026, it is embedded by default in Word, Excel, Outlook, Teams, SharePoint, and the Microsoft 365 Copilot Chat experience across millions of organisations. Microsoft Agent 365 — which went into general availability in May 2026 — adds autonomous agents that operate across Microsoft 365 and third-party applications. Copilot is built on Microsoft's Enterprise Data Protection framework: prompts and responses are processed within the Microsoft 365 service boundary, your data is not used to train foundation models, and Copilot honours existing Microsoft 365 permissions and access controls. But that does not mean Copilot is safe by default. The governance controls organisations need to deploy Copilot safely — and what regulated entities specifically need to address — are the focus of this guide.

What Microsoft does well by default

Microsoft 365 Copilot operates within the Microsoft 365 service boundary. Prompts entered by users and responses generated by Copilot are protected by the same contractual terms that apply to email in Exchange and files in SharePoint. The prompts and responses are encrypted at rest and in transit, isolated between tenants, and are not used to train Microsoft's foundation models. Copilot honours existing user permissions — it cannot access data the user does not already have permission to access. For users entering prompts about regulated data (health information, financial records, legal matters), the contractual protections that apply to that data in Microsoft 365 also apply to Copilot interactions with it.

What Microsoft does NOT do — and where governance is required

Copilot inherits existing Microsoft 365 permissions. If data has been overshared in SharePoint (a chronic problem in most organisations), Copilot will surface that data to users who technically have access but probably should not. Permissions hygiene is now an AI governance issue, not just a security issue. Copilot also does not validate the accuracy of its outputs. Like all large language models, Copilot can produce confident-sounding outputs that contain errors, fabricated citations, or misinterpreted source data. Human review of consequential Copilot outputs remains essential. Copilot does not automatically classify outputs containing sensitive data — sensitivity labels must be configured and applied through Microsoft Purview Information Protection.

The EchoLeak incident and what it taught us

In early 2025, security researchers disclosed EchoLeak (CVE-2025-32711), a zero-click vulnerability in Microsoft 365 Copilot that could allow attackers to retrieve sensitive information from Microsoft Graph and Outlook APIs without user interaction. Microsoft patched the vulnerability promptly, and the issue did not involve actual data exfiltration in customer environments. However, EchoLeak demonstrated that enterprise AI tools — even those built on Microsoft's extensive security framework — present novel attack surfaces that traditional security controls may not cover. Prompt injection, indirect prompt injection through embedded content, and data exfiltration via AI outputs are emerging attack vectors that governance frameworks must address.

The Microsoft Purview governance stack

Microsoft's governance tools for Copilot are powerful but require deliberate configuration. Discovery: identify where Copilot is deployed and how it is being used across the organisation. Classification: apply sensitivity labels through Microsoft Purview Information Protection so that Copilot respects data sensitivity in its outputs. Data Loss Prevention (DLP): configure DLP policies to prevent Copilot from including specific data types (PII, financial information, IP) in responses. Audit logging: capture all Copilot interactions for compliance review, eDiscovery, and incident investigation. Retention policies: align Copilot prompt and response retention with broader records management obligations. Communication compliance: monitor Copilot interactions for inappropriate use, harassment, or policy violations.

What APRA and ASIC expect

For APRA-regulated entities, Copilot deployment must be documented in the AI use case inventory required by APRA's 30 April 2026 industry letter. Risk classification should consider that Copilot is broadly deployed (affecting most staff), accesses sensitive data (financial records, customer information, regulatory correspondence), and influences consequential decisions (drafting customer communications, summarising regulatory analysis). Human oversight controls are particularly important for Copilot outputs that inform regulated activities — customer advice, regulatory submissions, financial analysis. Vendor management under CPS 230 applies — Microsoft is a material service provider for most APRA-regulated entities, and the AI services tier of that relationship requires specific governance attention. ASIC's 8 May 2026 cyber resilience letter is directly relevant — Copilot deployment expands the cyber attack surface and creates new categories of cyber incident that boards need to understand.

Shadow Copilot

The greatest immediate Copilot governance risk is shadow Copilot — employees enabling personal Copilot accounts, browser extensions, or third-party integrations that operate outside enterprise governance. A user signed into a personal Microsoft account in the same browser as their work account can inadvertently route work data through personal Copilot processing without Enterprise Data Protection applying. AI policy must explicitly address this — what personal AI accounts can and cannot be used for work, and what technical controls (browser policies, conditional access) enforce the policy.

Practical implementation steps

Before broad Copilot deployment, conduct a permissions audit to identify and remediate overshared content in SharePoint and OneDrive. Configure Microsoft Purview Information Protection with sensitivity labels that apply organisation-wide. Implement Copilot-specific DLP policies for sensitive data categories. Train users on Copilot capabilities and limitations — including the requirement to validate consequential outputs. Establish an AI policy that addresses Copilot use, personal AI accounts, and shadow AI. Monitor Copilot usage patterns through Purview dashboards. Plan for incident response — what happens when Copilot produces an inaccurate output that leads to a customer or regulatory issue?

Primary sources: Microsoft — Enterprise Data Protection in Copilot | APRA Letter to Industry on AI, 30 April 2026