Microsoft 365 DLP falls short where AI and SaaS data flow

At a glance

What this is: This is Strac’s 2026 guide to Microsoft 365 DLP, with the key finding that native Purview coverage is useful but incomplete for unstructured content and AI-era data movement.

Why it matters: It matters because IAM and security teams increasingly need to govern sensitive data as it moves through SaaS, collaboration, and AI surfaces, where access, sharing, and remediation controls intersect.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Strac's guide to Microsoft 365 DLP limits and AI-era coverage

Context

Microsoft 365 DLP is a data governance control, not a complete data security programme. It can classify and block sensitive information in core Microsoft workloads, but modern business data now moves through SaaS apps, browser-based collaboration, screenshots, attachments, and AI assistants in ways that native policy engines often do not fully observe.

The identity connection is indirect but real: DLP decisions depend on who can access, share, forward, or expose data, while AI agents and connected tools can change the path that data takes. In that sense, the gap is not only detection coverage, but governance across access, redaction, and downstream use.

Key questions

Q: What breaks when Microsoft 365 DLP only detects content but cannot remediate it?

A: Detection-only DLP leaves a gap between finding risky content and stopping it from spreading. In practice, users can still forward, screenshot, paste, or sync data into other tools before security teams act. Organisations need a control model that includes blocking, redaction, and downstream governance, not just alerts and reports.

Q: Why do AI assistants complicate DLP and identity governance together?

A: AI assistants can retrieve data on behalf of users, summarise it, and push it into new workflows without following the same visible access path as a person. That means the security question is both who can access the source data and which software entity can reuse it. Identity and DLP controls have to be reviewed together.

Q: How can teams tell whether DLP coverage is actually keeping pace with collaboration risk?

A: Use evidence-based testing across file types, chat channels, screenshots, and external sharing paths. If sensitive data is only caught in plain text but not in images or attachments, the control is partial. A mature programme measures detection, blocking, redaction, and exception rates by workload.

Q: Who is accountable when sensitive Microsoft 365 data is exposed through an AI-connected workflow?

A: Accountability usually sits across security, data governance, and application owners because the exposure path spans access rights, policy settings, and tool integration. If the data can be retrieved by an assistant or connected service, that integration should be in scope for review, approval, and ongoing monitoring.

Technical breakdown

How Microsoft 365 DLP inspects content across workloads

Microsoft 365 DLP works by evaluating content in Exchange, SharePoint, OneDrive, Teams, and endpoint channels against predefined or custom policy rules. Those rules look for sensitive information types, pattern matches, labels, and context that indicate a sharing or exfiltration risk. Once triggered, the policy can warn, block, encrypt, or audit activity. The core limitation is that this model is strongest when content is structured enough to classify cleanly. Unstructured text inside images, PDFs, screenshots, or mixed-format attachments raises the false-positive and false-negative problem that many native DLP programmes struggle to absorb.

Practical implication: classify the highest-risk workloads first, then test whether your DLP rules actually see the file types and collaboration paths your users rely on.

Why OCR and inline redaction change the control model

OCR-aware scanning extends DLP beyond text tokens by extracting sensitive material from images and scanned documents before policy decisions are applied. Inline redaction is different from alerting because it changes the content itself rather than only reporting a violation. That matters in collaboration-heavy environments where sensitive data is often shared casually, embedded in screenshots, or pasted into chat. The control model shifts from after-the-fact detection to active content modification, which reduces exposure but also requires tighter tuning so legitimate business communication is not over-redacted.

Practical implication: if screenshots, scans, or images carry sensitive data, evaluate whether your current DLP can inspect them before they reach recipients.

Why AI and MCP paths create a new DLP boundary

Copilot-style assistants and MCP-connected tools can read and re-expose Microsoft 365 content without following the same user journey that classic DLP policies were built around. MCP, or Model Context Protocol, connects AI systems to tools and data sources, which means the governance question is no longer only who can open a file, but which software entities can retrieve, summarise, or repurpose it. That introduces a new boundary between authorised access and authorised reuse. Traditional DLP may still detect the source object, but it may not fully govern what an AI system does with the data once retrieved.

Practical implication: treat AI-connected data paths as separate policy surfaces and map which assistants can reach regulated or secret-bearing content.

NHI Mgmt Group analysis

Native DLP is necessary but no longer sufficient for modern content governance. Microsoft 365 DLP still provides a baseline for email and collaboration controls, but the article itself shows that detection-centric policy engines struggle with unstructured and cross-platform data. In practice, the gap appears when the same sensitive record moves from a document library into a chat, screenshot, or AI workflow. Security teams should treat DLP as a visibility and enforcement layer, not as a complete control plane for data movement.

