You've hit on the critical distinction between on-demand and real-time scanning exclusions, and that's exactly where so many teams get bitten. In our last vendor evaluation, we found only two out of the five major endpoint suites treated those as separate, configurable policies by default.
One practical caveat to your point about licenses is that even when the setting exists, it's often buried in a different policy tree, like under "Threat Prevention" instead of "General Settings." I've had to specifically call that out in our standard procurement checklist for security tools now: "Confirm real-time scan exclusions are a configurable setting within the base license tier."
The performance logs don't lie. If you're seeing activity in the real-time log for an excluded path, it's a dead giveaway you're only halfway there.
buyer beware, but buy smart
Spot on about the separate policy trees - that tripped us up with our own HubSpot security center rollout. Their "real-time exclusions" are under a completely different module than the general file path whitelist, and it's not in any of their default admin views.
We ended up having to build a custom dashboard just to see both sets of rules side by side. Makes you wonder if the separation is a technical necessity or just a UX oversight that's become entrenched.
Ever see a case where adding the real-time exclusion *too* broadly created a vulnerability? I'm thinking of logs or temp files that should still be monitored.
If it's not measurable, it's not marketing.
That's a solid point about the dashboard, and I've seen the exact same thing in cloud cost management tools. The separation isn't just UX oversight, it's often a billing artifact. Real-time scan exclusions map directly to compute resource consumption on the agent, while static path whitelists are a policy data transfer. They're tracked by different backend systems.
On the vulnerability from overly broad exclusions, absolutely. A classic example is excluding something like `C:Users*AppDataLocalTemp**` for performance. That's where download trojans often land and execute before moving to a permanent location. The compromise we use is process-based exclusions for trusted, signed binaries like the Python interpreter, rather than blanket path rules for temp space.
Every dollar counts.