Portal Walkthrough — Control 3.9: Microsoft Sentinel Integration for AI Agent Monitoring

READ FIRST — Scope and Sibling Routing

This walkthrough covers portal-first deployment of Microsoft Sentinel for AI agent monitoring across Microsoft 365 Copilot, Copilot Studio, Power Platform agents, and Entra workload identities. It is the primary operational procedure for Control 3.9 and is intended to be executed by the Sentinel Admin with input from the SOC Analyst, AI Governance Lead, Entra Security Admin, and Power Platform Admin.

In scope

Topic	Where it lives
Pre-flight roles, licensing, workspace decisions	§0
Sovereign cloud variant and compensating controls	§1
Workspace deployment via the Defender portal (security.microsoft.com)	§2
Data connectors (M365 / Entra human + workload SP / Defender / Defender for Cloud Apps / Copilot / Power Platform / optional App Insights)	§3
Agent-specific analytics rules (7 rules)	§4
Workbooks (AI Agent Security Posture, CA Insights, Agent Usage & Performance)	§5
Logic Apps automation playbooks (suspend agent, notify Owner + SOC, ITSM + NYDFS 500.17 timer)	§6
Per-table retention configuration with the books-and-records boundary	§7
Defender portal unified incident UX with agent enrichment	§8
Sentinel MCP Server as optional analyst augmentation	§9
Evidence capture, zone cadence, and examiner packet	§10

Out of scope — routed to siblings

Topic	Route to
Bicep / ARM / az-cli / Graph automation of Sentinel artifacts	powershell-setup.md
KQL detection-rule unit tests, dry-run alerts, and KPI verification	verification-testing.md
Connector ingestion lag, Logic App run failures, MCP authorization errors	troubleshooting.md
Books-and-records retention (FINRA 4511 / SEC 17a-4(f)) — NOT Sentinel	Control 1.9 — Data Retention and Deletion Policies
Comprehensive Purview audit-log configuration (upstream of OfficeActivity)	Control 1.7 — Comprehensive Audit Logging and Compliance
Runtime XPIA / jailbreak / external-threat detection at the Defender / Prompt Shields layer	Control 1.8 — Runtime Protection and External Threat Detection
Conditional Access policy authorship for the CA Insights workbook	Control 1.11 — Conditional Access and Phishing-Resistant MFA
Defender AI-SPM posture scoring (the Defender feed Sentinel ingests)	Control 1.24 — Defender AI Security Posture Management
Model risk re-validation triggered by Sentinel monitoring findings	Control 2.6 — Model Risk Management Alignment with OCC 2011-12 / SR 11-7
Supervisory review (FINRA 3110) of Sentinel alert evidence	Control 2.12 — Supervision and Oversight (FINRA Rule 3110)
Agent registry metadata used to enrich Sentinel incidents	Control 2.25 — Agent 365 Admin Center Governance Console
Incident reporting and root-cause analysis after Sentinel triages an incident	Control 3.4 — Incident Reporting and Root Cause Analysis
Cascade of orphan-agent signals into the orphan remediation workflow	Control 3.6 — Orphaned Agent Detection and Remediation
Long-window analytics SDK that complements (not replaces) Sentinel	Control 3.14 — Agent 365 Observability SDK

If the task at hand is not a portal-driven Sentinel deployment, configuration, or operational tuning action, stop and follow the routing above before continuing.

Scope Limit — Operational monitoring, not books-and-records

Microsoft Sentinel supports detection, investigation, alerting evidence, and the audit-trail expectations of NYDFS 23 NYCRR 500.06, the incident-response-plan expectations of NYDFS 500.16, and the 72-hour notification timer of NYDFS 500.17. It also supports the ongoing-monitoring expectations on AI/ML models in OCC Bulletin 2011-12 and Federal Reserve SR 11-7 by feeding monitoring findings into MRM re-validation under Control 2.6.

Sentinel does not substitute for any of the following, and this walkthrough is not a books-and-records retention design:

Obligation	Owning control / surface
Books-and-records retention under FINRA Rule 4511 and SEC Rules 17a-3 / 17a-4 (including 17a-4(f) WORM and audit-trail integrity)	Control 1.9 — Purview retention labels + 17a-4(f) vendor archive
Supervisory review of communications and agent outputs under FINRA Rule 3110	Control 2.12
Model risk management re-validation triggered by monitoring drift	Control 2.6
Incident reporting and RCA workflow after Sentinel raises an incident	Control 3.4
Orphaned-agent identification and remediation cascade	Control 3.6

FINRA Notice 25-07 is cited in this walkthrough as contextual industry consultation only. It is an RFC and does not create binding obligations; sections that reference it are for forward-looking program planning, not compliance attestation.

CISA BOD 22-09 is cited as an informative event-logging benchmark. It is a Binding Operational Directive that applies to federal civilian agencies, not to private-sector financial-services firms; its EL1 / EL2 / EL3 maturity tiers are useful as a maturity yardstick for FSI logging programs but are not regulatory requirements for FSI.

Hedged-Language Reminder

This walkthrough uses hedged compliance language intentionally. Phrases like "supports compliance with", "helps meet", "aids in", "required for", and "recommended to" appear throughout. They are not stylistic — they reflect the legal reality that no Microsoft product feature, no Sentinel deployment, and no individual control can by itself satisfy a regulatory obligation. Implementation requires the firm's legal, compliance, and risk functions to interpret the regulation against the firm's facts. Organizations should verify each compliance assertion in this document with their compliance counsel before relying on it for any examination, attestation, or filing.

If you are tempted to rewrite a sentence to say "ensures compliance with", "guarantees", "will prevent", or "eliminates risk" — stop. Those phrases create legal liability and overstate what software can do. Use the hedged forms.

Sovereign Cloud Availability (GCC / GCC High / DoD)

Capability	Commercial	GCC	GCC High	DoD	Compensating control if unavailable
Sentinel workspace via Defender portal	GA	GA	GA (rollout)	GA (rollout)	Use Azure portal path until Defender portal parity confirmed
Microsoft 365 (OfficeActivity / CopilotInteraction) connector	GA	GA	GA	Limited	§1 manual-export worksheet; ingest via custom collector if necessary
Entra SigninLogs connector	GA	GA	GA	GA	n/a
Entra AADServicePrincipalSignInLogs connector	GA	GA	GA	GA	n/a
Microsoft 365 Defender (XDR) connector	GA	GA	GA	Limited	§1 manual-export worksheet
Defender for Cloud Apps connector	GA	GA	Limited	Not available	§1 manual-export worksheet; reduce shadow-agent detection coverage and document gap
Microsoft Copilot connector (Defender portal)	GA	GA (parity may lag commercial 30–90 days)	Preview / Limited	Not available at time of writing	Document feature unavailability as a product-availability gap; rely on OfficeActivity CopilotInteraction stream for partial coverage
Power Platform Admin Activity connector	GA	GA	GA	Limited	Pull PowerPlatformAdminActivity via Purview Audit export if connector unavailable
Application Insights link (custom Copilot Studio telemetry)	GA	GA	GA	GA	n/a (but verify regional App Insights availability)
Sentinel MCP Server	Preview / GA (commercial)	Limited	Not available at time of writing	Not available	Skip §9 entirely — MCP is optional augmentation; document unavailability as a product-availability gap, not a control gap
Logic Apps for SOAR playbooks	GA	GA	GA	GA (regional)	n/a

Verify rollout status against the Microsoft 365 roadmap, the Microsoft Sentinel sovereign-cloud release notes, and the Microsoft Learn product-availability matrix before each control execution. Sovereign tenants must record any unavailable capability on the §1 compensating-control worksheet as the primary evidence artifact until parity is confirmed. Unavailability of a Microsoft product feature in a sovereign cloud is a product-availability gap, not a Control 3.9 deficiency.

Entra schema gotcha — AADServicePrincipalSignInLogs is a distinct table

The Entra ID connector exposes multiple sign-in tables. The default mental model — "all sign-ins are in SigninLogs" — is wrong for AI agent monitoring, and this is the single most common configuration error in Control 3.9 deployments.

Table	What it contains	What it does NOT contain
SigninLogs	Interactive and non-interactive human user sign-ins	Service principal / managed-identity / workload-identity sign-ins (incl. agent identities created via Entra Agent ID)
AADNonInteractiveUserSignInLogs	Non-interactive human user sign-ins (e.g., refresh tokens)	Service principal / managed-identity sign-ins
AADServicePrincipalSignInLogs	Service-principal sign-ins (incl. AI agents, app registrations, MCP tools acting as confidential clients)	Human user sign-ins
AADManagedIdentitySignInLogs	Sign-ins from system / user-assigned managed identities	Human user sign-ins
AuditLogs	Directory changes (consent grants, role assignments, app registrations)	Sign-in events

If your detection rule queries only SigninLogs, you will not see agent activity. Every analytics rule in §4 that targets agent / workload identity behavior must query AADServicePrincipalSignInLogs (and where applicable AADManagedIdentitySignInLogs). The ingestion of these tables is not enabled by default with the Entra connector — you must explicitly select them at §3.2.

License and Program Requirements

