Embedded Experiences & Zero Trust Deployment

About This Lab

Microsoft Security Copilot offers two distinct experiences: the standalone portal at securitycopilot.microsoft.com for cross-product investigations, and embedded side panels built directly into Microsoft security products such as Defender XDR, Sentinel, Entra, Intune, and Purview. Each embedded experience is scoped to the product’s data, providing contextual AI assistance without switching windows.

This lab also covers the Zero Trust framework for deploying Security Copilot securely. Zero Trust assumes breach and verifies every access request explicitly. You will configure Conditional Access policies, enforce least privilege with Copilot-specific roles, enable Privileged Identity Management (PIM) for time-bound access, secure privileged access workstations, and plan a phased deployment from evaluation through full rollout.

🔗 The Unified SecOps Vision

Microsoft’s security platform is built on the idea that defenders need a unified view across identity, endpoints, cloud, data, and applications. Six pillars - AI, XDR, SIEM, Cloud Security, Exposure Management, and Threat Intelligence - converge into one ecosystem that spans Prevent, Detect, Investigate, and Respond.

But even with this integrated foundation, humans still shoulder the responsibility of connecting signals and determining next steps. An analyst looking at a Defender XDR incident must manually correlate it with Sentinel detections, enrich it with threat intelligence, check exposure data, and decide on response actions across multiple portals.

Security Copilot changes that. By embedding AI directly into this unified SOC, we gain intelligence that understands context, recognises threat patterns, and guides analysts with clear next-step reasoning. It reads across all six pillars simultaneously - correlating XDR alerts with SIEM detections, enriching them with threat intelligence, factoring in exposure data, and recommending response actions. It turns a connected SOC into an intelligent SOC.

And that intelligence is key as we move toward the next evolution: autonomous protection. Today, Copilot assists analysts with recommendations and guided response. Tomorrow, trusted AI agents will detect, investigate, and contain threats independently - with human oversight at decision points. The journey from manual SOC → connected SOC → intelligent SOC → autonomous SOC is the trajectory this lab prepares you for.

🏢 Enterprise Use Case

Scenario: A global financial services firm is deploying Security Copilot to its 50-person SOC. They need to configure embedded experiences in Defender XDR and Sentinel for Tier 1 analysts, restrict standalone portal access to Tier 2/3 analysts, and ensure the entire deployment meets their Zero Trust maturity requirements before the auditors review next quarter.

The Challenge:

• Tier 1 analysts need AI assistance scoped to the product they are working in (Defender XDR incidents, Sentinel alerts) without cross-product access.
• Tier 2/3 analysts need full standalone portal access for cross-product investigations but must use privileged access workstations.
• The Security Copilot Owner role grants administrative capabilities that must be time-bound and require approval via PIM.
• Third-party plugin integrations introduce trust boundaries that must be governed.
• Auditors require evidence of Conditional Access enforcement, role assignment reviews, and usage monitoring.

The Solution: By applying Zero Trust principles systematically - Conditional Access, least privilege roles, PIM, privileged access devices, and phased deployment with monitoring - the firm deploys Security Copilot securely while meeting audit requirements and ensuring each analyst tier gets the right level of access.

🎯 What You Will Learn

1. Understand standalone vs embedded Security Copilot experiences
2. Use Copilot embedded in Defender XDR for incident summarization and guided response
3. Use Copilot embedded in Microsoft Sentinel for incident analysis
4. Use Copilot embedded in Microsoft Entra for risky user investigation
5. Use Copilot embedded in Microsoft Intune for device troubleshooting
6. Use Copilot embedded in Microsoft Purview for DLP and eDiscovery
7. Configure Conditional Access policies for Security Copilot access
8. Apply least privilege with Copilot Owner and Copilot Contributor roles
9. Configure Microsoft Entra PIM for time-bound Copilot access
10. Deploy privileged access workstations for SOC analysts
11. Secure third-party plugin access with Zero Trust principles
12. Plan a phased Copilot deployment (Evaluate → Pilot → Full)
13. Monitor Copilot usage and audit access patterns
14. Build a Copilot governance framework

🔑 Why This Matters

