The Hidden Risk of Microsoft Copilot Rollouts in Regulated Financial Services

Microsoft 365 Copilot is the fastest enterprise AI deployment in Microsoft's history. For many regulated firms, it is also the least governed AI deployment they have ever done, not because governance teams are not trying, but because the way Copilot works creates risk exposures that standard IT security and compliance frameworks were not designed to catch.

This article is for the Microsoft 365 administrators, CISOs, compliance leads, and CIOs at regulated financial services firms who have either deployed Copilot or are about to. It explains the specific risk dimensions that Copilot creates, why standard Microsoft admin controls are necessary but not sufficient, and what a defensible Copilot governance posture actually looks like under Article 26, FCA SYSC 8, and Consumer Duty.

Copilot does not create new data. It surfaces data that already exists. The risk is not that Copilot adds new exposure. It is that Copilot makes existing exposure much faster to realise. The governance question is: what does your existing data landscape look like to an AI with access to it?

Why Copilot Changes Your Risk Exposure

Microsoft 365 Copilot operates with the permissions of the user invoking it. If a user has read access to a SharePoint site containing sensitive client data, Copilot has read access to that data on their behalf. If a user has send permissions on a shared mailbox, Copilot can send from that mailbox. If a user can access Teams channels across the organisation, Copilot can surface content from those channels.

This permission inheritance model is not a bug. It is by design. Copilot is meant to be a productivity tool that helps users work with the data they have access to. The risk arises because most organisations' Microsoft 365 permission landscapes are not as clean as they assume. Over-provisioned permissions, stale access that was never revoked, shared drives with overly broad access, SharePoint sites created for projects that have since concluded. These are endemic in most enterprise Microsoft 365 environments.

Before Copilot, over-provisioned permissions were a governance problem that existed largely in theory. A user with access to a SharePoint site they should not have access to was not likely to be browsing that site regularly. Copilot changes this. An AI assistant actively synthesising information across everything the user has access to will surface the content of over-provisioned permissions in a way that passive access never did.

The Permission Inheritance Problem in Detail

The permission inheritance risk manifests in three specific ways that regulated firms encounter most frequently:

Overly broad SharePoint access

SharePoint permissions in most large Microsoft 365 environments have accumulated over years of organisational change. Sites created for projects retain their membership lists after the project concludes. Departmental sites have access granted to entire business units when the original need was a single team. Senior leaders have broad access granted as a convenience that was never scoped to need.

Copilot synthesises across all of this. A Copilot query from a user about a client project will return results from every SharePoint site that user can access, including sites they have access to for legacy reasons that have nothing to do with the query. The information surfaced may include sensitive data from projects the user has no current business need to access.

Email and calendar scope

Copilot in Outlook can access the full email and calendar history of the user invoking it. For executives, senior relationship managers, or anyone with delegated access to shared mailboxes, this scope can include communications with significant commercial sensitivity. The governance question is not whether Copilot should access this. It is whether the organisation understands what Copilot's effective scope is across its user population.

Teams content surfacing

Copilot can surface content from Teams channels and meetings. In most organisations, Teams channels include internal communications, client discussions, deal commentary, and sometimes information that would not be shared more broadly. The access control on Teams channels is not always maintained as carefully as SharePoint document libraries. Copilot will surface what it can access.

Governance Visibility: What Microsoft's Admin Tools Show and What They Miss

Microsoft provides significant administrative tooling for Copilot governance: Copilot usage reports in the Microsoft 365 Admin Center, sensitivity label analytics, Microsoft Purview for data governance, and Entra ID for identity and access management. These tools are necessary. They are not sufficient for regulated firm governance requirements.

What Microsoft admin tools show

• Which users have Copilot licences and are actively using it
• High-level usage patterns (interactions, active users, feature adoption)
• Sensitivity label coverage across content that Copilot can access
• Data loss prevention policy matches and alerts
• Identity and access management for the Microsoft 365 tenant

What Microsoft admin tools do not show

• Cross-platform patterns. What Copilot users are doing in combination with AI agents on other platforms (Google Workspace, Salesforce, OpenAI)
• Evidence of governance oversight in a form that satisfies Article 26 or FCA supervision requirements. Usage reports are operational metrics, not signed governance evidence
• Risk classification of the Copilot deployment against Article 26 high-risk criteria or FCA SYSC 8 materiality thresholds
• HMAC-signed, reproducible evidence of the governance state at a specific date. Microsoft's logging can be exported but is not signed in a way that satisfies regulatory evidence requirements

Further reading: Article 26 Is an Evidence Problem, Not a Compliance Problem covers the signed-evidence requirement Microsoft's admin tools do not satisfy. The AI Inventory Crisis Nobody Is Talking About explains why Copilot belongs in the unified cross-platform inventory.

Copilot Under EU AI Act Article 26

Whether a Copilot deployment constitutes a high-risk AI system under EU AI Act Annex III depends on how it is being used. Copilot used for document drafting and email summarisation is unlikely to meet the high-risk threshold. Copilot being used to assist in credit decisioning, customer communication, claims assessment, or any other Annex III context is a different question.

For regulated financial services firms, the risk of Copilot touching Annex III activities is real and worth assessing explicitly. A Copilot interaction that helps a relationship manager draft a credit recommendation, summarises a customer's complaint history for a customer service agent, or synthesises regulatory reporting data. Each of these may constitute use in an Annex III context.