Capability	License / SKU
Microsoft Sentinel workspace (analytics + automation + workbooks)	Per-GB or commitment-tier ingestion + Sentinel surcharge; M365 E5 customers receive a per-user benefit toward eligible M365 data sources
Microsoft Sentinel via the Defender portal (unified XDR experience)	Microsoft 365 Defender (E5 or E5 Security) entitlement plus Sentinel workspace
Defender for Cloud Apps connector	Defender for Cloud Apps standalone or E5 / E5 Security
Microsoft Copilot connector (Defender portal)	M365 Copilot tenant license + Defender for Cloud Apps entitlement
Application Insights (Copilot Studio custom telemetry path)	Azure Monitor Application Insights — pay-as-you-go ingestion
Sentinel MCP Server (optional augmentation)	Sentinel data-lake tier + MCP server license — verify current pricing on the Microsoft Sentinel pricing page before enabling
Logic Apps (SOAR playbooks)	Consumption-tier or Standard-tier Logic Apps
Entra AADServicePrincipalSignInLogs ingestion	Entra ID P1 minimum; P2 recommended for full sign-in risk telemetry

Portal Navigation May Shift

Microsoft updates portal blade names and navigation regularly — particularly during the migration of Sentinel from the Azure portal into the Defender portal. Where this walkthrough cites a path such as Defender portal → Microsoft Sentinel → Configuration → Data connectors, treat the path as descriptive, not authoritative. If the blade has moved, anchor on the page title rather than the breadcrumb. Capture the new path in troubleshooting.md so it can be promoted into the next revision.

The Sentinel Azure portal experience deprecation date is March 31, 2027 at the time of writing. New deployments executed after early 2026 should use the Defender portal (security.microsoft.com) as the default surface. The Azure portal path (portal.azure.com → Microsoft Sentinel) remains supported until the deprecation date for backward compatibility and for blades that have not yet reached Defender-portal parity, but should not be the default for greenfield deployments.

Document Map

§	Section	Primary surface	Verification criterion
0	Pre-flight prerequisites, roles, workspace decisions	Entra PIM + Azure portal	VC-1
1	Sovereign-cloud variant and compensating controls	Manual worksheet	VC-2
2	Workspace deployment via Defender portal	security.microsoft.com → Microsoft Sentinel	VC-3
3	Data connectors (M365, Entra, Defender, Cloud Apps, Copilot, Power Platform, App Insights)	Defender portal → Configuration → Data connectors	VC-4
4	Analytics rules — 7 AI-specific detections	Defender portal → Configuration → Analytics	VC-5
5	Workbooks — Security Posture, CA Insights, Agent Usage	Defender portal → Threat management → Workbooks	VC-6
6	Logic Apps automation playbooks (3 examples)	Defender portal → Configuration → Automation	VC-7
7	Per-table retention with the books-and-records boundary	Log Analytics workspace → Tables	VC-8
8	Incident investigation UX in the Defender portal	Defender portal → Incidents	VC-9
9	Sentinel MCP Server (optional analyst augmentation)	Defender portal → Sentinel MCP	VC-10
10	Evidence capture, zone cadence, examiner packet	All portals + Purview evidence library	VC-11

The numbering of analytics rules in §4 (R1–R7) and Logic Apps playbooks in §6 (P1–P3) is referenced from Control 3.9 and from verification-testing.md. Do not renumber locally — the numbering is the audit handle.

---

§0. Pre-flight — Roles, Licensing, Workspace Decisions

Treat this section as a checklist that must be completed before opening the Defender portal. Skipping it is the most common cause of mid-deployment rework.

0.1 Confirm canonical roles and PIM activation

Use the canonical role names from the role catalog. Map them to the operators executing this walkthrough.

Canonical role	Used for	Where assigned	Activation expectation
Sentinel Admin (Microsoft Sentinel Contributor + Log Analytics Contributor on the workspace resource group)	Workspace creation, connector enablement, analytics-rule authoring, workbook publishing, Logic App linkage	Azure RBAC on the Sentinel resource group	PIM-eligible, max 8h activation, justification + ticket required
SOC Analyst (Microsoft Sentinel Responder)	Incident triage, comments, status updates, playbook on-demand triggers	Azure RBAC on the Sentinel resource group	PIM-eligible, max 8h
Entra Security Admin	Enabling diagnostic settings on Entra ID, including the workload-identity sign-in tables	Entra ID role	PIM-eligible, max 4h
Purview Compliance Admin	Verifying upstream Purview audit-log enablement (feeds OfficeActivity / CopilotInteraction)	Purview role group	PIM-eligible, max 8h
AI Governance Lead	Approves analytics-rule thresholds; signs off on §10 evidence packet	Azure AD group + RACI documented in Control 2.25	Standing assignment; sign-off via change ticket
Power Platform Admin	Enables Power Platform admin-activity logging and Copilot Studio diagnostics export	Power Platform admin role	PIM-eligible, max 8h
Compliance Officer	Reviews retention configuration in §7; co-signs the §10 evidence packet quarterly	Standing role	Standing
CISO	Final approver of §6 automation playbooks that suspend agents (compensating-control authority)	Standing role	Standing
Agent Owner	Receives Logic App playbook P2 notification (Teams adaptive card) and acknowledges within the §10 SLA	Per-agent metadata in agent registry (Control 2.25)	Per-agent assignment

PIM tip

Configure all five Sentinel-related Azure roles as eligible, not active. Permanent active assignments to Sentinel Contributor are an audit finding under NYDFS 500.07 (least-privilege) review.

[Screenshot anchor: ]

0.2 Confirm licensing and ingestion budget

Open the Microsoft 365 admin center → Billing → Licenses view and verify the following before proceeding:

1. M365 E5 (or E5 Security) is assigned to the SOC user population that will operate the Defender portal.
2. Defender for Cloud Apps is licensed.
3. Microsoft 365 Copilot license count matches the population that will be monitored via the Copilot connector.
4. Open Azure portal → Cost Management → Budgets in the Sentinel subscription and confirm an ingestion budget exists with an alert at 80% of the monthly cap. Sentinel ingestion costs scale with OfficeActivity and CloudAppEvents volume in particular; uncapped ingestion is a common audit finding.

[Screenshot anchor: ]

0.3 Workspace decisions — single vs. multi, region, retention default

Document the following decisions in the change-management ticket before §2:

Decision	Recommended default	Rationale
Workspace count	One Sentinel workspace per regulated business unit (broker-dealer, bank, RIA), not one per environment	Aligns with FINRA Rule 3110 supervisory-system delineation; simplifies books-and-records segregation under Control 1.9
Region	Same region as the M365 tenant's primary data residency (e.g., East US 2 for US commercial; USGov Virginia for GCC High)	Avoids cross-region egress fees and simplifies NYDFS 500.11 third-party data-flow diagrams
Default interactive retention	180 days	Operational triage window; aligns with NYDFS 500.06 audit-trail expectations without overspending
Long-term archive in Sentinel	Up to 12 years for select tables	NYDFS 500.06 audit-trail floor + matches FINRA / SEC books-and-records statutory floor — but see §7 books-and-records boundary admonition
Customer-managed keys (CMK)	Enabled for FSI tenants holding NPI under GLBA	Simplifies §501(b) Safeguards Rule attestations
Lock level	CanNotDelete on the workspace resource group	Prevents accidental deletion of audit-trail data; required by SEC 17a-4(f) integrity expectations

Examiner Evidence Box — §0 Pre-flight

Capture the following for the §10 evidence packet:

• PIM role-assignment screenshot (eligible, not active) for Sentinel Admin, SOC Analyst, Entra Security Admin
• Cost budget screenshot showing 80% alert threshold
• Change-management ticket containing the workspace-decisions table above, signed by the AI Governance Lead and the Sentinel Admin
• Confirmation that resource-group lock CanNotDelete is in place (Azure portal → Resource group → Locks)

Cross-Reference

The role-to-control mapping in §0.1 originates in Control 2.25 — Agent 365 Admin Center Governance Console. The Agent Owner field used by Logic App playbook P2 (§6.2) is sourced from the Agent 365 registry; if that registry is not populated for an agent, the playbook degrades to a SOC-only notification — see Control 3.6 — Orphaned Agent Detection and Remediation.

---

§1. Sovereign-Cloud Variant and Compensating-Control Worksheet

This walkthrough was authored against Microsoft 365 commercial cloud. If the deployment target is GCC, GCC High, or DoD, complete this section before §2 and use the worksheet output as the authoritative scope statement for the deployment.

1.1 Determine cloud surface

Open the M365 admin center → Settings → Org settings → Organization profile → Data location. Capture the value (US, GCC, GCCH, DoD). The data-location string drives every subsequent connector availability decision.

[Screenshot anchor: ]

1.2 Compensating-control worksheet

For each capability listed in the Sovereign Cloud Availability table at the top of this document, fill in this worksheet row in the change-management ticket:

Capability	Available in this cloud?	If no, compensating control	Owning role	Re-check date
Microsoft Copilot connector	Yes / No / Limited	If No: ingest CopilotInteraction subset via OfficeActivity; flag detection-coverage gap on the §10 examiner packet	Sentinel Admin	Quarterly
Defender for Cloud Apps connector	Yes / No / Limited	If No: replace shadow-agent detection (R6) with Power Platform admin-activity-only detection; reduce coverage rating from "Full" to "Partial"	Sentinel Admin + AI Governance Lead	Quarterly
Sentinel MCP Server	Yes / No	If No: skip §9 entirely; SOC analysts use the standard Defender portal incident UX	Sentinel Admin	Quarterly
AADServicePrincipalSignInLogs	Yes (all clouds at time of writing)	n/a	Entra Security Admin	Annual

The completed worksheet is the primary evidence artifact that an unavailable Microsoft product feature in a sovereign cloud is documented as a product-availability gap, not a Control 3.9 deficiency. Examiners will accept a documented product-availability gap with a quarterly re-check cadence; they will not accept silent omission.

Examiner Evidence Box — §1 Sovereign Cloud

• Data-location screenshot
• Completed compensating-control worksheet stored in the Purview evidence library tagged Control-3.9 / Sovereign-Variant
• Quarterly re-check ticket history (last four quarters minimum)

---

§2. Workspace Deployment via the Defender Portal

This section deploys the Sentinel workspace and onboards it into the Defender portal unified experience.

Surface choice

The Defender portal (security.microsoft.com) is the default surface for new Sentinel deployments at the time of writing. The Azure portal experience for Microsoft Sentinel is scheduled for deprecation on March 31, 2027. Existing deployments executing before early 2026 may continue to use the Azure portal path; new deployments should adopt the Defender portal as the primary surface to avoid a re-platforming task in 2026–2027.

2.1 Create the Log Analytics workspace

1. Open the Azure portal → Log Analytics workspaces → + Create.
2. Subscription: the Sentinel subscription identified in §0.3.
3. Resource group: a dedicated RG (e.g., rg-sentinel-prod-eus2). Apply the CanNotDelete lock from §0.3 after creation.
4. Workspace name: follow the firm's naming convention (e.g., law-sentinel-bd-prod-eus2 for the broker-dealer business unit).
5. Region: the value selected in §0.3.
6. Tags: at minimum BusinessUnit, DataClassification=Confidential-NPI, Control=3.9, Owner=<Sentinel-Admin-DL>, CostCenter.
7. Click Review + create, then Create.

[Screenshot anchor: ]

2.2 Enable Microsoft Sentinel on the workspace

1. In the Azure portal, search for Microsoft Sentinel and open the service.
2. Click + Create → select the workspace from §2.1 → Add.
3. Wait for the Sentinel onboarding to complete (typically 1–3 minutes).

[Screenshot anchor: ]

2.3 Onboard Sentinel into the Defender portal

1. Navigate to security.microsoft.com in a private browser session as the Sentinel Admin.
2. In the left navigation, expand Microsoft Sentinel. If Sentinel is not yet visible, the Defender portal will offer an onboarding card — click Connect a workspace.
3. Select the workspace from §2.1 and click Next → Connect.
4. Wait for the unified-portal onboarding banner to switch from "Onboarding" to "Connected".

[Screenshot anchor: ]

Multi-workspace tenants

The Defender portal supports a primary workspace plus secondary workspace views. Set the regulated business-unit workspace selected in §0.3 as the primary. Cross-workspace KQL is supported via the workspace() operator but adds latency and cost; design analytics rules to live in the workspace whose data they query.

2.4 Apply the resource-group delete lock and tag governance

1. Azure portal → resource group from §2.1 → Locks → + Add → Lock type: Delete → Lock name: lock-sentinel-prod-no-delete → Notes: "Control 3.9 / SEC 17a-4(f) audit-trail integrity / NYDFS 500.06" → OK.
2. Confirm tags from §2.1 propagated to the workspace, the Sentinel solution, and any auto-created Logic Apps resource group.

Examiner Evidence Box — §2 Workspace Deployment

• Workspace properties blade (showing region, retention default, CMK if applicable)
• Resource-group lock blade showing CanNotDelete
• Defender portal banner showing the workspace as Connected
• Tag inheritance screenshot

Cross-Reference

The CMK decision in §0.3 / §2.1 is owned by the broader key-management program, not by Control 3.9. If the tenant is using customer-managed keys for log data, document the Key Vault and key reference here and cross-link to the firm's key-management runbook. If the firm has not yet deployed CMK, that is a separate program decision and not a Control 3.9 blocker.

---

§3. Data Connectors — The Ingestion Backbone

This section enables the seven data connectors that feed every analytics rule, workbook, and Logic App in this walkthrough. Each subsection follows the same pattern: portal navigation, connector enablement, table verification, and ingestion sanity check.

Order matters

Enable connectors in the order presented (3.1 → 3.7). The Entra connector (3.2) must precede the analytics rules in §4 because the agent-identity tables it produces are queried by every workload-identity rule. The Microsoft 365 connector (3.1) must precede the Copilot connector (3.5) because CopilotInteraction enrichment depends on OfficeActivity user-context resolution.

3.1 Microsoft 365 connector (OfficeActivity, including CopilotInteraction)

The M365 connector ingests the unified Purview audit log into the OfficeActivity table, which includes the CopilotInteraction record type for Microsoft 365 Copilot interactions across Word, Excel, PowerPoint, Outlook, Teams, and the BizChat surface.

1. Defender portal → Microsoft Sentinel → Configuration → Data connectors.
2. Search for Microsoft 365 (formerly Office 365). Select the connector and click Open connector page.
3. In the Configuration section, enable telemetry for Exchange, SharePoint, Teams, and General (the General record type carries CopilotInteraction).
4. Click Apply Changes.

5. Wait 15–30 minutes, then run the following KQL in Logs:

   OfficeActivity
   | where TimeGenerated > ago(1h)
   | summarize Count = count() by RecordType
   | order by Count desc
   

   Expected: a non-zero count for CopilotInteraction if the tenant has active Copilot users. If the count is zero after 24 hours, route to troubleshooting.md.

[Screenshot anchor: ]

Upstream dependency

The M365 connector reads from the Purview unified audit log. If audit logging is not enabled at the Purview level, the connector will succeed at the portal layer but produce no data. Verify upstream audit-logging configuration in Control 1.7 — Comprehensive Audit Logging and Compliance before treating an empty OfficeActivity table as a Sentinel issue.

3.2 Microsoft Entra ID connector (human + workload identities)

This is the most error-prone connector in the entire walkthrough. Read the schema gotcha admonition at the top of this document before proceeding.

1. Defender portal → Microsoft Sentinel → Configuration → Data connectors → search Microsoft Entra ID → Open connector page.
2. In the Configuration pane, you will see a list of log types. Select all of the following — do not accept the default of SigninLogs only:
   • SigninLogs (interactive human sign-ins)
   • AuditLogs (directory changes — feeds R5 unusual consent grants)
   • NonInteractiveUserSignInLogs
   • ServicePrincipalSignInLogs ← CRITICAL FOR AGENT MONITORING (writes to AADServicePrincipalSignInLogs)
   • ManagedIdentitySignInLogs (writes to AADManagedIdentitySignInLogs)
   • ProvisioningLogs
   • ADFSSignInLogs (only if hybrid AD FS is in scope)
   • RiskyUsers, UserRiskEvents, RiskyServicePrincipals, ServicePrincipalRiskEvents (Entra ID P2)
3. Click Apply Changes.

4. Wait 15–30 minutes, then verify each table:

   union withsource = T *
   | where T in ("SigninLogs", "AADServicePrincipalSignInLogs", "AADManagedIdentitySignInLogs", "AuditLogs")
   | where TimeGenerated > ago(1h)
   | summarize Count = count() by T
   

   Expected: non-zero rows for each table. AADServicePrincipalSignInLogs should be non-zero in any tenant with active service principals; if zero, the most likely cause is that the checkbox in step 2 was not selected — return to step 2 and verify.

[Screenshot anchor: ]

Diagnostic settings vs. data connector

The Defender-portal Entra connector is implemented under the hood as a diagnostic setting on the Entra tenant pointing at the Sentinel workspace. Some FSI tenants pre-create this diagnostic setting via Azure Policy. If the Entra connector page shows "This connector is already configured" but the table list is incomplete, open Entra portal → Diagnostic settings and edit the existing setting to add the missing log types. The Defender portal will reflect the change within a few minutes.

3.3 Microsoft Defender XDR connector

The Microsoft Defender XDR (M365D) connector ingests Defender alerts and raw device telemetry into Sentinel. For Control 3.9, the alert stream is the primary use; the device telemetry is optional and increases ingestion cost.

1. Defender portal → Microsoft Sentinel → Configuration → Data connectors → search Microsoft Defender XDR → Open connector page.
2. Enable Connect incidents and alerts. This streams the unified Defender incident queue into Sentinel.
3. Under Connect events, enable at minimum:
   • AlertInfo, AlertEvidence (alert metadata, required)
   • DeviceEvents (optional; high volume — gate on cost-budget headroom from §0.2)
   • EmailEvents, EmailUrlInfo, EmailAttachmentInfo (recommended for Copilot phishing-related detections)
   • CloudAppEvents (covered in §3.4 — disable here if §3.4 is enabled)
4. Disable bi-directional sync of incidents until §8 has been validated; bi-directional sync without a tested investigation runbook can cause incident-status thrash.
5. Click Apply Changes.