AI-connected workspaces create a data governance blind spot that looks like a content problem but behaves like an identity problem. Once a Copilot or MCP-connected system can retrieve Microsoft 365 content, the security question shifts to delegated access and downstream use. That is where identity governance and DLP intersect: the organization must know which software entities can act on behalf of users or applications, and what content they can access in those delegated paths. Practitioners should map AI data access as part of identity governance, not as an isolated productivity feature.

OCR-aware redaction defines a more realistic control for SaaS collaboration than regex-based detection alone. The guide points to a wider pattern across modern data security: the format of the content now matters as much as the sensitivity label. That is a useful concept for the market because it reframes DLP from keyword matching to content-state control. Teams should evaluate whether their governance model can preserve business use while reducing unnecessary exposure across mixed-format files.

Microsoft 365 DLP exposes the limits of perimeter thinking in data security programmes. Organisations increasingly need controls that span Microsoft, third-party SaaS, browser sessions, and AI tools, because sensitive data now crosses those boundaries routinely. The implication is not to abandon native DLP, but to understand where native policy ends and where cross-SaaS remediation must begin. Security leaders should design for data portability rather than assume platform boundaries will hold.

For identity teams, the practical issue is not only access entitlement but reuse entitlement. Traditional IAM can tell you who authenticated to the platform, yet it does not automatically govern how content is copied, summarised, redacted, or forwarded by connected systems. That distinction matters as AI adoption grows. Practitioners should align DLP policy, app authorization, and identity governance so that access, delegation, and content handling are reviewed together.

What this signals

Microsoft 365 DLP will increasingly be judged by whether it can govern content as it moves through AI-connected workflows, not just whether it can classify a file at rest. Content-state governance: the next control gap is the point where a file becomes a prompt, a summary, or a shared snippet, and that is where identity, authorization, and redaction need to align.

For practitioners, the immediate signal is that DLP programmes should be reviewed alongside app authorization and delegated access. If an assistant or connector can reuse content outside the original user session, the organisation needs a policy boundary that treats that reuse as a governed event, not just a convenience feature.

For practitioners

• Inventory AI-connected data paths Map where Microsoft 365 content can be read by Copilot-style assistants, MCP-connected tools, and other downstream services. Identify the workloads where data leaves native Microsoft controls and mark them for separate policy evaluation.
• Test unstructured content coverage Run controlled tests against PDFs, screenshots, scanned documents, and mixed-format attachments to see whether your DLP policy detects and blocks the same sensitive patterns as it does in plain text.
• Separate detection from remediation Define which findings should trigger alerts, which should block sharing, and which should be redacted inline. Use that distinction to reduce false positives while still preventing sensitive content from leaving approved channels.
• Tie DLP to identity governance reviews Include delegated applications, service accounts, and AI assistants in reviews of who can access sensitive content and how that content can be reused outside the original user session.

Key takeaways

• Microsoft 365 DLP is useful, but detection alone does not close the exposure gap created by modern SaaS and AI data flows.
• Unstructured content, OCR-heavy files, and MCP-connected assistants are where native policy controls are most likely to lose visibility.
• Security teams should align DLP with identity governance so access, delegation, and content reuse are reviewed as one control problem.

Key terms

• Data Loss Prevention: Data loss prevention is the set of controls used to detect, block, and report sensitive data moving in ways the organisation does not allow. In practice, DLP must account for endpoints, email, cloud apps, APIs, and user behaviour, or it will miss the paths where real exposure happens.
• Output Redaction: Output redaction is the process of removing or masking sensitive content before an AI response is delivered or stored. It is a runtime control that reduces accidental disclosure of secrets, personal data, or regulated information when a model generates text from broad context.
• MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.
• Sensitive Information: Sensitive information is a higher-risk category of personal data that attracts stricter handling requirements because misuse can create greater harm. In Australia this includes biometrics, health information, political opinions, and criminal history, which means controls for collection, access, disclosure, and transfer need tighter governance than ordinary personal data.

What's in the full article

Strac's full guide covers the operational detail this post intentionally leaves for the source:

• Step-by-step Microsoft 365 DLP setup guidance for Exchange, SharePoint, OneDrive, and Teams
• Policy examples for PII, PHI, PCI, and custom sensitive information types
• Testing and tuning guidance for false positives, override handling, and reporting
• Operational examples for extending detection into SaaS and GenAI workflows

👉 The full Strac guide covers setup steps, policy examples, and Microsoft 365 coverage details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It helps security and identity practitioners connect access governance to the broader control problems that modern programmes now face.