For most organisations built on Microsoft 365, the arrival of Copilot and similar assistants didn’t introduce a fundamentally new class of risk. What it did was make existing weaknesses far easier to find and exploit, both for curious employees and for attackers. That distinction matters, because it points security teams towards the controls they already have rather than towards a new product category.

The clearest example is oversharing. An AI assistant grounded in company data works within the permissions each user already holds. In principle, that’s the right design. In practice, many tenants have accumulated years of loosely shared files: HR folders opened to the whole organisation for a one-off project, finance spreadsheets shared by link and never revoked, SharePoint sites whose membership drifted as teams reorganised. Before AI, most of that exposure was protected by obscurity, because nobody knew where to look. An assistant that searches everything a user can reach removes that protection in seconds.

The risk here is less about malicious insiders than about ordinary people asking reasonable questions and getting answers they were never meant to see. A manager asking for a summary of recent pay discussions may receive one drawn from documents that should have been locked down years ago. No breach has technically occurred, yet the damage to trust and, potentially, to compliance can be real.

Identity is still the front door

Attackers have noticed that AI raises the value of a compromised account. A stolen identity with Copilot access is a faster way to find sensitive material than manually browsing SharePoint, and an attacker can simply ask the assistant to locate contracts, credentials in documents or discussions about an acquisition. That makes identity protection even more central than it was.

The techniques themselves aren’t new. Adversary-in-the-middle phishing kits that steal session tokens, device code phishing, MFA fatigue attacks and abuse of OAuth app consent all remain common routes into Microsoft 365 tenants. Generative AI helps the attacker at the front end too, producing convincing, well-written phishing emails in any language and at volume, which removes one of the older warning signs users were trained to spot.

The defences are also familiar, though too often only partly deployed, and getting them right is a common reason organisations bring in security consultants who specialise in Microsoft’s stack. They include phishing-resistant MFA such as passkeys or FIDO2 keys, Conditional Access policies that take device health and sign-in risk into account, token protection where it’s supported, and tight control over which third-party apps users can consent to. Many organisations have some of these in place for administrators and far less for everyone else. Closing that gap is the most useful step most of them can take, though configuring Conditional Access well without locking people out is harder than the documentation makes it look.

AI tools also bring a newer class of attack aimed at the assistant itself. Prompt injection, where hidden instructions in an email or document try to steer an assistant’s behaviour, is a real concern. Researchers disclosed a zero-click flaw in Microsoft 365 Copilot in 2025 that could have let an attacker extract data through a crafted email, and Microsoft patched it. It’s a reminder that assistants reading untrusted content are part of the attack surface, and that vendor fixes are only part of the answer.

Governance is where Purview and Sentinel earn their keep

The practical answer to AI-driven oversharing is data governance, and in Microsoft environments that largely means Purview. Sensitivity labels let organisations mark confidential material and apply protections that travel with the file, including encryption and restrictions on what AI assistants can do with labelled content. Data loss prevention policies can stop sensitive information types, such as payment card numbers or national insurance numbers, from being shared inappropriately. Microsoft has also added AI-focused views to Purview that show which sensitive data is being accessed through assistants and by whom.

None of it works well without groundwork. Labels applied inconsistently, or left to users to choose, provide patchy protection. Auto-labelling needs tuning. Retention policies need decisions about what the business actually wants to keep. That’s organisational work as much as technical work, and it’s the part that most often stalls.

On the detection side, Microsoft Sentinel and Defender XDR can bring identity, endpoint, email and cloud signals together, so that a risky sign-in followed by unusual volumes of file access or assistant queries shows up as a single incident rather than scattered alerts. The value depends on tuning and on someone watching. A SIEM that ingests everything and alerts on nothing useful is expensive log storage.

The harder problem sits just ahead. As Microsoft and others push AI agents that act with their own permissions, sending messages, updating records and calling other services, security teams will need to treat those agents as identities in their own right, with least-privilege access, monitoring and a clear owner. Most organisations haven’t yet decided who in the business signs off an agent’s permissions, and that decision is arriving faster than the policies to support it.