6. Verify:

   AlertInfo
   | where TimeGenerated > ago(24h)
   | summarize Count = count() by ServiceSource
   

   Expected: non-zero rows for Defender for Endpoint, Defender for Office 365, and (if licensed) Defender for Cloud Apps.

[Screenshot anchor: ]

Cross-Reference

The Defender AI-SPM posture findings ingested via this connector originate in Control 1.24 — Defender AI Security Posture Management. If AI-SPM is not yet enabled in the Defender portal, the connector will succeed but the AI-posture rows in the §5 workbook will be empty.

3.4 Defender for Cloud Apps connector

The Defender for Cloud Apps (MDA) connector writes to CloudAppEvents and is the primary feed for shadow-agent detection (R6) and SaaS-app risk for AI tools.

1. Defender portal → Microsoft Sentinel → Configuration → Data connectors → search Microsoft Defender for Cloud Apps → Open connector page.
2. Enable CloudAppEvents stream.
3. Click Apply Changes.

4. Verify:

   CloudAppEvents
   | where TimeGenerated > ago(1h)
   | summarize Count = count() by Application
   | order by Count desc
   | take 25
   

   Expected: a populated list of cloud apps. If Microsoft Copilot or known third-party AI applications (e.g., ChatGPT, Claude, Gemini) appear, the shadow-AI detection (R6) will function.

[Screenshot anchor: ]

Sovereign clouds

Defender for Cloud Apps connector is not available in DoD and is limited in GCC High at the time of writing. If unavailable, document the gap on the §1 worksheet and switch R6 (shadow-agent detection) to the Power Platform admin-activity-only variant.

3.5 Microsoft Copilot connector (Defender portal)

The Microsoft Copilot connector (GA in commercial cloud at the time of writing) provides richer Copilot signals than what is available via OfficeActivity alone — including XPIA flags, prompt-shield outcomes, and sensitivity-label propagation.

1. Defender portal → Microsoft Sentinel → Configuration → Data connectors → search Microsoft Copilot → Open connector page.
2. Click Connect. Authorize the connector with the Sentinel Admin credentials.
3. Click Apply Changes.

4. Verify (table name and schema may evolve — check the connector page for current table reference):

   OfficeActivity
   | where RecordType == "CopilotInteraction"
   | where TimeGenerated > ago(1h)
   | extend XPIAFlag = tostring(parse_json(CopilotEventData).XPIAFlag)
   | summarize Total = count(), XPIAFlagged = countif(isnotempty(XPIAFlag)) by bin(TimeGenerated, 15m)
   

   Expected: non-zero Total for an active tenant; XPIAFlagged may be zero in normal operation and is expected to be rare.

[Screenshot anchor: ]

Connector evolution

The Microsoft Copilot connector schema is evolving as Microsoft adds prompt-injection telemetry, plugin/connector telemetry, and agent-identity attribution. Re-verify the schema each quarter against Microsoft Learn before committing analytics-rule KQL to production.

3.6 Power Platform admin activity connector

The Power Platform connector writes to PowerPlatformAdminActivity and is the primary feed for DLP-policy-change detection (R4) and Copilot Studio agent lifecycle events.

1. Defender portal → Microsoft Sentinel → Configuration → Data connectors → search Power Platform → Open connector page.
2. Authorize with the Power Platform Admin account.
3. Enable the following streams:
   • PowerPlatformAdminActivity (admin-center actions, DLP policy changes, environment changes)
   • PowerPlatformDlpActivity (DLP policy violations / blocks)
   • CopilotStudioActivity (where available — Copilot Studio agent publish, share, deletion events)
4. Click Apply Changes.

5. Verify:

   PowerPlatformAdminActivity
   | where TimeGenerated > ago(24h)
   | summarize Count = count() by EventOriginalType
   | order by Count desc
   

   Expected: rows including CreateDlpPolicy, UpdateDlpPolicy, DeleteDlpPolicy, CreateEnvironment, etc.

[Screenshot anchor: ]

Cross-Reference

The DLP-policy-change detection (R4) depends on this connector. The DLP policies themselves are authored under the Power Platform DLP control surface; if Sentinel detects a DLP-policy change, the change-management ticket associated with that DLP edit should be retrievable from the Power Platform admin center audit log as well.

3.7 Application Insights — Copilot Studio custom telemetry (optional)

Copilot Studio supports an Application Insights export for richer per-conversation telemetry than what flows into OfficeActivity. This is optional and best-suited to high-value enterprise agents in Zone 3.

1. Open Copilot Studio (copilotstudio.microsoft.com) as the agent maker.
2. Open the agent → Settings → Advanced → Application Insights.
3. Paste the Application Insights connection string for the App Insights resource that the firm has provisioned for agent telemetry. (Provisioning the App Insights resource itself is outside the scope of this walkthrough.)
4. Toggle Log activities = On.
5. Toggle Log sensitive activity properties = On for Zone 2 / Zone 3 agents only after a privacy review by the Compliance Officer; in Zone 1 leave this Off.
6. Click Save.
7. In the Power Platform admin center (admin.powerplatform.microsoft.com), open the environment containing the agent → Settings → Product → Features → set Allow conversation transcripts = On if the firm has approved transcript capture under Control 1.9.
8. In the Defender portal → Microsoft Sentinel → Configuration → Data connectors → search Azure Monitor / Application Insights → connect the App Insights resource to the Sentinel workspace via the diagnostic-settings path.

[Screenshot anchor: ]

Records-retention boundary

Application Insights is an operational telemetry store. It is not an SEC 17a-4(f) compliant records archive. Conversation transcripts captured through this path must be evaluated against the firm's books-and-records policy under Control 1.9. If the transcripts qualify as books-and-records (e.g., communications with customers about securities), the firm must route a copy to the 17a-4(f) WORM vendor archive — App Insights alone does not meet the records-integrity requirement of SEC Rule 17a-4(f). Organizations should verify this routing with their compliance counsel before enabling Allow conversation transcripts on customer-facing agents.

Examiner Evidence Box — §3 Data Connectors

For each of the seven connectors above, capture:

• The Open connector page view showing Connected / Last data received timestamps
• The verification KQL output showing non-zero rows in each expected table
• For the Entra connector specifically, a screenshot of the diagnostic-settings page showing all sign-in log types selected (this is the single most-asked screenshot in NYDFS audit-trail reviews)
• For the Application Insights connector, the privacy-review sign-off ticket from §3.7

Cross-Reference

Connector ingestion lag, "0 rows" verification failures, and authorization errors are routed to troubleshooting.md. Bicep / Terraform automation of the connector enablement is in powershell-setup.md — note that several connectors (Microsoft Copilot, Power Platform) currently have no ARM/Bicep API and must be enabled via the portal even in IaC-first shops.

---

§4. Analytics Rules — Seven AI-Specific Detections

This section creates the seven analytics rules that constitute the operational detection floor for Control 3.9. Each rule follows the same authoring pattern in the Defender portal.

Rule numbering is the audit handle

Rule numbers R1–R7 are referenced from Control 3.9, from verification-testing.md (which contains the dry-run / unit-test cases for each rule), and from the §10 evidence packet. Do not renumber locally.

4.0 Common authoring pattern

For each rule below, use this navigation:

1. Defender portal → Microsoft Sentinel → Configuration → Analytics → + Create → Scheduled query rule.
2. General tab: paste the rule name, description, and tactics from the rule subsection. Severity per the table.
3. Set rule logic tab: paste the KQL into the Rule query box. Configure the Query scheduling and Alert threshold per the rule.
4. Entity mapping: map at minimum Account (UPN), IP (IPAddress), and where present CloudApplication and a custom Agent entity.
5. Incident settings: enable incident creation and alert grouping as specified per rule (e.g., group by Account over 1h).
6. Automated response tab: where indicated, attach the Logic App playbook from §6.
7. Review and create.

[Screenshot anchor: ]

4.1 R1 — Prompt-injection / jailbreak indicator (XPIA)

Field	Value
Severity	High
MITRE tactic	Initial Access, Defense Evasion
Frequency	Every 5 minutes
Lookback	30 minutes
Threshold	≥ 1 event
Auto-response	Logic App P1 Suspend Agent (gated — only triggers on confirmed Defender alert; see §6.1)

let lookback = 30m;
OfficeActivity
| where TimeGenerated > ago(lookback)
| where RecordType == "CopilotInteraction"
| extend EventData = parse_json(CopilotEventData)
| extend XPIAFlag = tostring(EventData.XPIAFlag)
| extend PromptShieldOutcome = tostring(EventData.PromptShieldOutcome)
| where isnotempty(XPIAFlag) or PromptShieldOutcome in ("Blocked", "Flagged")
| extend AgentId = tostring(EventData.AgentId), 
         ConversationId = tostring(EventData.ConversationId),
         Account = UserId
| project TimeGenerated, Account, AgentId, ConversationId, XPIAFlag, PromptShieldOutcome, ClientIP

Detection caveat

This rule detects an XPIA / prompt-shield signal raised by the Microsoft Copilot runtime. It does not detect prompt injection at agents that bypass the Copilot prompt-shield layer (e.g., custom Copilot Studio agents that use external LLMs without shield integration). Runtime-layer protection across all agent surfaces is owned by Control 1.8 — Runtime Protection and External Threat Detection. Sentinel R1 is the monitoring layer; it aids in detection but does not by itself prevent prompt injection.