The deployer, the regulated firm, is responsible for making this assessment. Microsoft, as the provider, does not make the classification for each customer's use case. The assessment is the firm's to make, and the evidence that the assessment was made correctly is the firm's to produce.

Copilot Under FCA SYSC 8 and Consumer Duty

Independently of the EU AI Act classification question, Copilot's use in contexts that affect regulated activities or customer outcomes falls within FCA SYSC 8 and Consumer Duty scope, and these obligations are already in force.

SYSC 8

Microsoft Copilot is a material third-party arrangement for any regulated firm using it in connection with regulated activities. SYSC 8 requires firms to maintain oversight of material third-party arrangements, including the ability to identify failures and intervene. An AI tool operating at scale across the firm's Microsoft 365 environment, with access to email, documents, Teams, and calendar, is material by any reasonable assessment.

SYSC 8 oversight of Copilot means: the firm understands what Copilot can access and does with that access, monitors its use in regulated contexts, and can demonstrate that oversight to the FCA. Microsoft's usage reports support operational monitoring. They do not, on their own, satisfy SYSC 8 oversight requirements in a supervised firm context.

Consumer Duty

Copilot used by customer-facing staff (relationship managers, customer service agents, claims handlers) affects customer interactions and potentially customer outcomes. Consumer Duty requires firms to ensure AI-assisted customer interactions deliver good outcomes. This means monitoring Copilot-assisted communications for quality, accuracy, and compliance with Consumer Duty standards, not just tracking usage metrics.

A Copilot Governance Controls Checklist

The following checklist provides a practical starting point for regulated firms assessing their Copilot governance posture. It is not exhaustive, but it covers the most common gaps identified in regulated firm environments:

Permission and access scope

• Has a permissions audit been conducted specifically in preparation for Copilot deployment, identifying over-provisioned access that Copilot will surface?
• Are sensitivity labels applied consistently across SharePoint, OneDrive, and Teams content that Copilot can access?
• Has the firm assessed which users' Copilot access scope includes sensitive regulated data, and is that access appropriate?

Regulatory classification

• Has the firm assessed whether its Copilot use cases include Annex III contexts that would bring it within EU AI Act high-risk scope?
• Has the firm assessed Copilot as a material third-party arrangement under SYSC 8?
• Has Consumer Duty impact been assessed for Copilot use by customer-facing staff?

Monitoring and oversight

• Is Copilot usage in regulated contexts being actively monitored, not just tracked for engagement metrics?
• Is there a named individual or team responsible for Copilot governance oversight, with documented authority to intervene?
• Are Copilot-assisted customer communications being quality-reviewed on a documented cadence?

Evidence and documentation

• Does the firm have signed, dated evidence of its Copilot risk assessment and governance controls, verifiable under regulatory examination?
• Is Copilot included in the firm's AI agent inventory and regular evidence generation cycle?
• Are cross-platform patterns, what Copilot users are also doing on other AI platforms, being monitored and evidenced?

How AETHER Pulse Addresses Copilot Governance

AETHER Pulse connects to Microsoft 365 through the Microsoft Graph API, enumerating Copilot and other Microsoft 365 AI capabilities as part of its cross-platform agent discovery. It classifies Copilot deployments using its five-dimensional risk framework (assessing data access scope, external communication capability, human oversight status, and regulatory touchpoints) and includes Copilot in its cross-platform toxic-combination detection.

Critically, AETHER includes Copilot in its regular signed evidence generation cycle, so the firm's governance of its Copilot deployment is covered by the same signed, verifiable evidence infrastructure as its other AI agents. This means Copilot governance evidence is available in the same form as Article 26 evidence: dated, signed, reproducible under examination.

For regulated firms that have deployed or are deploying Copilot, AETHER provides the governance evidence layer that Microsoft's own tooling does not.

Published methodology: aetherpulse.app/methodology

Frequently Asked Questions

Does Microsoft Copilot fall within EU AI Act high-risk scope?

It depends on how it is being used. Copilot used for general productivity tasks (email drafting, document summarisation, meeting notes) is unlikely to meet the Annex III high-risk threshold. Copilot used to assist in credit assessment, customer risk profiling, claims triage, or other Annex III activities may meet the threshold. The classification is the deployer's responsibility to make.

What is the most common Copilot governance gap in regulated firms?

The most common gap is deploying Copilot at the technology layer (licences, tenant configuration, sensitivity labels) without addressing the governance layer: who is responsible for oversight, how is Copilot's use in regulated contexts being monitored, and what signed evidence exists of that monitoring. Microsoft provides the technology controls. The governance layer is the firm's responsibility.

Do Microsoft's built-in Copilot governance features satisfy FCA requirements?

Microsoft's admin tools provide necessary operational controls and monitoring capabilities. They do not, on their own, produce the governance evidence that FCA SYSC 8 oversight requirements and Consumer Duty monitoring obligations require: signed, verifiable records of governance activity that can be produced in a supervision visit. Those records require a governance evidence layer on top of Microsoft's operational tooling.

What about Microsoft Purview for AI governance?

Microsoft Purview provides data governance, sensitivity labelling, and compliance management within the Microsoft ecosystem. It is valuable for managing Copilot's interaction with sensitive data. It does not provide cross-platform AI agent discovery, cross-platform toxic-combination detection, or cryptographically signed evidence artefacts of the kind required for Article 26 compliance. Purview and AETHER Pulse are complementary rather than competing.

Review Your Copilot Governance Posture →