Security Copilot is a powerful tool that processes sensitive security data across your entire Microsoft security stack. Without proper Zero Trust controls, you risk over-provisioning access, exposing sensitive investigation data to unauthorised users, and failing compliance audits. Embedded experiences allow you to meet analysts where they work - inside the security products they already use daily - while controlling data scope. Combined with Conditional Access, PIM, and a phased deployment model, you ensure that Copilot adoption is secure, auditable, and aligned with your organisation’s Zero Trust maturity journey.

• Security Copilot provisioned with SCU capacity · Complete Lab 01: Getting Started with Security Copilot first.
• Microsoft 365 E5 or E5 Security license · Required for full Defender XDR, Sentinel, and Purview integration.
• Microsoft Entra ID P2 · Required for Privileged Identity Management (PIM).
• Defender XDR, Sentinel, Entra, Intune, and Purview configured · Each product must be operational to explore its embedded Copilot experience.
• Global Administrator or Security Administrator role · Required for Conditional Access policy creation and role management.
• Conditional Access Administrator role · Required for creating and managing Conditional Access policies.

Microsoft Security Copilot provides two complementary access modes. Understanding the differences is critical for planning role-based access and deployment scope.

Standalone Experience

• Access: securitycopilot.microsoft.com - a dedicated portal with full prompt bar and session management.
• Data scope: Cross-product. Copilot can query data from all connected Microsoft security products simultaneously.
• Use case: Complex, cross-product investigations where an analyst needs to correlate data from Defender XDR, Sentinel, Entra, and threat intelligence in a single session.
• Audience: Tier 2/3 analysts, threat hunters, and SOC leads who need maximum flexibility.
• Features: Promptbooks, session history, pinboards, file uploads, custom plugins, full prompt engineering.

Embedded Experience

• Access: Side panel within each Microsoft security product (Defender XDR, Sentinel, Entra, Intune, Purview).
• Data scope: Product-scoped. The embedded Copilot focuses on the data and context of the product you are working in.
• Use case: In-context assistance while working on a specific incident, alert, user, or device within a product.
• Audience: Tier 1 analysts who work primarily within one product at a time.
• Features: Pre-built guided prompts, incident summarisation, natural language to KQL, contextual recommendations.

Comparison Matrix

The Defender XDR embedded experience is the most feature-rich, offering incident summarisation, script analysis, guided response, and natural language to KQL generation directly within the incident workflow.

Key Embedded Capabilities

• Incident summary: Click the Copilot icon on any incident to get an AI-generated summary with affected entities, MITRE techniques, and timeline.
• Guided response: Copilot provides step-by-step remediation recommendations contextual to the specific incident.
• Script analysis: Paste suspicious PowerShell, batch, or script content and get a plain-language explanation of what the script does.
• KQL generation: Describe what you want to hunt for in natural language and Copilot generates the KQL query for Advanced Hunting.
• Device summary: Get a comprehensive overview of a device’s risk, compliance, alerts, and recent activity.

Portal Walkthrough

1. Navigate to security.microsoft.com > Incidents.
2. Open any active incident.
3. Look for the Copilot icon (shield with sparkle) in the incident toolbar or side panel.
4. Click Summarize incident to generate an AI summary.
5. Click Guided response to get recommended remediation steps.
6. Navigate to Advanced Hunting and use the Copilot prompt bar to generate KQL queries.

Verify Copilot Availability in Defender XDR

# Verify that Security Copilot is enabled for Defender XDR
# This checks the current user's access to the Security Copilot service principal
# and confirms the Defender XDR plugin is active

Connect-MgGraph -Scopes "Application.Read.All","SecurityEvents.Read.All"

# Check Security Copilot service principal exists in tenant
$copilotSP = Get-MgServicePrincipal -Filter "displayName eq 'Security Copilot'"
if ($copilotSP) {
    Write-Host "✅ Security Copilot service principal found" -ForegroundColor Green
    Write-Host "   App ID: $($copilotSP.AppId)"
    Write-Host "   Object ID: $($copilotSP.Id)"
} else {
    Write-Host "❌ Security Copilot service principal not found" -ForegroundColor Red
}

# Verify current user has Security Copilot role assignments
$currentUser = Get-MgContext
Write-Host "`nCurrent user: $($currentUser.Account)"