4.2 R2 — Anomalous connector / MCP tool use by an agent

Detects an agent invoking a connector or MCP tool that is outside its normal baseline (sudden new connector, sharp volume spike, or use of a connector flagged as high-risk in Power Platform DLP).

Field	Value
Severity	Medium
MITRE tactic	Discovery, Collection
Frequency	Every 30 minutes
Lookback	24 hours, baseline 14 days
Threshold	≥ 3 anomalous invocations within lookback
Auto-response	Logic App P2 Notify Owner + SOC

let baselineWindow = 14d;
let lookback = 24h;
let baseline = PowerPlatformAdminActivity
    | where TimeGenerated between (ago(baselineWindow) .. ago(lookback))
    | where EventOriginalType in ("InvokeConnector", "InvokeMcpTool")
    | summarize BaselineCount = count() by AgentId = tostring(parse_json(EventData).AgentId), 
                                            ConnectorName = tostring(parse_json(EventData).ConnectorName);
PowerPlatformAdminActivity
| where TimeGenerated > ago(lookback)
| where EventOriginalType in ("InvokeConnector", "InvokeMcpTool")
| extend AgentId = tostring(parse_json(EventData).AgentId),
         ConnectorName = tostring(parse_json(EventData).ConnectorName),
         Account = UserId
| summarize RecentCount = count() by AgentId, ConnectorName, Account
| join kind=leftouter (baseline) on AgentId, ConnectorName
| where isnull(BaselineCount) or RecentCount > BaselineCount * 5
| where RecentCount >= 3
| project AgentId, ConnectorName, Account, RecentCount, BaselineCount

[Screenshot anchor: ]

4.3 R3 — After-hours privileged agent activity

Detects a service-principal sign-in by an agent flagged as privileged (membership in an Entra group such as sg-agents-privileged) outside of business hours.

Field	Value
Severity	Medium
MITRE tactic	Persistence, Privilege Escalation
Frequency	Every 15 minutes
Lookback	1 hour
Threshold	≥ 1 event
Auto-response	Logic App P2 Notify Owner + SOC

let businessStart = 7;
let businessEnd = 19;
let timezoneOffset = -5h; // adjust to firm primary timezone
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(1h)
| extend LocalHour = datetime_part("hour", TimeGenerated + timezoneOffset)
| where LocalHour < businessStart or LocalHour >= businessEnd
| where ServicePrincipalName has_any (dynamic(["agent-", "copilot-", "mcp-"]))
   or ServicePrincipalId in (
       // populate from Entra group membership of sg-agents-privileged via watchlist
       _GetWatchlist("PrivilegedAgents") | project ServicePrincipalId
   )
| project TimeGenerated, ServicePrincipalName, ServicePrincipalId, IPAddress, ResourceDisplayName, ConditionalAccessStatus

Watchlist pattern

Maintain the privileged-agent list as a Sentinel Watchlist (Defender portal → Microsoft Sentinel → Configuration → Watchlists). The watchlist is sourced from the Agent 365 registry (Control 2.25) on a daily refresh. Embedding the list inline in the rule KQL is an anti-pattern that breaks change management.

4.4 R4 — DLP-policy change or bypass on Power Platform

Detects creation, modification, or deletion of a Power Platform DLP policy, and detects DLP-policy bypass attempts.

Field	Value
Severity	High (delete / bypass) / Medium (create / update)
MITRE tactic	Defense Evasion, Impact
Frequency	Every 15 minutes
Lookback	1 hour
Threshold	≥ 1 event
Auto-response	Logic App P3 ITSM + NYDFS 500.17 timer (delete / bypass only)

union 
(
    PowerPlatformAdminActivity
    | where TimeGenerated > ago(1h)
    | where EventOriginalType in ("DeleteDlpPolicy", "UpdateDlpPolicy", "CreateDlpPolicy")
    | extend PolicyName = tostring(parse_json(EventData).PolicyName),
             ChangeType = EventOriginalType,
             Account = UserId
    | project TimeGenerated, ChangeType, PolicyName, Account, ClientIP
),
(
    PowerPlatformDlpActivity
    | where TimeGenerated > ago(1h)
    | where ActionType == "PolicyBypassAttempt"
    | extend PolicyName = tostring(parse_json(AdditionalFields).PolicyName),
             ChangeType = "BypassAttempt",
             Account = UserId
    | project TimeGenerated, ChangeType, PolicyName, Account, ClientIP
)

Sensitive change

DLP policy deletes are a Tier-0 administrative action for any Power Platform tenant in scope of GLBA Safeguards Rule §314.4(c)(8) (audit trails for security events). The change-management process must require dual approval for DLP-policy deletes; if Sentinel detects a deletion without a corresponding approved change ticket, treat it as a potential insider threat and escalate per the firm's incident-response plan (Control 3.4).

4.5 R5 — Unusual consent grants or service-principal role assignments

Detects OAuth consent grants to high-privilege Microsoft Graph scopes by a service principal, and detects directory-role assignments to service principals.

Field	Value
Severity	High
MITRE tactic	Persistence, Privilege Escalation
Frequency	Every 15 minutes
Lookback	1 hour
Threshold	≥ 1 event
Auto-response	Logic App P2 Notify Owner + SOC

let highRiskScopes = dynamic([
    "Mail.ReadWrite.All", "Mail.Send", "Files.ReadWrite.All", 
    "Directory.ReadWrite.All", "Application.ReadWrite.All",
    "RoleManagement.ReadWrite.Directory", "Sites.FullControl.All"
]);
union
(
    AuditLogs
    | where TimeGenerated > ago(1h)
    | where OperationName == "Consent to application"
    | extend ConsentScope = tostring(parse_json(tostring(TargetResources[0].modifiedProperties[4].newValue)))
    | where ConsentScope has_any (highRiskScopes)
    | extend Account = tostring(InitiatedBy.user.userPrincipalName),
             AppName = tostring(TargetResources[0].displayName)
    | project TimeGenerated, Operation = OperationName, AppName, ConsentScope, Account
),
(
    AuditLogs
    | where TimeGenerated > ago(1h)
    | where OperationName in ("Add member to role", "Add eligible member to role")
    | where TargetResources[0].type == "ServicePrincipal"
    | extend Account = tostring(InitiatedBy.user.userPrincipalName),
             RoleName = tostring(parse_json(tostring(TargetResources[0].modifiedProperties[1].newValue))),
             ServicePrincipalName = tostring(TargetResources[0].displayName)
    | project TimeGenerated, Operation = OperationName, ServicePrincipalName, RoleName, Account
)

4.6 R6 — Orphan / shadow agent indicator

Detects two distinct cases:

• Orphan: An agent (service principal) with sign-in activity but whose registered owner is disabled, deleted, or no longer in the Agent 365 registry.
• Shadow: A connection to a non-sanctioned third-party AI service (ChatGPT, Claude, Gemini, etc.) by a user account with significant data-access privileges.

Field	Value
Severity	Medium
MITRE tactic	Discovery, Collection
Frequency	Every 1 hour
Lookback	24 hours
Threshold	≥ 1 event
Auto-response	None — cascades to Control 3.6 remediation workflow

// Orphan branch
let orphanAgents = AADServicePrincipalSignInLogs
    | where TimeGenerated > ago(24h)
    | distinct ServicePrincipalId, ServicePrincipalName
    | join kind=leftouter (
        _GetWatchlist("AgentRegistry") | project ServicePrincipalId, OwnerUPN, OwnerStatus
    ) on ServicePrincipalId
    | where isnull(OwnerUPN) or OwnerStatus == "Disabled" or OwnerStatus == "Deleted"
    | extend FindingType = "OrphanAgent";
// Shadow branch
let shadowAI = CloudAppEvents
    | where TimeGenerated > ago(24h)
    | where Application has_any (dynamic(["ChatGPT", "Claude", "Gemini", "Perplexity", "Anthropic", "OpenAI"]))
    | summarize Events = count(), DistinctUsers = dcount(AccountObjectId) by Application
    | extend FindingType = "ShadowAI";
union orphanAgents, shadowAI

Cross-Reference

The orphan branch of R6 is the upstream signal for Control 3.6 — Orphaned Agent Detection and Remediation. The R6 detection alone does not remediate; remediation is a 3.6 workflow. Sentinel's role here is to surface the signal and route it.

4.7 R7 — Mass data download by an agent identity

Detects volumetric data egress by a service principal (e.g., agent reads thousands of SharePoint items in a short window — a hallmark of a compromised or misconfigured agent).

Field	Value
Severity	High
MITRE tactic	Collection, Exfiltration
Frequency	Every 15 minutes
Lookback	1 hour, baseline 14 days
Threshold	Configurable per agent class — see thresholds table below
Auto-response	Logic App P1 Suspend Agent (gated; high severity only)

let lookback = 1h;
let baselineWindow = 14d;
let baseline = OfficeActivity
    | where TimeGenerated between (ago(baselineWindow) .. ago(lookback))
    | where Operation in ("FileDownloaded", "FileAccessed", "FileSyncDownloadedFull")
    | where UserType == "ServicePrincipal" or UserId has "@" == false
    | summarize BaselineHourly = avg(todouble(1)) * 60 by UserId;
