Secure AI Adoption: Practical Implementation with Microsoft Purview and Defender

Microsoft's new Data Security Index 2026 dropped some numbers worth paying attention to: 32% of data security breaches involve generative AI tools. At the same time, 47% of organizations have implemented AI-specific controls, up 8% from 2025.

I see this gap daily with customers. AI tools are being adopted faster than security teams can establish monitoring. Let me share some concrete measures to close that gap.

What should I prioritise first?

If you only do three things on the Microsoft stack, do these: consolidate tooling on Microsoft Purview so you have a single classification and labelling layer, monitor AI usage with Defender for Cloud Apps and DLP so unsanctioned activity is at least visible, and use Security Copilot to amortise the analyst time that AI-related alerts will consume. Anything else is layered on top of these three.

1. Consolidate tools → Unified visibility in Purview
2. Monitor AI usage → DLP and Defender for Cloud Apps
3. Use AI defensively → Security Copilot for automation

How do I find unauthorised AI usage with KQL?

The discovery path on Defender XDR has three queries: catalog traffic to known AI services (visibility), correlate DLP policy matches against AI app names (governance), and baseline normal usage to find anomalies (detection). The first two are continuous reporting queries; the third is the one you wire to a scheduled analytics rule.

Query 1: Identify Traffic to Known AI Services

// Defender for Cloud Apps - Shadow AI discovery
CloudAppEvents
| where Timestamp > ago(7d)
| where Application has_any ("ChatGPT", "Claude", "Gemini", "Copilot", "Perplexity", "Midjourney", "DALL-E")
| summarize
    RequestCount = count(),
    UniqueUsers = dcount(AccountObjectId),
    DataUploadedMB = sum(toreal(ReportId)) / 1048576 // Approximation
by Application, bin(Timestamp, 1d)
| order by RequestCount desc

Run this weekly and watch for new entries — Defender for Cloud Apps' app catalogue updates as new AI services launch, so a service you'd never heard of last month can show up as the top user-facing destination this month.

Query 2: Find Sensitive Data Sent to AI Endpoints

// Data Security Events - DLP policy violations (Advanced Hunting)
DataSecurityEvents
| where Timestamp > ago(30d)
| where DlpPolicyMatchInfo contains "AI" or DlpPolicyMatchInfo contains "Generative"
| where DlpPolicyEnforcementMode in (2, 3, 4) // Warn, Warn+Bypass, Block
| extend SensitiveTypes = parse_json(SensitiveInfoTypeInfo)
| summarize
    BlockedAttempts = countif(DlpPolicyEnforcementMode == 4),
    WarnedAttempts = countif(DlpPolicyEnforcementMode in (2, 3)),
    UniqueUsers = dcount(AccountUpn)
by AccountUpn, ApplicationNames
| where BlockedAttempts > 5
| order by BlockedAttempts desc

Note: DataSecurityEvents is in Preview and requires Microsoft Purview integration with Defender XDR.

Users who repeatedly trip DLP blocks on AI surfaces are either bypass attempts (genuine accident or deliberate workaround) or signs that the legitimate workflow needs a sanctioned alternative. Treat the top-N list as a backlog of either training conversations or sanctioned-tool roll-outs, not just a list of bad actors.

Query 3: Anomaly Detection on Data Exfiltration

// Identify users with abnormal uploads to AI services
let baseline = CloudAppEvents
| where Timestamp between(ago(30d) .. ago(7d))
| where Application has_any ("ChatGPT", "Claude", "Gemini")
| summarize AvgDailyRequests = count() / 23 by AccountObjectId;
//
CloudAppEvents
| where Timestamp > ago(7d)
| where Application has_any ("ChatGPT", "Claude", "Gemini")
| summarize TodayRequests = count() by AccountObjectId, bin(Timestamp, 1d)
| join kind=inner baseline on AccountObjectId
| where TodayRequests > AvgDailyRequests * 3
| project AccountObjectId, TodayRequests, AvgDailyRequests, AnomalyRatio = TodayRequests / AvgDailyRequests

Three-times-baseline is conservative — for high-volume Copilot users you may want a higher ratio. The point is not the specific multiplier but the pattern: a user whose AI traffic suddenly spikes is either onboarding, demonstrating to a colleague, or pulling data out faster than usual. All three are worth a manager check-in.

What does an AI data leakage IR playbook look like?

A short, scoped IR playbook for AI data leakage works in four phases: identify (verify the DLP alert is a true positive), contain (suspend session, block the AI app, lock the user), eradicate (re-permission the data, tighten the DLP rule, deploy session controls), and learn (write the post-mortem and feed the policy back into the baseline). The total wall-clock time for phases 1-3 should be under four hours; the eradication conversation often surfaces a process change that prevents the next incident.