# List Defender XDR incidents to confirm data access
$incidents = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/v1.0/security/incidents?`$top=5"
Write-Host "`nRecent Defender XDR incidents accessible: $($incidents.value.Count)"

The Sentinel embedded experience brings Copilot directly into the incident investigation workflow, providing AI-powered summarisation and analysis scoped to Sentinel data.

Key Embedded Capabilities

• Incident summarisation: Get an AI-generated summary of a Sentinel incident including related alerts, entities, and timeline.
• Guided investigation: Copilot suggests next investigation steps based on the incident context.
• KQL assistance: Generate and explain KQL queries within the Sentinel Logs blade.

Opening the Copilot Panel in Sentinel

1. Navigate to portal.azure.com > Microsoft Sentinel > your workspace.
2. Go to Incidents and open an active incident.
3. Click the Copilot button in the incident toolbar to open the side panel.
4. Use the pre-built prompts or type custom queries about the incident.

Verify Sentinel Incidents Are Accessible

// KQL - Verify Sentinel incidents are accessible to Copilot
// Run this in the Sentinel Logs blade to confirm data availability
// Copilot uses the same data access permissions as the signed-in user
SecurityIncident
| where TimeGenerated > ago(7d)
| summarize
    TotalIncidents = count(),
    OpenIncidents = countif(Status == "New" or Status == "Active"),
    ClosedIncidents = countif(Status == "Closed")
| extend CopilotReady = iff(TotalIncidents > 0, "✅ Incidents available for Copilot", "⚠️ No recent incidents found")
| project CopilotReady, TotalIncidents, OpenIncidents, ClosedIncidents

Security Copilot embedded experiences extend to identity, device management, and data security products, each providing contextual AI assistance.

Microsoft Entra - Risky User Investigation

• Where: Entra admin centre > Identity Protection > Risky users > select a user > Copilot panel.
• Key scenarios: Summarise why a user is flagged as risky, review sign-in anomalies, assess MFA status, and get remediation recommendations.
• Value: Analysts can triage risky users without switching to the standalone Copilot portal or writing manual queries.

Microsoft Intune - Device Troubleshooting

• Where: Intune admin centre > Devices > select a device > Copilot panel.
• Key scenarios: Diagnose device compliance failures, explain error codes, suggest remediation for policy conflicts, and summarise device configuration status.
• Value: Reduces escalation to Tier 2 for routine device issues by providing AI-assisted troubleshooting directly in the Intune console.

Microsoft Purview - DLP and eDiscovery

• Where: Purview compliance portal > DLP alerts or eDiscovery cases > Copilot panel.
• Key scenarios: Summarise DLP policy matches, explain sensitive information types detected, assist with eDiscovery search query construction, and review data classification findings.
• Value: Compliance analysts can get AI assistance for complex DLP investigations and eDiscovery scoping without needing standalone Copilot access.

Conditional Access is the first Zero Trust control to deploy. You will create a policy that requires MFA and compliant devices for all Security Copilot access, and blocks legacy authentication protocols.

Policy Requirements

• Require multi-factor authentication for all Copilot users.
• Require compliant or Hybrid Azure AD joined devices.
• Block legacy authentication protocols.
• Target privileged security roles (Security Administrator, Security Operator).

Create the Conditional Access Policy

# Configure Conditional Access Policy for Security Copilot
# Requires: Microsoft.Graph.Identity.SignIns module
# Scope: Targets privileged security roles accessing Security Copilot
# Controls: MFA + compliant device + block legacy auth

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess","Application.Read.All"

# Get the Security Copilot service principal App ID
$copilotApp = Get-MgServicePrincipal -Filter "displayName eq 'Security Copilot'"
$copilotAppId = $copilotApp.AppId

# Get the security group for Copilot users
$copilotUsersGroup = Get-MgGroup -Filter "displayName eq 'SG-SecurityCopilot-Users'"