OfficeActivity
| where TimeGenerated > ago(lookback)
| where Operation in ("FileDownloaded", "FileAccessed", "FileSyncDownloadedFull")
| where UserType == "ServicePrincipal" or UserId has "@" == false
| summarize RecentCount = count(), DistinctSites = dcount(Site_Url) by UserId
| join kind=leftouter (baseline) on UserId
| where RecentCount > coalesce(BaselineHourly, 50.0) * 10
| where RecentCount >= 500
| project UserId, RecentCount, DistinctSites, BaselineHourly

Agent class	Recommended absolute threshold	Recommended baseline-multiplier
Zone 1 personal Copilot	100 file events / hour	5×
Zone 2 team agent	500 file events / hour	10×
Zone 3 enterprise agent	2,500 file events / hour	10×

Adjust thresholds per business unit; the table is a starting point, not a mandate.

[Screenshot anchor: ]

Examiner Evidence Box — §4 Analytics Rules

For each rule R1–R7 capture:

• The Analytics rule detail page (rule name, description, severity, tactics, schedule, auto-response binding)
• A screenshot of the Set rule logic tab showing the KQL committed in this walkthrough (or the firm's tuned variant) with the change-management ticket referenced in the rule description
• A 30-day rolling alert summary screenshot from the Defender portal Incidents view filtered to each rule

Cross-Reference

Rule unit tests (synthetic event injection, dry-run KQL, false-positive baseline) are in verification-testing.md. Rule-tuning thresholds and false-positive triage are owned by the SOC under FFIEC IT Examination Handbook (Information Security) operations expectations; tuning history is part of the §10 evidence packet.

---

§5. Workbooks — Visualization and Examiner Reporting

This section deploys three workbooks that consolidate the §3 ingestion and §4 detections into views suitable for SOC operations, AI governance reviews, and examiner walkthroughs.

5.1 AI Agent Security Posture workbook

This is the primary examiner-facing workbook. It consolidates Defender AI-SPM posture findings, R1–R7 alert volume trends, top affected agents, and the orphan-agent backlog from R6.

1. Defender portal → Microsoft Sentinel → Threat management → Workbooks.
2. Click Templates → search AI Agent or Copilot. If a Microsoft-published template (e.g., Microsoft Copilot for Microsoft 365 Activity or Defender AI Posture) exists, click Save to add it to the workspace, then click View saved workbook → Edit.
3. If no template fits, click + Workbook → Edit → start with an empty workbook and add the panels described below.

4. Add the following panels (each as a Query part):

   Panel	KQL summary
   Alerts by rule (R1–R7), 30 days	SecurityAlert \| where TimeGenerated > ago(30d) \| where AlertName startswith "Agent " \| summarize Count = count() by AlertName, bin(TimeGenerated, 1d) \| render timechart
   Top 10 agents by alert volume	SecurityAlert \| where TimeGenerated > ago(30d) \| extend AgentId = tostring(parse_json(Entities)[0].AgentId) \| where isnotempty(AgentId) \| summarize Alerts = count() by AgentId \| top 10 by Alerts
   Orphan agent backlog (R6)	SecurityAlert \| where AlertName == "R6 Orphan or Shadow Agent" \| where Status != "Closed"
   Defender AI-SPM posture summary	AlertInfo \| where ServiceSource == "Microsoft Defender for Cloud" \| where Category has "AI" \| summarize Count = count() by Severity
   XPIA / Prompt-shield trend (R1)	Query from R1 KQL with bin(TimeGenerated, 1h) and render columnchart
   DLP-policy change ledger (R4)	Query from R4 KQL with project TimeGenerated, ChangeType, PolicyName, Account rendered as a table

5. Save the workbook with name AI-Agent-Security-Posture and pin to the SOC dashboard.

[Screenshot anchor: ]

5.2 Conditional Access Insights workbook

A Microsoft-published workbook that visualizes Conditional Access policy effectiveness — including for service-principal sign-ins, which is the primary value for Control 3.9.

1. Defender portal → Microsoft Sentinel → Workbooks → Templates → search Conditional Access Insights.
2. Click Save → View saved workbook.
3. In the workbook parameters bar, set Scope = Service Principals to filter the view to workload identities.
4. Save and pin.

Cross-Reference

Conditional Access policy authorship is owned by Control 1.11 — Conditional Access and Phishing-Resistant MFA. The workbook visualizes policy effectiveness; it does not author or modify policy. If the workbook shows agent sign-ins not subject to a Conditional Access policy, the remediation is in 1.11, not in Sentinel.

5.3 Agent Usage and Performance workbook

Consumes the Application Insights stream from §3.7 (where enabled). Provides per-agent latency, error rate, conversation volume, and top intents — useful for operational observability and for input to MRM re-validation under Control 2.6.

1. Defender portal → Microsoft Sentinel → Workbooks → + Workbook.

2. Add Query parts targeting the Application Insights tables (AppRequests, AppDependencies, AppExceptions, customEvents):

   Panel	KQL summary
   Conversations per agent per day	customEvents \| where name == "ConversationStart" \| summarize Count = count() by tostring(customDimensions.AgentId), bin(timestamp, 1d)
   P95 response latency	AppRequests \| summarize percentile(duration, 95) by tostring(customDimensions.AgentId), bin(timestamp, 1h)
   Top failed intents	customEvents \| where name == "IntentResolution" and tobool(customDimensions.Failed) \| summarize Count = count() by tostring(customDimensions.IntentName) \| top 20 by Count
   Knowledge-source usage	customEvents \| where name == "KnowledgeSourceQuery" \| summarize Count = count() by tostring(customDimensions.SourceName)

3. Save as AI-Agent-Usage-Performance.

Performance metrics ≠ model risk evidence

Performance metrics from this workbook are operational telemetry. They aid in detecting model drift and quality degradation, but they do not constitute model-risk-management evidence under OCC 2011-12 / SR 11-7. MRM evidence requires the structured re-validation workflow in Control 2.6. Workbook outputs are inputs to that workflow, not substitutes for it.

Examiner Evidence Box — §5 Workbooks

• PNG export of each of the three workbooks at the most recent quarter-end (Defender portal → Workbook → ⋯ → Print to PDF or use the workbook export endpoint)
• The pinned-dashboard view in the SOC operations room
• The list of workbook owners and review cadence (quarterly minimum)

---

§6. Logic Apps Automation Playbooks

This section deploys three SOAR playbooks. All three are authored as Logic Apps (Consumption) in the Sentinel resource group and bound to the analytics rules from §4.

Automation policy gate

Any playbook that takes suspending action on an agent (P1) requires CISO sign-off as a documented compensating-control authority. Notify-only playbooks (P2) and ITSM-routing playbooks (P3) do not require CISO sign-off but do require AI Governance Lead sign-off. The sign-off ticket reference must appear in the Logic App tag ApprovalTicket=<id>.

6.1 P1 — Suspend Agent on High-Severity Alert

Trigger: Sentinel incident created with severity High and alert rule in (R1, R7).

Action sequence:

1. Trigger: Microsoft Sentinel incident (alert rule = R1 or R7, severity = High).
2. Get incident entities → extract AgentId from the alert entity mapping.
3. HTTP action → call Microsoft Graph: POST https://graph.microsoft.com/v1.0/servicePrincipals/{AgentId} with body { "accountEnabled": false }. Authentication: managed identity of the Logic App, granted Application.ReadWrite.All (consent gated under the firm's high-privilege-app review process).
4. Post adaptive card to Teams → channel #soc-agent-suspensions with the incident ID, agent ID, agent owner UPN (from the Agent 365 watchlist), and a "Confirm suspension" button that, when clicked, posts a comment back to the Sentinel incident.
5. Add comment to Sentinel incident → "Agent {AgentId} suspended automatically by playbook P1 at {utcNow()}. Owner notified. Awaiting SOC confirmation."
6. Tag incident → auto-suspension-applied.

Portal authoring

1. Defender portal → Microsoft Sentinel → Configuration → Automation → + Create → Playbook with incident trigger.
2. Subscription / RG: the Sentinel RG. Name: pb-3.9-P1-suspend-agent. Authentication: System-assigned managed identity.
3. Click Create playbook, then in the Logic App designer add the steps above.
4. Return to Sentinel → Automation → + Create automation rule → bind P1 to incidents matching Analytics rule name in (R1 Prompt Injection Indicator, R7 Mass Download by Agent) AND Severity = High.

[Screenshot anchor: ]

Suspension is a reversible operational action, not a discipline action

Disabling an agent service principal stops it from authenticating but does not delete it, does not revoke its assigned permissions, and does not constitute a finding under any supervisory framework. The SOC must follow up by:

1. Contacting the Agent Owner (P2 fires automatically in parallel).
2. Triaging the underlying alert per Control 3.4.
3. Re-enabling or formally retiring the agent within the SLA on the §10 cadence table.

6.2 P2 — Notify Agent Owner and SOC

Trigger: Sentinel incident created (any severity) for any rule in §4.

Action sequence:

1. Trigger: Microsoft Sentinel incident.
2. Get incident entities → extract AgentId.
3. Lookup Agent Owner → query the Agent 365 watchlist for OwnerUPN. If not found, fall back to the SOC distribution list and tag the incident agent-owner-unknown (cascades to Control 3.6).
4. Post adaptive card in Teams → DM the Agent Owner with the incident ID, severity, alert summary, agent ID, and an "Acknowledge" button.
5. Send email (Office 365 Outlook connector) → CC the SOC distribution list.
6. Add comment to Sentinel incident → "Owner {OwnerUPN} notified at {utcNow()}; acknowledgement SLA per §10 cadence."

Portal authoring

1. Defender portal → Microsoft Sentinel → Configuration → Automation → + Create → Playbook with incident trigger. Name: pb-3.9-P2-notify-owner.
2. In the designer, the Lookup step is a Run query and list results (Sentinel) action that queries the watchlist KQL: _GetWatchlist("AgentRegistry") | where ServicePrincipalId == "{AgentId}" | project OwnerUPN.
3. Bind via automation rule to all §4 rules.

[Screenshot anchor: ]

6.3 P3 — ITSM Routing and NYDFS 500.17 Notification Timer

Trigger: Sentinel incident created with severity High for rules R1, R4 (delete / bypass branch), R5, or R7.

Action sequence:

1. Trigger: Microsoft Sentinel incident.
2. Create ITSM ticket → ServiceNow / Jira / generic ITSM connector. Set the ticket priority to map to the Sentinel severity, populate the description from the incident summary, and tag the ticket category Cybersecurity / AI Agent.
3. Set NYDFS 500.17 72-hour notification clock → write a record to a custom log table NYDFS500_17_Timer_CL with fields IncidentId, OpenedUtc, NotificationDueUtc = OpenedUtc + 72h, Status = "Open". Sentinel does not make the notification decision — that decision is made by the Compliance Officer per the firm's incident-response plan (Control 3.4). The timer table is decision support, not the decision.
4. Post adaptive card to #nydfs-500-17-watchlist Teams channel notifying the Compliance Officer that the timer has been started.
5. Add comment to Sentinel incident → "P3 fired at {utcNow()}. ITSM ticket {TicketId}. NYDFS 500.17 72h decision-support timer started; compliance review required by {NotificationDueUtc}."

The timer is decision-support, not a decision

NYDFS 23 NYCRR 500.17(a) requires notification to the Department of Financial Services within 72 hours of a determination that a cybersecurity event has occurred meeting the criteria in the regulation. The determination is a human judgment by the Compliance Officer / CISO informed by counsel, not an automated Sentinel output. P3 starts a decision-support timer that surfaces the deadline; it does not file with NYDFS, does not classify the event, and does not satisfy the 500.17 obligation by itself.

Portal authoring

1. Defender portal → Microsoft Sentinel → Configuration → Automation → + Create → name pb-3.9-P3-itsm-nydfs-timer.
2. Authorize the ITSM connector (out-of-band approval from the firm's ITSM admin).
3. Bind via automation rule with the rule and severity filters above.

[Screenshot anchor: ]

Examiner Evidence Box — §6 Automation

• Each Logic App's run history (last 90 days) showing successful triggers and any failed runs with remediation comments
• The CISO sign-off ticket for P1
• The AI Governance Lead sign-off tickets for P2 and P3
• For each P3 run in the last quarter, the entry in NYDFS500_17_Timer_CL and the corresponding Compliance Officer disposition (notified / no-notification with reason)

Cross-Reference

Logic App run failures, ITSM connector authentication errors, and managed-identity permission issues are routed to troubleshooting.md. Automation rule binding (which rule fires which playbook with which severity gate) is a key audit artifact — capture the Automation rules list view in the §10 packet.

---

§7. Per-Table Retention with the Books-and-Records Boundary

Sentinel's retention model has three tiers:

Tier	Period	Use
Interactive	Default 30 days, configurable up to 730 days (and recently up to 4 years for some tables)	KQL queries, analytics rules, workbooks
Auxiliary / Basic logs	Up to 2 years	Cost-optimized retention for high-volume, low-query tables
Archive	Up to 12 years (Sentinel)	Long-term audit-trail retention with restore capability

This section configures retention per table to support the audit-trail expectations of NYDFS 500.06, FFIEC IT Examination Handbook (Audit), and SOX §404 (where AI agent activity is in scope of financial-reporting controls).

7.1 Recommended retention by table

Table	Interactive	Archive	Total	Rationale
OfficeActivity (incl. CopilotInteraction)	180 days	up to 12 years	up to ~12 years	NYDFS 500.06 + audit-trail floor; but see books-and-records boundary below
AADServicePrincipalSignInLogs	180 days	7 years	7 years	Agent identity audit trail; aligns with FINRA recordkeeping floor for related access logs
SigninLogs, AADNonInteractiveUserSignInLogs	90 days	2 years	2 years	Operational; books-and-records authority routes to Purview
AuditLogs (Entra)	180 days	7 years	7 years	Directory-change audit trail; high regulatory value
CloudAppEvents	90 days	2 years	2 years	Operational; high volume
PowerPlatformAdminActivity, PowerPlatformDlpActivity	180 days	7 years	7 years	DLP-policy change ledger; GLBA Safeguards Rule §314.4(c)(8)
AlertInfo, SecurityAlert	180 days	up to 12 years	up to ~12 years	Incident audit trail (NYDFS 500.16 IRP evidence)
AppRequests, AppDependencies (App Insights)	30 days	None	30 days	Operational telemetry only

7.2 Configuring per-table retention

1. Azure portal → Log Analytics workspaces → the workspace from §2.1 → Tables (preview).
2. For each table in the table above, click the row → Manage table → set Total retention period and Archive period per the table.

3. Save and verify the next day via:

   .show table OfficeActivity policy retention
   

[Screenshot anchor: ]

7.3 The books-and-records boundary — read this carefully

Sentinel is NOT an SEC 17a-4(f) records archive

The retention values in §7.1 support operational audit trail expectations. They do NOT by themselves satisfy:

• FINRA Rule 4511 books-and-records preservation requirements
• SEC Rule 17a-3 record creation requirements
• SEC Rule 17a-4 record preservation requirements, including 17a-4(f) WORM / non-rewriteable, non-erasable storage and audit-trail integrity requirements

Books-and-records data — including customer communications produced by or assisted by an AI agent that meet the definition of broker-dealer records — must be:

1. Captured by Purview retention labels under Control 1.9.
2. Preserved in a compliant 17a-4(f) WORM vendor archive (e.g., Smarsh, Global Relay, Microsoft 365 Archive with a third-party 17a-4(f) attestation, or an equivalent solution that the firm's compliance counsel has reviewed against the rule's text).
3. Reviewed under the firm's supervisory system per Control 2.12 — Supervision and Oversight (FINRA Rule 3110).

Sentinel complements the books-and-records program by retaining security telemetry (sign-ins, alerts, audit events) that demonstrate the integrity of the records system. Sentinel does not replace the records program. Implementation of records preservation requires architecture decisions, vendor procurement, and sign-off by compliance counsel that are outside the scope of Control 3.9. Organizations should verify their records-preservation architecture with their compliance counsel before relying on Sentinel retention for any records obligation.

Examiner Evidence Box — §7 Retention

• Per-table retention configuration screenshot for each table in §7.1
• The cross-reference document (one page) stating which tables Sentinel owns vs. which records flow to Purview / 17a-4(f) archive — signed by the Sentinel Admin and the Compliance Officer
• The 17a-4(f) vendor attestation reference (vendor name, attestation date, scope) — even though the vendor is owned by Control 1.9, the cross-reference is captured here so an examiner reviewing Control 3.9 can immediately see the boundary

Cross-Reference

See Control 1.9 — Data Retention and Deletion Policies for the books-and-records architecture. See Control 1.7 — Comprehensive Audit Logging and Compliance for the upstream Purview audit-log retention configuration that feeds OfficeActivity.

---

§8. Incident Investigation UX in the Defender Portal

This section walks through the SOC analyst experience for triaging an AI-agent incident in the Defender portal unified view.

8.1 Open the incident

1. security.microsoft.com → Incidents & alerts → Incidents.
2. Filter: Service source = Microsoft Sentinel AND Tags contains "agent" (apply the agent tag via automation rule on the §4 detections to make this filter cheap).
3. Click an incident.

8.2 Read the unified incident page

The Defender portal unified incident page shows:

• Attack story graph — entities (User, Service Principal, IP, Cloud App, Agent), nodes, and lateral movement.
• Alerts tab — all Sentinel and Defender alerts grouped into the incident.
• Assets tab — affected users, devices, mailboxes, and AI applications (when surfaced by the Microsoft Copilot connector).
• Investigation tab — automated investigation results, where applicable.
• Evidence and response tab — files, processes, IPs, and actions taken (including P1 suspension if it fired).

[Screenshot anchor: ]

8.3 Enrich with Agent 365 registry

The custom entity AgentId is mapped at rule authoring (§4.0). In the incident page, click the AgentId entity → Side panel → the panel includes a Custom enrichment section pulling from the Agent 365 watchlist (configured as a custom-details entity in §4):

• Owner UPN, owner business unit, owner manager
• Agent zone (1, 2, or 3)
• Sensitivity classification
• Approved connectors / allowed MCP tools
• MRM tier and last MRM re-validation date

This enrichment is the single most-used artifact in SOC triage and significantly compresses the first-response window.

Cross-Reference

The Agent 365 watchlist is sourced from Control 2.25 — Agent 365 Admin Center Governance Console. If the registry is sparse or stale, incident enrichment degrades and SOC mean-time-to-respond increases — this is a cross-cutting program risk, not a Sentinel deficiency.

8.4 Cascade to Control 3.4 incident reporting

For any incident that the SOC determines is a reportable event:

1. In the incident page → Manage incident → set Status = Active, Classification = True positive, Determination per the firm's taxonomy.
2. Click Tasks → assign the incident-reporting and RCA tasks defined in Control 3.4.
3. If P3 fired (NYDFS 500.17 timer), confirm the entry in NYDFS500_17_Timer_CL and notify the Compliance Officer.
4. Export the incident to PDF from the incident page ⋯ menu → Print for the post-incident report.

Examiner Evidence Box — §8 Investigation

• For a representative quarter, the Incidents filtered view (Sentinel + tag agent) showing volume and disposition
• One worked example from triage to closure with timestamps, status changes, and evidence references
• The link from a closed Sentinel incident to its Control 3.4 RCA artifact

---

§9. Sentinel MCP Server — Optional Analyst Augmentation

The Sentinel MCP Server exposes Sentinel data and operations as tools to MCP-compatible AI assistants (e.g., a SOC analyst's GPT-based copilot). At the time of writing it is in Preview / GA in commercial cloud and not available in GCC High or DoD.

Optional capability with cost and license implications

Sentinel MCP is optional augmentation, not a Control 3.9 baseline requirement. It can accelerate analyst triage but it adds licensing cost (Sentinel data-lake tier + MCP server license) and a new attack surface (an LLM with read access to Sentinel data). Verify the current licensing and pricing on the Microsoft Sentinel pricing page and run the firm's third-party-AI risk review before enabling.

9.1 Preconditions

1. Sentinel data-lake tier enabled on the workspace (Azure portal → workspace → Sentinel data lake → Enable).
2. MCP server license verified.
3. Firm's third-party-AI risk review completed for the analyst-facing MCP client (whatever client the SOC will use).
4. CISO sign-off on the read-scope granted to MCP and the user population permitted to use it.

9.2 Enable the MCP server

1. Defender portal → Microsoft Sentinel → Configuration → Sentinel MCP (or equivalent blade — confirm current path).
2. Click Enable. Authorize with the Sentinel Admin account.
3. Configure the Authorization scope — restrict to read operations on a defined set of tables (do not grant write/edit).
4. Configure the User scope — restrict to the SOC distribution group.
5. Save.

[Screenshot anchor: ]

9.3 Connect an MCP client

1. In the analyst's MCP-compatible client (e.g., the SOC's Copilot Studio agent or a sanctioned external assistant), add the Sentinel MCP server endpoint.
2. The analyst authenticates with their Entra credentials; the MCP server uses on-behalf-of token flow to ensure the analyst's own RBAC is enforced.
3. Test with a simple query (e.g., "summarize Sentinel incidents tagged agent in the last 24 hours by severity").

9.4 Operating constraints

• Read-only. Do not grant write scope to the MCP server. Any analyst-driven action (close incident, run playbook, edit rule) must be performed in the Defender portal so the action is captured in the standard audit trail.
• PII / NPI in queries. Analyst prompts and MCP responses may contain customer NPI under GLBA. Treat MCP transcripts as Confidential-NPI; capture them in the firm's analyst-tooling DLP scope.
• Hallucination risk. MCP returns summaries, not authoritative records. Any artifact that goes into an examiner packet, an RCA, or a regulatory filing must be sourced from a direct KQL query in the Defender portal, not from an MCP response. The MCP response is an analyst aid; the KQL output is the record.

MCP responses are not records

The output of a Sentinel MCP conversation is not an SEC 17a-4(f) record, is not examiner evidence, and must not be relied upon as the source-of-truth for any compliance disposition. MCP aids analyst speed; the Defender portal and the underlying Log Analytics workspace remain the authoritative record.

Examiner Evidence Box — §9 MCP (if enabled)

• The CISO sign-off ticket
• The third-party-AI risk-review artifact
• The MCP authorization-scope screenshot showing read-only and the user-scope restriction
• The DLP scope coverage for analyst MCP transcripts

Cross-Reference

If the firm chooses not to enable Sentinel MCP, document the decision in the §1 worksheet (sovereign clouds) or in a standalone control-decision artifact (commercial). Non-adoption of an optional capability is not a control gap.

---

§10. Evidence Capture, Zone Cadence, and Examiner Packet

This section defines the operating cadence and evidence packet for Control 3.9.

10.1 Cadence by zone

Zone	Activity	Frequency	Owner
Zone 1 (Personal)	R1–R5 enabled; P2 notification on incidents	Continuous	SOC Analyst
Zone 1	Workbook 5.1 review	Monthly	AI Governance Lead
Zone 2 (Team)	All seven rules R1–R7 enabled; P1 + P2 + P3 enabled	Continuous	SOC Analyst
Zone 2	Rule tuning review (false-positive rate, threshold drift)	Monthly	SOC Analyst + Sentinel Admin
Zone 2	Workbook 5.1 review	Bi-weekly	AI Governance Lead
Zone 3 (Enterprise)	All rules enabled; App Insights workbook 5.3 enabled	Continuous	SOC Analyst
Zone 3	Rule tuning review	Weekly	SOC Analyst + Sentinel Admin
Zone 3	Workbook 5.1 + 5.3 review	Weekly	AI Governance Lead
All zones	§1 sovereign-cloud worksheet re-check	Quarterly	Sentinel Admin
All zones	§10 evidence packet assembly	Quarterly	Sentinel Admin + Compliance Officer
All zones	Full §0–§7 walkthrough re-execution (greenfield rebuild test)	Annual	Sentinel Admin

10.2 The §10 evidence packet

Assemble quarterly. Store in the Purview evidence library tagged Control-3.9 / <YYYY>-Q<N>. The packet is the primary examiner deliverable for Control 3.9.

#	Artifact	Source section
1	Roles + PIM eligible-assignment screenshots	§0
2	Cost budget screenshot	§0
3	Workspace decisions ticket	§0
4	Sovereign-cloud compensating-control worksheet	§1
5	Workspace properties + lock screenshots	§2
6	Defender portal Connected banner	§2
7	Per-connector status + verification KQL output (×7 connectors)	§3
8	Entra diagnostic-settings screenshot showing all sign-in tables enabled	§3.2
9	Per-rule detail page + KQL screenshot + 30-day alert summary (×7 rules)	§4
10	Three workbook PDF exports	§5
11	Three Logic App run-history exports + sign-off tickets	§6
12	Per-table retention configuration screenshots + records-boundary cross-reference	§7
13	One worked incident (triage to closure) demonstrating §8 enrichment + §3.4 cascade	§8
14	MCP enablement evidence OR documented non-adoption decision	§9
15	Cadence-table compliance log (last quarter)	§10.1
16	Rule-tuning ledger (changes, dates, approvers)	§10
17	Quarterly sign-off cover sheet — Sentinel Admin + AI Governance Lead + Compliance Officer	§10

10.3 Verification criteria summary

VC	Description	Source section
VC-1	Roles assigned PIM-eligible; cost budget exists	§0
VC-2	Sovereign-cloud worksheet completed (sovereign tenants)	§1
VC-3	Workspace deployed + onboarded to Defender portal + RG locked	§2
VC-4	All seven connectors connected with non-zero ingestion verified	§3
VC-5	Seven analytics rules deployed and producing alerts	§4
VC-6	Three workbooks deployed and pinned	§5
VC-7	Three Logic Apps deployed with sign-off and successful run history	§6
VC-8	Per-table retention configured per §7.1 with records-boundary cross-reference	§7
VC-9	One worked incident in last quarter demonstrating §8 enrichment	§8
VC-10	MCP enabled with constraints OR documented non-adoption	§9
VC-11	Quarterly evidence packet assembled and signed off	§10

Detailed verification procedures (KQL probes, dry-run injection tests, evidence-collection commands) are in verification-testing.md.

Examiner Evidence Box — §10 Cadence

• The §10 evidence packet itself for the most recent four quarters
• The quarterly sign-off cover sheets
• The annual greenfield-rebuild test result (proves the runbook is current and reproducible)

Cross-Reference — supervisory program

Sentinel evidence is one input to the firm's supervisory program under Control 2.12 — Supervision and Oversight (FINRA Rule 3110). The §10 packet should be referenced from the firm's annual 3110 written supervisory procedures testing.

Cross-Reference — long-window observability

For long-window analytics that exceed Sentinel's interactive retention (e.g., year-over-year agent behavior trends, multi-quarter MRM input), see Control 3.14 — Agent 365 Observability SDK. The SDK complements Sentinel; it does not replace any of the detection, alerting, or incident workflows defined in this walkthrough.

---

Updated: April 2026 | Version: v1.4.0 | UI Verification Status: Current