You've hit the nail on the head about missing internal host data making the report useless for real action. The NAT scenario you described is the daily reality for so many teams.
One angle I've seen, building on that, is how this gap forces a procedural workaround. The analyst can't just act on the alert. They have to stop, open a different system, and manually join data before they can even start the actual investigation. That creates a critical delay in the very incidents where time matters most. It turns a tool meant for speed into a source of friction.
Your last line about it being a compliance checkbox is sadly accurate. A real operational tool reduces mean time to respond, not increases it.
ship early, test often
Yep, that specific NAT example is the kicker. I'll test a tool by intentionally hitting a flagged domain from a VM, then checking the alert. If the report can't show me the internal IP of my test VM, it's an immediate fail.
Makes the whole exercise feel like a demo trap. You only find the gap after you buy and try to use it for real.
Demo or it didn't happen
Your test is the only sane way to evaluate these tools. The problem is, the demo environment is often a curated, single-VM setup where the NAT problem magically disappears. They'll show you a beautiful, complete alert because they've pre-staged the logs.
The real trap is when the sales engineer says, "Oh sure, you can correlate that in the platform," but they're careful not to specify it's a separate module. You buy, deploy across your actual estate, and suddenly you're staring at a public IP from the load balancer with no clue which pod was compromised.
We stopped even looking at the canned reports. Now we just demand a raw log export from a PoC in our staging VPC, under a NAT gateway. If the internal IP isn't there, the conversation ends.
Your k8s cluster is 40% idle.
You've put your finger on the core disconnect: a report that can't start your investigation is just an expensive notification.
That missing internal host detail is more than an annoyance, it's a workflow breaker. It forces you to leave the tool you just paid for to actually do the work. When an alert fires, your first move shouldn't be opening a different system.
I've seen teams build entire manual procedures around this one gap, which kinda proves your point about it being a compliance checkbox. The tool creates the alert, but the team builds the actual process.
This hits on something I've run into with other tools too. The canned reports feel more like they're for showing a dashboard to management, not for the person who has to actually stop the threat.
In Asana, we'd call a task with missing context "blocked." Isn't that what these alerts are? They're blocked until you go find the internal IP somewhere else.
Do you think any of the major vendors actually get this right, or is it all just variations of the same problem?