# Define the Conditional Access policy
$policyParams = @{
    DisplayName = "CA-SecurityCopilot-RequireMFA-CompliantDevice"
    State       = "enabledForReportingButNotEnforced"  # Report-only first
    Conditions  = @{
        Applications = @{
            IncludeApplications = @($copilotAppId)
        }
        Users = @{
            IncludeGroups = @($copilotUsersGroup.Id)
        }
        ClientAppTypes = @("browser", "mobileAppsAndDesktopClients")
    }
    GrantControls = @{
        BuiltInControls = @("mfa", "compliantDevice")
        Operator        = "AND"
    }
    SessionControls = @{
        SignInFrequency = @{
            Value     = 4
            Type      = "hours"
            IsEnabled = $true
        }
    }
}

# Create the policy in report-only mode
$policy = New-MgIdentityConditionalAccessPolicy -BodyParameter $policyParams
Write-Host "✅ CA policy created: $($policy.DisplayName)" -ForegroundColor Green
Write-Host "   Policy ID: $($policy.Id)"
Write-Host "   State: $($policy.State) (report-only - review before enforcing)"

# Block legacy authentication - separate policy
$legacyBlockParams = @{
    DisplayName = "CA-SecurityCopilot-BlockLegacyAuth"
    State       = "enabledForReportingButNotEnforced"
    Conditions  = @{
        Applications = @{
            IncludeApplications = @($copilotAppId)
        }
        Users = @{
            IncludeGroups = @($copilotUsersGroup.Id)
        }
        ClientAppTypes = @("exchangeActiveSync", "other")
    }
    GrantControls = @{
        BuiltInControls = @("block")
        Operator        = "OR"
    }
}

$legacyPolicy = New-MgIdentityConditionalAccessPolicy -BodyParameter $legacyBlockParams
Write-Host "✅ Legacy auth block policy created: $($legacyPolicy.DisplayName)" -ForegroundColor Green

Security Copilot has two specific roles: Copilot Owner (full administrative control including SCU management and plugin configuration) and Copilot Contributor (can create sessions, run Promptbooks, and use all Copilot features without administrative access). Apply least privilege by assigning the minimum role needed.

Role Comparison

Review and Restrict Role Assignments

# Review current Security Copilot role assignments
# Remove default "All Users" from Contributor and assign specific security groups
# Principle: Only SOC analysts and security engineers should have Copilot access

Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory","Group.Read.All"

# Get Copilot role definitions
$copilotOwnerRole = Get-MgRoleManagementDirectoryRoleDefinition `
    -Filter "displayName eq 'Security Copilot Owner'"
$copilotContribRole = Get-MgRoleManagementDirectoryRoleDefinition `
    -Filter "displayName eq 'Security Copilot Contributor'"

Write-Host "Copilot Owner Role ID: $($copilotOwnerRole.Id)"
Write-Host "Copilot Contributor Role ID: $($copilotContribRole.Id)"

# List current role assignments
Write-Host "`n--- Current Copilot Owner Assignments ---"
Get-MgRoleManagementDirectoryRoleAssignment `
    -Filter "roleDefinitionId eq '$($copilotOwnerRole.Id)'" |
    ForEach-Object {
        $principal = Get-MgDirectoryObject -DirectoryObjectId $_.PrincipalId
        Write-Host "  $($principal.AdditionalProperties.displayName) ($($_.PrincipalId))"
    }

Write-Host "`n--- Current Copilot Contributor Assignments ---"
Get-MgRoleManagementDirectoryRoleAssignment `
    -Filter "roleDefinitionId eq '$($copilotContribRole.Id)'" |
    ForEach-Object {
        $principal = Get-MgDirectoryObject -DirectoryObjectId $_.PrincipalId
        Write-Host "  $($principal.AdditionalProperties.displayName) ($($_.PrincipalId))"
    }

# Create targeted security groups for role assignment
$tier1Group = Get-MgGroup -Filter "displayName eq 'SG-SOC-Tier1-Analysts'"
$tier2Group = Get-MgGroup -Filter "displayName eq 'SG-SOC-Tier2-Analysts'"
$socLeadsGroup = Get-MgGroup -Filter "displayName eq 'SG-SOC-Leads'"

# Assign Copilot Contributor to Tier 1 and Tier 2 analysts
@($tier1Group, $tier2Group) | ForEach-Object {
    if ($_) {
        New-MgRoleManagementDirectoryRoleAssignment -RoleDefinitionId $copilotContribRole.Id `
            -PrincipalId $_.Id -DirectoryScopeId "/"
        Write-Host "✅ Assigned Copilot Contributor to $($_.DisplayName)" -ForegroundColor Green
    }
}

