Help: S1 blocking a crucial accounting software. Whitelisting isn't sticking.

Whitelists failing to stick in SentinelOne are almost always a symptom of misaligned detection scopes. You've added an exclusion, but for what? The detection is likely for "suspicious behavior," not for the static file.

First, stop thinking about the application as a single file. That legacy accounting app probably spawns child processes, calls to unusual DLLs, or scripts its own updates in a way that triggers behavioral AI. A path or hash exclusion for the main .exe does nothing for those spawned components.

You need to find the *exact* detection name from the Activity Log. Then, create an exclusion that matches the detection type (e.g., "Suspicious Behavior," "Malicious Activity") and scope it appropriately. Sometimes you need a broader "File Path" exclusion on the parent directory, not just the binary. Other times, you need to whitelist the specific script engine it's using.

As for your comparison point, in my experience, CrowdStrike's exclusions are equally granular and fussy, but their logging makes the root cause slightly easier to trace. Microsoft Defender is often more forgiving of legacy app chaos, but that's a feature, not a bug, in your specific case. Tell your S1 sales engineer you need the exclusion workflow sorted, or the pilot fails on operational grounds. That usually gets a senior support resource involved who can decipher the detection chain.

Oh man, I've been in this exact spot during our rollout. The hash and path exclusions can feel like they're working... until they just don't.

You nailed it with the policy inheritance guess. That tripped us up for a week. Check if there's a higher-level policy, maybe from a parent group, that doesn't have the exclusion. S1 applies the most restrictive policy it finds, so your custom pilot policy might be getting overridden. It's a hierarchy thing that's easy to miss.

As for the CrowdStrike comparison, we ran them side by side for a bit. Honestly, their exclusions are rock solid once set, but S1's behavioral AI is just more... jumpy. For a legacy app that does weird things, you might need to pair the file exclusion with a *behavioral* exclusion for the specific detection. It's a two-step fix.

Yep, exactly this. The behavioral AI doesn't care about your file hash. We had a similar case where a script the app spawned to call a web service was the real trigger. You need that exact detection name from the log.

One extra tip: once you find the detection, scope the exclusion to the whole folder path. We used `C:Program Files (x86)OldApp*` and it finally stuck.

The other replies about hunting down the exact behavioral detection are correct, but you're also asking the right internal questions. Yes, check the policy inheritance first. In the console, look at the agent's actual "Applied Policies." If you see more than one, that's your problem. A global policy without the exclusion will stomp your pilot policy every time.

On your point about exclusion reliability compared to CrowdStrike, they're different beasts. CrowdStrike's exclusions are more static and predictable, which is good for legacy junk. S1's AI model is constantly retraining locally on each endpoint. That's why your exclusion seems to "wear off." It's not a bug, it's the system learning again and deciding the activity is still sketchy. You need to kill the detection at the source, not just hide the file.

For a workflow, start here:
* Go to the Activity Log for a blocked machine, filter for that app, and find the full detection name.
* Create a behavioral exclusion for that *specific* detection name, scoped to the application's entire directory with a wildcard.
* Then, and only if you still get false positives, add a hash exclusion for the main executable as a belt-and-suspenders measure. The path exclusion alone is often useless for the child processes.

Policy inheritance is likely your problem. Check the agent's applied policies view in the console. If you see a global policy listed, that's overriding your pilot group's exclusions.

For the app itself, forget hash exclusions. Find the exact detection name from the activity log. You'll probably need a behavioral exclusion scoped to the whole program directory, not just the main .exe file.

Compared to CrowdStrike, S1's AI is more aggressive and retrains locally. An exclusion isn't a permanent bypass, it's telling the engine to ignore a specific suspicious pattern from a trusted source.

The other replies have covered the main angles well - policy inheritance and behavioral detections are your likely culprits. To your specific point about exclusion reliability compared to CrowdStrike or Defender, think of it this way: a hash exclusion in S1 tells the engine "don't flag this *specific file* as malware," but it doesn't tell the behavioral AI to stop watching what that file *does*. For a legacy app that acts oddly, you need to address both.

So your workflow should be:
1. Confirm the applied policy on one affected endpoint. If a parent policy is present without the exclusion, that's step one.
2. If the policy is correct, dig into the Activity Log for that endpoint and find the *exact* detection name. It'll be something like "Suspicious Behavior - Code Injection."
3. Create a new exclusion of type "Suspicious Behavior" (or whatever the log shows), and scope it to the entire application directory using a wildcard path.

That two-layer approach - static file plus behavioral pattern - usually makes it stick. Defender is more similar to S1 here, while CrowdStrike's prevention model is a bit more static and predictable for these edge cases.

That point about policy inheritance is so critical. We had a similar setup with a pilot group, and the Applied Policies view was the only way we spotted a default "Full Protection" policy from the site level that was silently overriding our exclusions. It's not intuitive at all until you see it laid out there.

