Scoping the behavioral exclusion to the whole directory with `**` is the only way it works. The file exclusion is almost irrelevant.
The real problem is that the detection name can be a red herring. Your "Process Impersonation" flag might be a symptom. Next week the same app could trigger "Suspicious Scripting" from a different component. You're just playing whack-a-mole with a smarter mole.
The only permanent fix is to isolate the legacy app.
Least privilege is not a suggestion.
Policy inheritance is the easy check, but you need to solve for the real problem: dynamic behavior.
> We need the exclusion to be absolute for this particular app.
This is the wrong goal with S1. You're fighting the engine. Path and hash exclusions don't stop the behavioral AI from watching what that process *does*. When a spawned sub-process or script acts weird, it triggers a new detection.
The workflow is this:
1. Confirm no policy override in Applied Policies.
2. Go to the Activity Log on a blocked endpoint. Find the exact detection name (e.g., "Suspicious Behavior - Process Impersonation").
3. Create a behavioral exclusion for that name, scoped to the entire application directory with `C:Program FilesYourApp**`. You'll likely need multiple behavioral exclusions over time.
Comparing to CrowdStrike is pointless. Different architecture. S1's exclusions are guidelines for a learning system, not a static off switch. Your only "absolute" fix is to isolate the app in a VM or on an excluded network segment.
Five nines? Prove it.
Your three specific questions are hitting the right pain points, and they reveal the conceptual mismatch you're facing.
On the first two, the consensus here is correct. You must verify policy inheritance via the "Applied Policies" view on an endpoint, but even a perfectly scoped policy will fail due to your third point. The desire for an absolute exclusion is fundamentally at odds with how SentinelOne's behavioral AI functions. A hash or path exclusion is not a permissions toggle, it's a contextual data point the engine considers. The engine is still evaluating runtime behavior of that process and any child processes.
For your comparison question, this is a core architectural difference. CrowdStrike's indicator exclusions and Microsoft Defender's process-based allowances often behave more like the static "off switch" you're seeking, as their detection logic can be more signature or IOC-driven at the execution stage. SentinelOne's model is more continuous, which is why you need to target the behavioral detection names directly from the Activity Log, scoped with `**` to the entire application directory. Without those behavioral exclusions, you are merely treating a symptom.
The workflow, therefore, is a diagnostic loop: isolate the exact detection name from a recent block, create a behavioral exclusion for it with broad directory scope, monitor, and repeat for the next unique detection. It's an iterative whitelisting process for the app's entire behavioral profile.