# Assign Copilot Owner to SOC Leads only (via PIM in Step 7)
Write-Host "`n⚠️ Copilot Owner role should be assigned via PIM (see Step 7)" -ForegroundColor Yellow

Privileged Identity Management (PIM) ensures the Copilot Owner role is only active when needed. Users must explicitly activate the role with justification, and the activation expires after a defined period.

PIM Configuration

# Configure PIM for the Security Copilot Owner role
# Requires: Microsoft.Graph.Identity.Governance module + Entra ID P2 license
# This makes the Owner role eligible (not active) with approval + justification

Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory","PrivilegedAccess.ReadWrite.AzureADGroup"

# Get the Copilot Owner role definition
$copilotOwnerRole = Get-MgRoleManagementDirectoryRoleDefinition `
    -Filter "displayName eq 'Security Copilot Owner'"

# Get the SOC Leads group (eligible for Copilot Owner)
$socLeadsGroup = Get-MgGroup -Filter "displayName eq 'SG-SOC-Leads'"

# Create PIM eligible assignment for SOC Leads
$eligibleParams = @{
    Action           = "adminAssign"
    RoleDefinitionId = $copilotOwnerRole.Id
    PrincipalId      = $socLeadsGroup.Id
    DirectoryScopeId = "/"
    Justification    = "SOC Leads eligible for Copilot Owner role via PIM"
    ScheduleInfo     = @{
        StartDateTime = (Get-Date).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ")
        Expiration    = @{
            Type     = "afterDuration"
            Duration = "P365D"  # Eligibility lasts 1 year, then must be renewed
        }
    }
}

$eligibleAssignment = New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest `
    -BodyParameter $eligibleParams

Write-Host "✅ PIM eligible assignment created for SOC Leads" -ForegroundColor Green
Write-Host "   Role: Security Copilot Owner"
Write-Host "   Group: $($socLeadsGroup.DisplayName)"

# Configure PIM role settings - activation requires approval and justification
# Maximum activation duration: 4 hours
# Require justification: Yes
# Require approval: Yes
# Approvers: Security Operations Manager group

Write-Host "`n📋 PIM Role Settings to configure in the portal:" -ForegroundColor Cyan
Write-Host "   1. Navigate to Entra admin centre > Identity Governance > PIM"
Write-Host "   2. Select 'Azure AD roles' > 'Roles' > 'Security Copilot Owner'"
Write-Host "   3. Click 'Role settings' > 'Edit'"
Write-Host "   4. Set maximum activation duration: 4 hours"
Write-Host "   5. Require justification on activation: Yes"
Write-Host "   6. Require approval to activate: Yes"
Write-Host "   7. Add approvers: SG-Security-Operations-Managers"
Write-Host "   8. Require MFA on activation: Yes"
Write-Host "   9. Click 'Update'"

Zero Trust requires that privileged access to Security Copilot (especially the standalone portal) occurs only from trusted, hardened devices. Privileged Access Workstations (PAWs) provide a clean, dedicated environment for security operations.

PAW Requirements for SOC Analysts

• Device compliance: Must be Intune-managed, fully patched, encrypted with BitLocker, and running a supported OS version.
• Defender for Endpoint: Must be onboarded with no active high-severity alerts.
• Network isolation: PAWs should have restricted internet access - only allow access to Microsoft security portals and approved security tools.
• Application control: Use Windows Defender Application Control (WDAC) to allow only approved applications.
• No personal use: PAWs are dedicated to security operations only.

Intune Compliance Policy Configuration

1. Navigate to Intune admin centre > Devices > Compliance policies > Create policy.
2. Platform: Windows 10 and later.
3. Name: PAW-SOC-CompliancePolicy.
4. Configure the following settings:
   • BitLocker: Required
   • Secure Boot: Required
   • Minimum OS version: 10.0.19045 (Windows 10 22H2) or later
   • Microsoft Defender Antimalware: Required
   • Microsoft Defender for Endpoint risk level: Clear (no active threats)
   • Firewall: Required
