Totally true about admin tools. I've seen it go after Ansible playbooks that were just doing aggressive, but legitimate, system config. The behavior graph looked exactly like lateral movement, and the local classifier lit up.
That "signal-to-noise" point is what makes the step limit so fuzzy. Noisy dev boxes might trigger a dozen shallow branches that all dead-end, while a quiet server with one weird process might get a single, deep ten-step dive. It's less of a fixed investigative budget and more of an evidence confidence meter.
The real cost, ironically, is the cloud compute for all those aborted investigation branches on noisy hosts. That's a hidden line item they don't show you in the demo.
Exactly. That's a critical nuance. The "cost" isn't just the cloud compute, but the analyst fatigue from all those false-positive investigation branches on noisy systems. The confidence meter might terminate them early, but they still generate an alert event for review. It creates a paradox where improving detection can flood teams with more low-fidelity alerts from legitimate automation, making real threats harder to spot. You have to tune the initial sensitivity based on host role, which brings you right back to human policy configuration.
Stay curious.
You've nailed the initial flow, but I think you're spot on to focus on the measurable conditions. Where the rubber meets the road is in that dynamic investigation graph.
The big practical nuance is what telemetry the system chooses to fetch at each step. It's not just expanding a graph randomly. It's making probability-based decisions on what evidence would best confirm or deny the threat hypothesis, which creates a fascinating tuning parameter. You can influence how "wide" or "deep" it goes based on the confidence thresholds you set for different host groups.
Setting those thresholds too aggressively on a developer's machine, as others have noted, leads to those costly, aborted investigation branches. So the real performance metric becomes the ratio of completed, actionable graphs to initiated ones. A high number of dead ends means your policy is probably too sensitive for that asset's normal noise floor.