Event Log Queries Go Self-Sufficient
June 30, 2026 · InfraScout Team
A recent update gave the Windows Event Log tool structured filters for Event IDs and Event Data fields, so an AI-driven investigation could ask precise questions without hand-rolling PowerShell. This update closes the last gaps that still sent it back to the shell. The tool now accepts a raw XPath filter for the questions structured filters can't express, answers counting questions with a number instead of a page of entries, and — across every InfraScout tool — refuses a query built on arguments it doesn't recognize instead of running it unfiltered.
The motivating case was a Kerberos troubleshooting session on a domain controller. The model reached for the event log tool once, then abandoned it and fell back to improvised PowerShell three times in a row. The data was there the whole time; the problem was that the filter arguments it tried to pass didn't match the tool's real parameter names, and the mistyped fields were silently dropped. The query ran unfiltered, came back for the wrong account, and the model reasonably concluded the tool didn't filter and gave up on it. The three changes below make that failure mode impossible.
Raw XPath filters, applied verbatim
Structured filters cover the pivots most investigations need, but Windows itself speaks a richer filter language, and some questions map onto it naturally. The event log tool now accepts a complete XPath 1.0 filter and applies it verbatim — the same expression language Windows Event Viewer's custom views and Get-WinEvent -FilterXPath use. When a question is best expressed as an XPath predicate, InfraScout passes it straight through instead of reverse-engineering an equivalent out of structured filters or falling back to the shell.
A raw XPath filter stands on its own: it can't be combined with the structured Event ID and Event Data filters, and the tool rejects that combination up front, before it touches the host, so the two strategies never quietly blend into an ambiguous query. A malformed filter is just as clear — it comes back as an error describing what went wrong, which the AI can read and correct in the same turn rather than puzzling over an empty result.
Count-only mode answers "how many" directly
Sometimes you don't want the events, you want the tally. "How many 4768 and 4771 failures in the last three days?" is a counting question, and paging through every matching entry to answer it is wasted effort. Count-only mode returns the answer directly: a total match count plus a per-Event-ID breakdown, so you see not just that there were failures but how they split across each ID.
Like every event log scan, a count is bounded by the examined-events ceiling that keeps deep scans on a chatty channel responsive. When that ceiling is reached before the scan runs out of events, the result says so — a floored count is explicitly flagged, so a partial tally is never mistaken for a complete total. The number you get is always either the real count or a count you know is a lower bound.
Wrong arguments now fail loudly — on every tool
The quietest bug is the one that returns a plausible answer. Until now, if a query named a parameter that doesn't exist — a mistyped field, or one the model invented — the unknown argument was silently ignored. The query still ran, just without the filter you thought you'd applied, and returned results the AI took at face value. That is exactly what derailed the domain controller session: the filter arguments were dropped, the query came back for an unrelated account, and the model concluded the tool was broken.
Now any unrecognized argument returns an immediate, actionable error that names the offending field. The AI reads it, fixes the call, and re-runs in the same turn, so an unfiltered result never gets a chance to masquerade as a filtered one. This is not limited to event logs — every InfraScout tool now rejects arguments it doesn't recognize, so a hallucinated parameter fails fast everywhere instead of quietly skewing a finding. Because the check runs on the server, it applies to every connected agent immediately, regardless of agent version.
Keep your agents current
Older agents ignore the new event log fields
Raw XPath filters and count-only mode both depend on an up-to-date agent. An older agent simply ignores the new fields, which means a raw XPath filter sent to an outdated agent comes back as unfiltered events rather than an error. Agent auto-update keeps your fleet current automatically — review your update policy to confirm it. The stricter argument checking is server-side and needs no agent update.
Try it
Open an assessment against a connected Windows host and ask a question that fits one of the new shapes: "how many failed Kerberos pre-authentications in the last three days," which comes back as a count with a per-Event-ID breakdown, or a targeted lookup best written as an XPath expression, which InfraScout now passes through directly. Either way, the event log tool answers on its own — no fallback to improvised PowerShell, and no unfiltered result quietly standing in for the one you asked for.
Questions or feedback? Reach us at info@infrascout.cloud.