Use this skill when asked to detect scope drift, behavioral expansion, or gradual privilege/access creep in service principals or automation accounts. Triggers on keywords like "scope drift", "service principal drift", "SPN behavioral change", "automation account drift", "baseline deviation", "access expansion", or when investigating whether a service principal has gradually expanded beyond its intended purpose. This skill builds a 90-day behavioral baseline per SPN, compares it with 7-day recent activity, computes a weighted Drift Score across 5 dimensions, and correlates with SecurityAlert and AuditLogs for corroborating evidence.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Use this skill when asked to detect scope drift, behavioral expansion, or gradual privilege/access creep in service principals or automation accounts. Triggers on keywords like "scope drift", "service principal drift", "SPN behavioral change", "automation account drift", "baseline deviation", "access expansion", or when investigating whether a service principal has gradually expanded beyond its intended purpose. This skill builds a 90-day behavioral baseline per SPN, compares it with 7-day recent activity, computes a weighted Drift Score across 5 dimensions, and correlates with SecurityAlert and AuditLogs for corroborating evidence.
threat_pulse_domains
["spn"]
drill_down_prompt
Analyze service principal drift for {entity} โ resource/IP/location expansion
Service Principal Scope Drift Detection โ Instructions
Purpose
Credit: The scope drift detection concept for service principals was inspired by Iftekhar Hussain's article The Agentic SOC Era: How Sentinel MCP Enables Autonomous Security Reasoning (Feb 2026), which demonstrated multi-source correlation across AADServicePrincipalSignInLogs, AuditLogs, and SecurityAlert to build 90-day behavioral baselines and surface drift via weighted scoring.
This skill detects scope drift โ the gradual, often imperceptible expansion of access or behavior beyond an established baseline โ in . Unlike sudden compromise (which triggers alerts), scope drift is a slow-burn pattern that evades threshold-based detections.
IP infrastructure expansion (TP Q5, high IPDrift): Q1 (new IPs list from NewIPs array) โ anti-join baseline IPs to identify novel sources โ IP enrichment (enrich_ips.py or ioc-investigation) for non-Azure IPs
โ Shortcut Default Rule: When a matching shortcut exists for the investigation context, use it โ don't run the full workflow. Only run the full query set when the user explicitly requests "full investigation", "comprehensive", or "deep dive". Shortcuts render only the report sections relevant to their query chain (plus Executive Summary and Recommendations, always).
โ ๏ธ CRITICAL WORKFLOW RULES - READ FIRST โ ๏ธ
Before starting ANY SPN scope drift analysis:
ALWAYS enforce Sentinel workspace selection (see Workspace Selection section below)
ALWAYS ask the user for output mode if not specified: inline chat summary or markdown file report (or both)
ALWAYS build baseline FIRST before comparing recent activity
ALWAYS apply the low-volume denominator floor to prevent false-positive drift scores on sparse baselines
ALWAYS correlate across all required data sources (AADServicePrincipalSignInLogs, AuditLogs, SecurityAlert)
ALWAYS run independent queries in parallel for performance
NEVER report a drift flag without corroborating evidence from at least one secondary data source
Data Sources
Data Source
Role
Purpose
AADServicePrincipalSignInLogs
โ Primary
SPN sign-in behavioral baseline
AuditLogs
โ Corroboration
Permission/credential/role changes
SecurityAlert
โ Corroboration
Corroborating alert evidence
SecurityIncident
โ Corroboration
Real alert status/classification
โ MANDATORY: Sentinel Workspace Selection
This skill requires a Sentinel workspace to execute queries. Follow these rules STRICTLY:
When invoked from incident-investigation skill:
Inherit the workspace selection from the parent investigation context
If no workspace was selected in parent context: STOP and ask user to select
When invoked standalone (direct user request):
ALWAYS call list_sentinel_workspaces MCP tool FIRST
If 1 workspace exists: Auto-select, display to user, proceed
If multiple workspaces exist:
Display all workspaces with Name and ID
ASK: "Which Sentinel workspace should I use for this investigation?"
โ STOP AND WAIT for user response
โ DO NOT proceed until user explicitly selects
If a query fails on the selected workspace:
โ DO NOT automatically try another workspace
STOP and report the error, display available workspaces, ASK user to select
๐ด PROHIBITED ACTIONS:
โ Selecting a workspace without user consent when multiple exist
โ Switching to another workspace after a failure without asking
โ Proceeding with investigation if workspace selection is ambiguous
Output Modes
This skill supports two output modes. ASK the user which they prefer if not explicitly specified. Both may be selected.
Mode 1: Inline Chat Summary (Default)
Render the full drift analysis directly in the chat response
Includes ASCII tables, Pareto chart, drift dimension bars, and security assessment
Best for quick review and interactive follow-up questions
Mode 2: Markdown File Report
Save a comprehensive report to reports/scope-drift/spn/Scope_Drift_Report_<entity>_<timestamp>.md
All ASCII visualizations render correctly inside markdown code fences (```)
Includes all data from inline mode plus additional detail sections
Use create_file tool โ NEVER use terminal commands for file output
Filename patterns:
Single SPN:Scope_Drift_Report_<spn_short_name>_YYYYMMDD_HHMMSS.md (use display name, sanitized: lowercase, spaces/special chars replaced with hyphens)
All SPNs:Scope_Drift_Report_all_spns_YYYYMMDD_HHMMSS.md (tenant-wide scan of all service principals)
Markdown Rendering Notes
โ ASCII tables, box-drawing characters, and bar charts render perfectly in markdown code blocks
โ Unicode block characters (โ full block, โ box-drawing horizontal) display correctly in monospaced fonts
Run Phases 2-3 โ Queries 2-4 (AuditLogs + SecurityAlert) โ scoped per tier
Compute Final Assessment โ Combine drift scores with corroborating evidence
Output Results โ Render in selected mode(s) with tiered depth
Entity Scaling (Large Environments)
Problem: In small tenants, running Queries 2โ4 for every SPN is fine. In enterprise environments with hundreds or thousands of service principals, running deep-dive queries for every flagged entity is prohibitively expensive and produces unreadable reports.
Solution: After Phase 1 computes drift scores for all SPNs, apply tiered depth based on entity count and drift severity.
Entity Count Detection
After Query 1, count distinct SPNs in the result set:
Entity Count
Tier
Deep Dive Limit
Behavior
โค 30 SPNs
Small
All flagged
Full deep dive for every SPN > 150%. No limiting needed.
31โ100 SPNs
Medium
Top 10
Full deep dive for top 10 by DriftScore. Summary row for remaining flagged SPNs.
101โ500 SPNs
Large
Top 10
Full deep dive for top 10. Tier 2 summary (next 15) with new resources/IPs only. Remaining flagged SPNs listed in ranking table with scores but no deep dive.
> 500 SPNs
Very Large
Top 10
Same as Large, plus: filter Phase 1 results to BL_TotalSignIns > 10 to exclude near-silent SPNs from scoring.
Tiered Depth Model
After computing drift scores and ranking all SPNs, assign tiers:
Tier
Entities
Queries Run
Report Depth
Tier 1 (Full)
Top N by DriftScore
All: Q2, Q3, Q4
Full deep dive: ASCII chart, dimension table, new resources/IPs/locations, AuditLog changes, alerts
Tier 2 (Summary)
Next 15 flagged SPNs (or remaining if < 15)
Q4 only (SecurityAlert correlation)
One-line summary per SPN: score, top 3 new resources, new IPs, flag status
Tier 3 (Score only)
All remaining flagged SPNs
None beyond Phase 1
Row in ranking table: SPN name, drift score, dimension ratios, flag emoji
Stable
SPNs โค 150%
None beyond Phase 1
Omitted from deep dives. Included in summary statistics only.
User Override
If the user explicitly asks for "all SPNs detailed" or "full report", honor the request but warn:
โ ๏ธ Tenant has service principals with flagged above 150%. Running full deep dives for all flagged SPNs may be slow and produce a very long report. Proceed? (Default: top 10 deep dives + summary for others)
Report Disclosure
When tiered depth is applied, always disclose in the report header:
**Entity Count:** <N> service principals (Large tenant โ tiered analysis applied)
**Deep Dives:** Top <X> by DriftScore (Tier 1: full analysis)
**Summaries:** <Y> additional flagged SPNs (Tier 2: alert correlation only)
**Score Only:** <Z> additional flagged SPNs (Tier 3: ranking table only)
**Stable:** <W> SPNs โค 150% (omitted from deep dives)
Drift Score Formula
The Drift Score is a weighted composite of behavioral dimensions, normalized so that 100 = identical to baseline.
CRITICAL: For entities with sparse baselines (< 10 daily sign-ins), the volume ratio is artificially inflated. Apply a floor:
IF BL_DailyAvg < 10:
AdjustedVolumeRatio = RC_DailyAvg / max(BL_DailyAvg, 10) * 100
Flag the score with: "โ ๏ธ Low-volume baseline โ ratio may be inflated"
This prevents an entity averaging 1 sign-in/day from triggering at 6 sign-ins/day (600% ratio but trivial absolute volume).
CRITICAL: The FailRate dimension is a percentage-point delta, not a multiplicative ratio like the other dimensions. Convert it to the same 0โ200+ scale using this formula:
FailRateDelta = RecentFailRate - BaselineFailRate (percentage points)
FailRateRatio = 100 + (FailRateDelta ร 10) (scaled: each +1pp = +10 on the ratio scale)
Baseline FailRate
Recent FailRate
Delta
Ratio
Interpretation
5.00%
5.00%
0.00
100.0
No change
5.00%
8.00%
+3.00
130.0
Moderate increase
5.00%
12.00%
+7.00
170.0
๐ด Above threshold
5.00%
2.00%
-3.00
70.0
Improving (contracting)
0.00%
0.00%
0.00
100.0
No change (both clean)
0.00%
5.00%
+5.00
150.0
๐ก At threshold โ new failures appearing
Edge case: Baseline = 0% avoids division-by-zero because delta is additive, not multiplicative. The scaling factor (ร10) means each percentage point of failure rate increase maps to 10 points on the drift scale. This keeps FailRate on the same magnitude as the other dimensions.
In the ASCII chart: Show the ratio as the bar fill percentage and append the raw delta as direction indicator: ^+X.XX (increasing) or v-X.XX (decreasing).
Execution Workflow
Phase 1: Behavioral Baseline vs. Recent Comparison
Baseline window: 90 days (days 8โ97 ago)
Recent window: 7 days (last 7 days)
This is the primary query that computes per-SPN behavioral profiles and drift metrics.
Data Source
Query
Notes
AADServicePrincipalSignInLogs
Query 1
Single query, 5 dimensions
Phase 2: Permission & Configuration Change Audit
Data source:AuditLogsCorrelation: Same 97-day window, filtered to SPNs from Phase 1
Operations to Look For:
Add/Remove service principal credentials
Update application โ Certificates and secrets management
Consent to application
Add delegated permission grant
Add app role assignment to service principal
Add application
Add service principal
Any operation containing: "permission", "role", "consent", "oauth", "credential", "certificate", "secret"
Phase 3: Security Alert Correlation
Run Query 4 in parallel with Phase 2 queries for performance.
SecurityAlert + SecurityIncident (Query 4): Check for alerts referencing SPN IDs or names, joined with SecurityIncident for real status/classification. Never read SecurityAlert.Status directly โ it's always "New".
Phase 4: Score Computation & Report Generation
Compute DriftScore per SPN using the 5-dimension formula
Apply the low-volume denominator floor
Flag any entity exceeding 150% threshold
For flagged entities: assess corroborating evidence (permission changes, alerts)
Generate risk assessment with emoji-coded findings
Render output in the user's selected mode
Sample KQL Queries
Query 1: Baseline vs. Recent Behavioral Comparison
Post-processing note: The low-volume denominator floor (max(BL_DailyAvg, 10)) is NOT applied in the KQL above โ it must be applied during post-processing when computing the final assessment. If BL_DailyAvg < 10, recalculate VolumeRatio using the floor value and recompute DriftScore. Flag affected SPNs with: "โ ๏ธ Low-volume baseline โ ratio may be inflated."
Query 2: AuditLog Permission & Credential Changes
// Permission/credential/role changes for service principals
// Substitute <SPN_IDS> with comma-separated SPN IDs from Query 1
// Substitute <SPN_NAMES> with SPN display names from Query 1
AuditLogs
| where TimeGenerated > ago(97d)
| where OperationName has_any ("service principal", "application", "credential", "certificate",
"secret", "permission", "role", "consent", "oauth")
| where tostring(TargetResources) has_any (<SPN_IDS>)
or tostring(InitiatedBy) has_any (<SPN_IDS>)
| extend InBaseline = TimeGenerated < ago(7d)
| summarize
BaselineOps = countif(InBaseline),
RecentOps = countif(not(InBaseline))
by OperationName
| order by RecentOps desc
Query 3: Detailed Recent AuditLog Changes
// Detailed drill-down for the recent 7-day window
// Substitute <SPN_IDS> with SPN IDs from Query 1
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has_any ("service principal", "application", "credential", "certificate",
"secret", "permission", "role", "consent", "oauth", "update")
| where tostring(TargetResources) has_any (<SPN_IDS>)
| project TimeGenerated, OperationName, Result,
InitiatedBy = tostring(parse_json(tostring(InitiatedBy)).app.displayName),
TargetName = tostring(parse_json(tostring(parse_json(tostring(TargetResources))[0])).displayName),
TargetId = tostring(parse_json(tostring(parse_json(tostring(TargetResources))[0])).id),
ModifiedProperties = tostring(parse_json(tostring(parse_json(tostring(TargetResources))[0])).modifiedProperties)
| order by TimeGenerated desc
๐ข False alarm โ discount from drift risk, note as noise
Closed
BenignPositive
๐ก Expected behavior โ note but don't escalate
Active/New
Any
๐ Unresolved โ flag for attention, may indicate ongoing threat
Product Name Mapping (Legacy โ Current Branding):
The ProductName field in SecurityAlert contains the detection product. When rendering reports, translate to current Microsoft branding:
SecurityAlert.ProductName (raw)
Report Display Name
Microsoft Defender Advanced Threat Protection
Microsoft Defender for Endpoint
Microsoft Cloud App Security
Microsoft Defender for Cloud Apps
Microsoft Data Loss Prevention
Microsoft Purview Data Loss Prevention
Azure Sentinel
Microsoft Sentinel
Microsoft 365 Defender
Microsoft Defender XDR
Office 365 Advanced Threat Protection
Microsoft Defender for Office 365
Azure Advanced Threat Protection
Microsoft Defender for Identity
Note:ProviderName (e.g., ASI Scheduled Alerts, MDATP, MCAS) is the internal provider identifier. ProductName (e.g., Azure Sentinel, Microsoft Defender Advanced Threat Protection) is the user-facing product name. Always use ProductName for grouping and display; ProviderName is unreliable for product identification (e.g., all alerts show as Microsoft XDR at the incident level).
Report Rendering: Group alerts by product using the current branded name. Show Baseline Alerts vs Recent Alerts and Baseline Incidents vs Recent Incidents columns per product row, plus Severity and Classification. Include a Total row. Add a brief 1-2 sentence summary comparing alert volume between periods. Do NOT list individual alert names โ keep the table concise at the product level.
Report Template
Inline Chat Report Structure
The inline report MUST include these sections in order:
Header โ Workspace, analysis period, drift threshold, data sources
Ranked Drift Score Table โ All SPNs sorted by DriftScore descending, with per-dimension ratios
Flagged Entity Deep Dive (for each Tier 1 SPN > 150%) โ Baseline vs. recent comparison, dimension bar chart, new IPs/resources, corroborating evidence
Tier 2 Entity Summaries (if entity scaling applied) โ One-line summary per Tier 2 SPN: score, top 3 new resources, new IPs, alert count
Correlated Signal Summary โ AuditLogs and SecurityAlert/Incident findings in a single table
Behavioral Baseline Chart โ ASCII bar chart showing all SPNs' daily avg vs. baseline
Security Assessment โ Emoji-coded findings table with evidence citations
Verdict Box โ Overall risk level, root cause analysis, recommendations
Markdown File Report Structure
When outputting to markdown file, include everything from the inline format PLUS:
Filename patterns:
Single SPN:reports/scope-drift/spn/Scope_Drift_Report_<spn_short_name>_YYYYMMDD_HHMMSS.md
All SPNs:reports/scope-drift/spn/Scope_Drift_Report_all_spns_YYYYMMDD_HHMMSS.md
# Service Principal Scope Drift Report**Generated:** YYYY-MM-DD HH:MM UTC
**Workspace:**<workspace_name>**Baseline Period:**<start> โ <end> (90 days)
**Recent Period:**<start> โ <end> (7 days)
**Drift Threshold:** 150%
**Data Sources:** AADServicePrincipalSignInLogs, AuditLogs, SecurityAlert
---
## Executive Summary
<1-3 sentence summary: how many SPNs analyzed, how many flagged, overall risk level>
---
## Drift Score Ranking<ASCIItablewithallSPNs, per-dimensionratios, flagstatus>
<!-- Wrap in code fence for consistent rendering -->
---
## Flagged Entities### <SPNName> โ Drift Score <score>**ASCII Drift Dimension Chart (REQUIRED):**
Render a box-drawn chart inside a code fence. **Inner width: 58 chars** (every line between `โ` markers = exactly 58 visual characters). No emoji inside boxes โ use text labels.
**Alignment:** Name (9 chars padded) + weight (5) + gap (2) + bars (20 `โโ`) + gap (2) + pct (6, right-aligned: `XXX.X%` or ` XX.X%`) + gap (2) + direction (10 total: `^`/`v`/`=` + 9 trailing spaces, or FailRate: delta like `v-X.XX` + 4 trailing spaces). Status labels (centered): `STABLE`, `STABLE (Low-Volume)`, `NEAR THRESHOLD`, `ABOVE THRESHOLD`, `CRITICAL`. Direction: `^` (up), `v` (down), `=` (stable).
**Bar characters:** Use `โ` (U+2588 full block) for filled portions and `โ` (U+2500 box-drawing horizontal) for the unfilled track.
**Bar fill:** 20 chars wide. Filled = round(ratio/100 ร 20), capped at 20. Title and status: center within 58 chars (include adjusted score if applicable, e.g., "SPN DRIFT SCORE: 107.5 (adj 80.5)"). Use `โ` for filled, `โ` for unfilled.
**Then** render the standard markdown dimension table:
| Dimension | Weight | Baseline (90d) | Recent (7d) | Ratio | Weighted | Status |
|-----------|--------|----------------|-------------|-------|----------|--------|
<New resources, new IPs, new locations enumeration>
<Corroborating evidence from AuditLogs, SecurityAlert>
---
## Pareto Analysis
<ASCII Pareto chart of drift dimensions or categories>
<80/20 analysis text>
---
## Correlated Signals
| Data Source | Finding | Incident Status |
|-------------|---------|-----------------|
| AADServicePrincipalSignInLogs | ... | N/A |
| AuditLogs | ... | N/A |
| SecurityAlert / SecurityIncident | <Group by ProductName, translate to current branding> | <Status: New/Active/Closed, Classification: TP/FP/BP> |
---
## Security Assessment
| Factor | Finding |
|--------|---------|
| ๐ด/๐ข/๐ก **Factor** | Evidence-based finding |
---
## Verdict
**ASCII Verdict Box (REQUIRED):**
Render a box-drawn verdict summary inside a code fence. **Inner width: 66 chars.** No emoji inside boxes. Pad every line to exactly 66 chars between `โ` markers.
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ OVERALL RISK: -- โ
โ Flagged SPNs: X of Y (Threshold: 150%) โ
โ Root Cause: โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
**Then** render the full verdict with:
- Root Cause Analysis paragraph
- Key Findings (numbered list)
- Recommendations (emoji-prefixed list)
---
## Appendix: Query Details
Render a single markdown table summarizing all queries executed. **Do NOT include full KQL text** โ the canonical queries are already documented in this SKILL.md file. The appendix serves as an audit trail only.
| Query | Table(s) | Records Scanned | Results | Execution |
|-------|----------|----------------:|--------:|----------:|
| Q1 โ SPN Baseline vs. Recent | AADServicePrincipalSignInLogs | X,XXX | N rows | X.XXs |
| ... | ... | ... | ... | ... |
*Query definitions: see the Sample KQL Queries section in this SKILL.md file.*
Known Pitfalls
SecurityAlert.Status Is Immutable โ Always Join SecurityIncident
Problem: The Status field on SecurityAlert is set to "New" at creation time and never changes. It does NOT reflect whether the alert has been investigated, closed, or classified. Reading SecurityAlert.Status as current investigation status will always show "New" regardless of actual state.
Solution: MUST join with SecurityIncident to get real Status (New/Active/Closed) and Classification (TruePositive/FalsePositive/BenignPositive). See Query 4 which implements this join. When assessing drift risk from alerts, differentiate: Closed-FalsePositive alerts are noise (discount), Closed-TruePositive alerts are confirmed threats (escalate), Active/New incidents need attention (flag).
Low-Volume Statistical Inflation
Problem: Entities with very low baseline activity (e.g., 1 sign-in/day) will show extreme volume ratios even with minor changes.
Solution: Apply the denominator floor (minimum 10 sign-ins/day for volume ratio calculation). Always flag low-volume baselines in the report.
Seasonal/Cyclical Baselines
Problem: Some entities have weekly patterns (lower on weekends) or monthly cycles (month-end batch jobs).
Solution: Note if the 7-day recent window falls on an atypical portion of the cycle. The 90-day baseline smooths most cyclical patterns, but edge cases exist.
IPv6 Fabric Address Churn
Problem: Microsoft first-party SPNs (MCAS, Defender, etc.) rotate through fd00: internal fabric IPv6 addresses automatically. This inflates the IP ratio without representing actual infrastructure changes.
Solution: When all new IPs share the same fd00: prefix, note this as "Microsoft internal fabric rotation" and downgrade the IP dimension's contribution to the drift score assessment. Do NOT flag IPv6 churn from Microsoft fabric addresses as suspicious.
Credential Rotation False Positives
Problem: Automated certificate/secret rotation creates regular Add/Remove service principal credentials audit entries.
Solution: Check if credential operations follow a regular cadence (weekly/monthly). If rotation is periodic and consistent with baseline, classify as operational โ not drift.
SPNs Without Baseline Data
Problem: Newly provisioned SPNs have no baseline to compare against.
Solution: These are excluded from the join kind=inner and will not appear in results. If the user asks about a specific SPN with no baseline, report: "No baseline data available โ SPN was provisioned within the recent window or has no sign-in history in the 90-day baseline period."
Sentinel IDs vs Defender XDR IDs for Triage MCP Drill-Down
Problem: Query 4 returns IncidentNumber (Sentinel) and SystemAlertId (Sentinel), but the Triage MCP tools (GetIncidentById, GetAlertById) expect Defender XDR IDs. Passing Sentinel IDs returns "not found" errors.
Solution: When following up on correlated alerts/incidents via Triage MCP:
Incidents: Always project ProviderIncidentId from SecurityIncident and pass that to GetIncidentById โ never use IncidentNumber
Alerts: Extract the Defender ID from SecurityAlert: tostring(parse_json(ExtendedProperties).IncidentId) โ never use SystemAlertId with the Triage MCP
The YAML manifest is the single source of truth for layout, widgets, field mappings, colors, and data source documentation. All customization happens there.