Phase 1: Identification (0-30 min)

Step	Action	Tool
1.1	Verify alert. Is it actually sensitive data?	Purview Activity Explorer
1.2	Identify user and context	Defender XDR User Page
1.3	Map scope. What was shared, with which service?	Cloud App Events

Phase 2: Containment (30-60 min)

# Suspend user session immediately
Revoke-MgUserSignInSession -UserId "[email protected]"

# Block access to AI applications
# Done in Defender for Cloud Apps > App Governance

Manual checks:

• Has the user copied data to a personal device?
• Has the data already been processed by the AI service?
• Which third parties potentially have access?

Phase 3: Eradication and Recovery

1. Reassess user permissions: Principle of least privilege
2. Update DLP policy: Block instead of warn
3. Implement session controls: Conditional Access for AI apps

Phase 4: Lessons Learned

Document in incident report:

• What data was exposed?
• Which AI service?
• Why did existing controls fail?
• Recommended policy changes

How does Microsoft Purview DSPM help proactively?

Data Security Posture Management (DSPM) is the key to proactive AI security. According to the report, over 80% of organizations are implementing DSPM strategies. DSPM works by continuously scanning the data estate for sensitive content, scoring it for risk, and flagging the locations where access is broader than the sensitivity warrants — which is exactly the surface a Copilot prompt can pull from.

Getting Started:

1. Enable continuous discovery

   • Purview > Data Security Posture Management > Get Started
   • Connect all data sources (SharePoint, OneDrive, Teams, SQL)

2. Define sensitivity classification

   • Use built-in sensitive info types
   • Create custom classifiers for industry-specific data

3. Set up automatic alerts

   • Alert on high-risk exposure
   • Integrate with Sentinel for SOAR response

What DSPM actually changes for Copilot

The most useful DSPM finding is "sensitive content reachable to everyone in the organisation." Microsoft 365 Copilot honours existing permissions, so anything reachable to the prompting user is reachable to the model — but the long tail of mis-shared SharePoint sites means most tenants have payroll spreadsheets, customer lists, or M&A documents that were quietly shared to "Everyone except external users" years ago. DSPM surfaces those before a curious Copilot prompt does.

How do I govern sanctioned vs unsanctioned AI tools?

The right governance frame is binary at the top — sanctioned (with monitoring) vs blocked (or session-controlled) — and granular underneath. Sanctioned tools get a DLP policy and continuous monitoring; unsanctioned tools get either a hard Conditional Access block or a session-control policy that lets users see the service but blocks sensitive uploads.

Recommended Approach:

Allow (with monitoring):

• Microsoft Copilot (integrated DLP)
• Azure OpenAI (enterprise-controlled)
• GitHub Copilot (with enterprise license)

Block or strictly monitor:

• Public ChatGPT
• Claude (unauthenticated)
• Other shadow AI services

Conditional Access Policy Example:

Policy: Block-Unsanctioned-AI
Assignments:
  Users: All Users
  Cloud Apps: ChatGPT, Claude (public), Bard
  Conditions: Any device, any location
Grant: Block access
Session: N/A

For a softer variant, replace Grant: Block access with Session: Conditional Access App Control and route through Defender for Cloud Apps. Users can still read AI responses but cannot paste sensitive content into prompts — the DLP engine inspects each request in real time.

Where does Security Copilot fit in?

82% of organizations plan to use generative AI in security operations. Security Copilot's role on the data-protection side is not to replace the analyst but to compress the lookup-and-write phase of every incident — explaining a DLP match, drafting a user notification, and proposing the next DLP-rule refinement. Three practical use cases:

1. Incident triage: "Analyze this DLP event and rate severity"
2. Policy recommendations: "Suggest DLP rules based on last month's blocks"
3. Report generation: "Create executive summary of AI-related incidents"

What I'd actually prioritize

AI adoption isn't going anywhere. The key is building security into the AI strategy, not adding it later.

1. Start with visibility. Deploy Defender for Cloud Apps and enable AI app discovery. You can't protect what you can't see.

2. Graduated controls. Don't block everything. Allow sanctioned tools with DLP, block shadow AI.

3. Automate response. Security Copilot and Sentinel playbooks let a small team cover more ground.

If you want a parallel piece on the framework-supply-chain side of AI security, the LangGrinch / CVE-2025-68664 walkthrough covers what happens when the AI framework itself is the vulnerability, not just the data flowing through it. For the agent-identity dimension — which is what makes Copilot prompts cross trust boundaries inside the tenant — see the AI agent identity crisis post.

---

Connect on LinkedIn or see my CV.