5. Assign to the SG-SOC-PAW-Devices device group.
6. Set non-compliance action: mark device as non-compliant immediately.

Security Copilot supports third-party plugins that extend its capabilities. However, these plugins introduce trust boundaries that must be governed under Zero Trust principles.

Trust Boundary Considerations

• Data flow: When Copilot invokes a third-party plugin, it may send security data (IOCs, incident details, user information) to that third party’s API.
• Authentication: Third-party plugins use API keys or OAuth tokens. These credentials must be stored securely and rotated regularly.
• Scope: Only enable plugins that are necessary for your SOC workflows. Disable unused plugins to reduce the attack surface.
• Approval process: Establish a review process where the security team must approve any new third-party plugin before it is enabled in production.

Governance Controls for Plugins

1. Inventory all enabled plugins in the Security Copilot owner settings and document which teams use each plugin.
2. Create a Conditional Access policy for each third-party SaaS application that Copilot plugins connect to (e.g., VirusTotal, Shodan).
3. Monitor plugin activity using Defender for Cloud Apps to track data sent to third-party services.
4. Review API key permissions quarterly to ensure they have minimum necessary access.
5. Maintain a plugin approval register documenting: plugin name, vendor, data shared, approved by, review date.

A phased deployment reduces risk and allows you to validate each stage before scaling. The three phases are: Evaluate (prove value with a small group), Pilot (expand to a broader team with governance), and Full Deployment (organisation-wide rollout).

Phase Model

Create Security Groups for Each Phase

# Create security groups for phased Copilot deployment
# Each group controls Copilot access at a specific deployment phase
# Users move from Evaluate → Pilot → FullDeployment as phases progress

Connect-MgGraph -Scopes "Group.ReadWrite.All"

$phases = @(
    @{
        Name        = "SG-Copilot-Phase1-Evaluate"
        Description = "Phase 1: Evaluation group - senior analysts validating Security Copilot value and SCU consumption"
    },
    @{
        Name        = "SG-Copilot-Phase2-Pilot"
        Description = "Phase 2: Pilot group - Tier 2 analysts with full Copilot access, Promptbooks, and governance framework"
    },
    @{
        Name        = "SG-Copilot-Phase3-FullDeployment"
        Description = "Phase 3: Full deployment - all SOC analysts with role-appropriate Copilot access"
    }
)

