Microsoft Sentinel and Log Analytics in Chat
October 2, 2026 · InfraScout Team
You can now review a Microsoft Sentinel deployment and query your Log Analytics workspaces from the same conversation as your Entra, Defender, and host checks. Ask which detections are actually running, which built-in ones never got switched on, whether a connector is delivering data, or what the workspace logs say about a sign-in you just flagged, and the AI answers from the workspace itself instead of from a portal tour.
What You Can Ask About Sentinel
Nine Sentinel tools read a workspace's configuration. The AI first checks that Sentinel is enabled on the workspace, then reads what you ask about: analytics rules with a coverage summary by kind, severity, and MITRE ATT&CK tactic; a single rule's full KQL, suppression, and incident settings; the rule templates that come with your installed Content Hub solutions; data connectors; automation rules in the order they run; watchlists and their items; and the installed solutions themselves.
Two of these answer questions that are tedious to piece together by hand. The template list can be narrowed to templates that no enabled rule was created from, which is your coverage gap: detections you already have available that are not running. The automation rule list calls out every rule that closes incidents, because a rule that closes incidents on creation suppresses a detection as effectively as disabling it.
The Sentinel tools read configuration, not incidents. For a workspace connected to the Microsoft Defender portal, Sentinel incidents and alerts already come through the Security tools. For a workspace that is not, the AI reads them from the SecurityIncident and SecurityAlert tables with a log query.
Querying Log Analytics
Four Log Analytics tools let the AI find workspaces in a subscription, see which tables received data recently and how much, read a table's columns before writing a query, and run KQL. That covers Azure activity, exported sign-in and audit logs, Windows security events, Syslog, custom _CL tables, and on a Sentinel workspace the Sentinel tables and watchlists.
Queries are bounded so a result fits in a conversation. At most 200 rows and about 100 KB come back, with no paging, and the search window defaults to one day unless the AI sets a longer one. When a result is cut off, the AI narrows or aggregates the query rather than paging through raw rows.
Log Analytics tool reference →
Three Conversations Worth Having
A coverage review starts with a question like this:
Review our Sentinel workspace's detection coverage. Which rule templates from our installed solutions are not enabled, and which of those could we turn on with the data connectors we already have? Also check whether any automation rule closes incidents automatically.The AI reads the rule summary, lists the templates no enabled rule uses, and compares each template's required connectors with the ones configured, so you end up with a shortlist you can enable today rather than a raw template count.
The second is whether a connector is actually ingesting. A configured connector does not prove that data arrives, and some connector pages say nothing about data flow at all. The AI checks the tables that connector feeds and reports when data last arrived and how much came in over the look-back window.
The third is correlation. When an Entra or Defender check turns up a suspicious sign-in, the AI can follow it into the workspace in the same chat, querying the exported sign-in logs or the security events of the host involved, without you switching tools or copying identifiers between portals.
Granting Access
Neither tool set needs a Microsoft 365 license (see Microsoft license requirements), but both need Azure role assignments that you make in your own tenant. Admin consent does not grant them, and the onboarding script does not assign them. For log queries, give the InfraScout app Log Analytics Data Reader on the workspace, its resource group, or the subscription; the scope decides which workspaces it can read. For Sentinel, give it Microsoft Sentinel Reader on the workspace or its resource group. That role also lets the app query the same workspace's logs, so you do not need both on one workspace. For the AI to find workspaces on its own, the app also needs Reader on the subscription; without it, give the AI the workspace's resource ID.
InfraScout only reads. Microsoft Sentinel Reader carries a few unrelated write actions that InfraScout never uses, so if your policy requires a strictly read-only grant, the connection guide includes a custom role with only what InfraScout reads, which you can assign in its place.
If a subscription belongs to a different tenant than the connection you asked about, the error now says so plainly and points the AI at your list of connections, so it switches to the right one instead of stalling on an access error with nothing to act on.
Granting Log Analytics and Sentinel access →
Queries That Cannot Send Data Out
Log rows can contain attacker-written text: command lines, file names, URLs, rule descriptions. InfraScout treats them as untrusted, and the AI never follows instructions found in them. As a second line of defense, KQL that would make Microsoft's side send data somewhere else, such as externaldata and similar remote-call functions, is refused before the query runs. This applies to Log Analytics queries and to Defender Advanced Hunting alike. If you want to match against your own list of indicators, put the list inline in the query with datatable() instead.