There is a known issue in currently available versions of ENS 10.6.1 where Exploit Prevention exclusions are not working properly with signer details. This issue will be addressed in upcoming ENS 10.6.1 December Update. I recommend you wait for mentioned release and test your EP Exclusion again.
The issue I'm describing is not related to the bug as I see, but with the capability of the product to fulfill specific use case. I can see exploit prevention policy exclusions section tool allows to create exceptions based on process name and signer and by caller module name and signer. In this rule case, process is powershell.exe and there is no caller module. So signing our internal scripts in order to trust those and exclude from exploit prevention rules triggers is not capability of current product. Or I miss something?
We are experiencing the same issue. We have various parts of our environment from SCCM client, DevOps configuration scripts, etc. that utilized powershell with parameters such as -EncodedCommand, etc. The rules from McAfee are simply based on signatures, so if it sees the behavior, it will block ifyour rule is configured to Block. However, I found not good way to create exclusions based on the properties of the event details (i.e Threat Target User Name:) . Basically, the rules are not sophisticated enough to determine a "good" from a "bad" script, and provides no mechanism to tell it what is "good" (we wanted to exclude based on , so you are left with turning the rule into "Report" mode or disable it completely.