foreach ($phase in $phases) {
    $group = New-MgGroup -DisplayName $phase.Name `
        -Description $phase.Description `
        -MailEnabled:$false `
        -MailNickname ($phase.Name -replace '[^a-zA-Z0-9]','') `
        -SecurityEnabled:$true `
        -GroupTypes @()
    Write-Host "✅ Created group: $($group.DisplayName) (ID: $($group.Id))" -ForegroundColor Green
}

Write-Host "`n📋 Next: Add senior analysts to Phase 1 group and assign Copilot Contributor role"

Monitoring who uses Security Copilot, how often, and how much SCU they consume is essential for governance, cost management, and demonstrating value to leadership.

Track Usage via Audit Logs

// KQL - Track Security Copilot usage across the organisation
// Data source: Unified Audit Log ingested into Sentinel
// Metrics: unique users, session count, prompt volume by day
AuditLogs
| where TimeGenerated > ago(30d)
| where TargetResources has "Security Copilot"
    or LoggedByService == "Security Copilot"
| summarize
    UniqueUsers      = dcount(InitiatedBy.user.userPrincipalName),
    TotalSessions    = dcount(CorrelationId),
    TotalPrompts     = count()
    by bin(TimeGenerated, 1d)
| order by TimeGenerated desc
| render timechart

Per-User Consumption Summary

// KQL - Per-user Security Copilot consumption for cost allocation
// Use this to identify heavy users, low-adoption users, and unusual spikes
AuditLogs
| where TimeGenerated > ago(30d)
| where TargetResources has "Security Copilot"
    or LoggedByService == "Security Copilot"
| extend UserUPN = tostring(InitiatedBy.user.userPrincipalName)
| summarize
    PromptCount    = count(),
    SessionCount   = dcount(CorrelationId),
    FirstUsed      = min(TimeGenerated),
    LastUsed       = max(TimeGenerated),
    ActiveDays     = dcount(bin(TimeGenerated, 1d))
    by UserUPN
| extend AvgPromptsPerDay = round(todouble(PromptCount) / ActiveDays, 1)
| order by PromptCount desc

Beyond usage monitoring, audit for anomalous access patterns that could indicate misuse or compromise of a Security Copilot account.

Detect Anomalous Usage

// KQL - Detect anomalous Security Copilot usage patterns
// Flags: unusual hours, bulk queries, new users, and access from unusual locations
let NormalHoursStart = 6;   // 06:00 local time
let NormalHoursEnd   = 22;  // 22:00 local time
let BulkThreshold    = 50;  // More than 50 prompts in 1 hour is anomalous
AuditLogs
| where TimeGenerated > ago(7d)
| where TargetResources has "Security Copilot"
    or LoggedByService == "Security Copilot"
| extend
    UserUPN   = tostring(InitiatedBy.user.userPrincipalName),
    HourOfDay = hourofday(TimeGenerated),
    IPAddress = tostring(InitiatedBy.user.ipAddress)
| summarize
    PromptCount = count(),
    UniqueIPs   = dcount(IPAddress),
    Hours       = make_set(HourOfDay)
    by UserUPN, bin(TimeGenerated, 1h)
| where PromptCount > BulkThreshold
    or Hours has_any (dynamic([0,1,2,3,4,5,23]))  // Outside normal hours
| extend AnomalyType = case(
    PromptCount > BulkThreshold, "Bulk query volume",
    Hours has_any (dynamic([0,1,2,3,4,5,23])), "Off-hours access",
    "Other"
)
| project TimeGenerated, UserUPN, PromptCount, AnomalyType, UniqueIPs

Detect New or Unexpected Users

// KQL - Identify first-time Security Copilot users
// Alert on users who appear for the first time - may indicate role misconfiguration
let KnownUsers = AuditLogs
    | where TimeGenerated between (ago(90d) .. ago(7d))
    | where TargetResources has "Security Copilot"
        or LoggedByService == "Security Copilot"
    | distinct tostring(InitiatedBy.user.userPrincipalName);
AuditLogs
| where TimeGenerated > ago(7d)
| where TargetResources has "Security Copilot"
    or LoggedByService == "Security Copilot"
| extend UserUPN = tostring(InitiatedBy.user.userPrincipalName)
| where UserUPN !in (KnownUsers)
| summarize FirstSeen = min(TimeGenerated), PromptCount = count() by UserUPN
| order by FirstSeen desc

A governance framework documents your organisation’s policies, rules, and processes for Security Copilot usage. This is essential for audit readiness and consistent operations.

Governance Document Structure

Before declaring full deployment readiness, use this executive checklist to verify all Zero Trust controls are in place.

Executive Zero Trust Readiness Checklist

What You Accomplished

In this lab you:

• Understood the differences between standalone and embedded Security Copilot experiences.
• Explored Copilot embedded in Defender XDR, Sentinel, Entra, Intune, and Purview.
• Configured Conditional Access policies requiring MFA and compliant devices for Copilot access.
• Applied least privilege by assigning Copilot Owner and Copilot Contributor roles to specific security groups.
• Configured Microsoft Entra PIM for time-bound, approval-based Copilot Owner access.
• Established privileged access workstation requirements with Intune compliance policies.
• Implemented governance controls for third-party plugin access.
• Planned a phased deployment model (Evaluate → Pilot → Full) with dedicated security groups.
• Created KQL queries to monitor Copilot usage and detect anomalous access patterns.
• Built a comprehensive Copilot governance framework for audit readiness.

Next Steps

• Execute your phased deployment plan, starting with the Evaluate group of senior analysts.
• Build Sentinel workbooks from the KQL queries in Steps 11–12 for persistent monitoring dashboards.
• Schedule quarterly access reviews for Copilot role assignments and plugin approvals.
• Share the governance framework with all SOC personnel and include it in new-hire onboarding.
• Revisit Conditional Access policies as Microsoft releases new Copilot features and embedded experiences.