And I think you're right on about the two-step fix. For our legacy inventory app, we found we needed a file path exclusion for the main program directory *and* a separate behavioral exclusion for "Suspicious Behavior - Process Hollowing" that the app's updater triggered. Just doing one never fully stopped the alerts.

Policy inheritance is the first check, but it's become the forum's favorite scapegoat. The real problem is likely the local AI model retraining. It learns your exclusion, then the app does something else weird a day later and triggers a different pattern. Hash exclusions are nearly useless for these legacy beasts.

Comparing it to CrowdStrike on "exclusion reliability" is missing the point. CrowdStrike is a bouncer with a list. S1 is a paranoid security guard who re-evaluates everyone every shift. You need to find the specific behavioral detection name and create an exclusion for that, scoped to the whole app directory. It won't be "absolute," it'll be a constant game of whack-a-mole with the app's weird behaviors.

Policy inheritance is the easy answer everyone's fixated on, but it lets you off the hook too early. Even with a perfect, standalone policy, you'll lose.

The core issue is thinking about exclusions as a static rule. They're not. S1's local model is constantly re-evaluating, and your "legacy, but critical" accounting app is probably doing a dozen weird things a modern app wouldn't. A hash exclusion for AccountingLauncher.exe is meaningless when the real trigger is a spawned sub-process like `ARWScriptEngine.exe` writing to a temp file. The behavioral AI sees that new, weird thing and flags it.

> We need the exclusion to be absolute for this particular app.

That's your problem right there. You're asking for a static solution in a dynamic system. The "absolute" fix is to run the app in a VM isolated from S1, or to pester the vendor for a less-janky update. Barring that, you're committing to a maintenance cycle:

1. Find the *exact* detection name from the log (e.g., "Suspicious Behavior - Scripting Abuse").
2. Create a Behavioral Exclusion for that detection, scoped to the entire program directory (`C:ProgramDataOldAccounting*`).
3. Wait. It'll likely trigger on a different behavior next week. Repeat.

Compared to CrowdStrike? CrowdStrike's exclusions are more like a firewall rule - set it and forget it. S1's are more like a permission slip you have to keep renewing because the hall monitor keeps getting new suspicions. It's not about reliability, it's about fundamentally different philosophies. You picked the paranoid guard. Now you have to keep convincing him.

Good questions. On policy inheritance, I'd suggest logging into the console and checking the "Applied Policies" view on one of the affected endpoints. If you see more than one policy listed, that's your culprit. A parent or global policy without the exclusion will override your pilot settings.

The bit about needing an absolute exclusion is the tricky part. With S1's behavioral AI, exclusions are more like guidelines for a constantly learning system, not a permanent off switch. A hash or path exclusion tells it "don't flag this file," but it doesn't stop watching what that file *does*. You'll likely need to find the exact behavioral detection name from the activity log and create a separate exclusion for that pattern, scoped to the app's entire directory. It's a two-step process for these older apps.

All three of your questions are hitting the right spots. Policy inheritance is the most common gotcha, so that's the fastest check. Pull up the "Applied Policies" view for one of the blocked endpoints right now. If you see a global policy listed alongside your pilot policy, you've found your first problem.

But even if that's clean, your focus on getting an "absolute" exclusion is where you'll hit the wall. You're fighting the product's design. SentinelOne's AI doesn't just check a file once, it continuously monitors behavior. Your path or hash exclusion for Accounting.exe means nothing when the app spawns a helper process that does something sketchy an hour later. That's why the block seems to come back.

You need to find the exact behavioral detection name from the Activity Log on an endpoint that just blocked it. Then create a behavioral exclusion for that specific pattern, scoped to the entire application directory. It's rarely just one. Be prepared to repeat this process as the app's other odd behaviors get flagged.

The folder path scope you mention is crucial, but I'd add you need to be careful with trailing wildcards. Using `C:Program FilesApp*` only excludes files directly in that folder, not subdirectories. For an accounting suite with nested folders for modules and logs, you often need `C:Program FilesApp**`. I've seen exclusions fail because the detection came from a script in a subfolder three levels down.

That's a great catch about the wildcards. I wouldn't have thought about subfolders. So for a path exclusion to be truly effective, you'd need to scope it with the double-asterisk to cover the whole install directory and everything inside it, right?

Does the same logic apply to the behavioral detection exclusions? If the AI flags a script in a nested log folder, does the behavioral rule also need that `**` scope?

That two-step process is exactly right. The file hash tells S1 to ignore the binary's signature, but the behavioral AI is still analyzing its runtime actions.

We had a similar case with an old ERP client. We excluded the main executable, but it kept triggering "Suspicious Behavior - Process Impersonation." We had to pull the exact detection name from the Activity Log and create a second behavioral exclusion scoped to the whole program directory with `**`. Only then did the blocks stop.