Why the integration model matters more than the integration count
urgentic connects natively to over 200 security tools, and for most of them, "integration" means what it usually means: read alerts in, write results back, normalise the format in between. That is genuinely useful and it is how most SOAR-style connectors work. Microsoft Sentinel and Defender XDR get a different treatment, because for a large share of urgentic customers, Sentinel is not one data source among many — it is the primary evidence store the entire investigation runs against.
The distinction that matters is between a tool that reads Sentinel alerts and a tool that investigates inside Sentinel's own data model — querying the same underlying tables (SecurityEvent, SigninLogs, DeviceEvents, and the rest) that a human analyst would query by hand in the Sentinel workspace, rather than working from a flattened summary of what Sentinel decided to surface.
What the Orchestrator does with a Sentinel workspace
The Orchestrator agent watches a connected Sentinel workspace on a schedule the customer sets — typically every 5, 15, or 30 minutes — and picks up new incidents whether or not a webhook is configured on the Sentinel side. Not every environment has webhooks wired up, and requiring one as a precondition would leave a real gap in coverage for teams that have not gone through that setup step. Polling closes that gap without adding an onboarding requirement.
Every incident picked up this way is deduplicated against what has already been processed, so a single underlying event that Sentinel has correlated into multiple incidents does not turn into multiple redundant investigations downstream.
What the investigation actually queries
Once an incident enters the pipeline, the Entity Enrichment and Hunting agents query the Sentinel workspace directly for the context around it — sign-in activity for the accounts involved, device event history, related alerts across the same investigation window — rather than relying solely on what Sentinel’s own incident summary already surfaced. This is the practical difference between "reading the alert" and "investigating the case": the agents are working from the same raw log tables an analyst would open the Sentinel query editor to look at.
For Defender XDR specifically, the same pattern applies to endpoint and identity signal — device timeline, process trees, sign-in risk detections — pulled directly rather than taken secondhand from whatever Sentinel chose to forward.
What comes back into Sentinel
The investigation does not end as a report that lives only inside urgentic. Findings, containment recommendations, and detection rules generated by the Detection Engineering agent can be written back into the customer's own Sentinel workspace — new analytics rules, updated watchlists, incident comments with the full evidence trail — so a team that lives day-to-day inside the Sentinel console sees urgentic's work show up there, rather than needing to context-switch into a separate tool to get value from it.
Who this is actually built for
This depth of integration is specifically aimed at organisations that have already standardised on Microsoft for their security stack and want autonomous investigation added on top of it, rather than a second platform running alongside it. If Sentinel and Defender XDR are already the centre of your SOC's day-to-day, the practical question is not whether urgentic connects to them — every AI-augmented SOC vendor will say yes to that — but whether it investigates using the same data an analyst already trusts, or a simplified copy of it. That is the distinction this integration is built around.