How do I filter out all the benign PowerShell activity from our IT admin machines?

We have successfully deployed Elastic Endpoint across our Windows estate, primarily for advanced threat detection on our developer and user workstations. The fidelity of the telemetry is impressive. However, we are now facing a significant signal-to-noise ratio challenge from our IT administrator machines, which are generating a high volume of PowerShell-related security alerts that are almost entirely benign. These machines are used for legitimate system management, software deployment, and automation tasks.

Our Security Operations Center is being inundated with alerts from events such as:
* Script block logging for internally developed deployment scripts.
* Use of standard PowerShell modules like `ActiveDirectory` or `ExchangeOnlineManagement`.
* Remote management sessions (`Enter-PSSession`) between trusted administrative jump hosts and servers.
* Expected, non-malicious use of encoded commands or script text as part of our standardized tooling.

This alert fatigue is causing a real risk of missing genuine threats buried within the noise. Simply turning off PowerShell logging for these hosts is not an acceptable solution, as we would lose visibility into potentially malicious activity that could originate from a compromised admin account.

Therefore, my core question is: **What is the most effective and sustainable methodology within Elastic Endpoint to filter out this known-benign administrative activity while maintaining critical security coverage?**

I am looking for a strategy that leverages Elastic's strengths in filtering and exception management. I have considered, but seek community validation on, the following approaches:

* **Endpoint Integration Policy Exceptions:** Creating allow-list exceptions for specific script hashes or command-line arguments tied to our known administrative toolset. The concern here is maintenance overhead as scripts are updated.
* **Elastic Agent Policy & Tags:** Applying a specific policy or tag to IT admin machines and using that as a filter in detection rules. For example, modifying pre-built rules to include a `where not host.tags: "it-admin"` clause.
* **Custom Detection Rules with Enhanced Filtering:** Building organization-specific rules that are more precise than the out-of-box ones. This would involve defining explicit, benign patterns to exclude.

A concrete example of the noise is the "Powershell Encoded Command" alert. Our deployment scripts routinely use the `-EncodedCommand` parameter for routine tasks. A sample rule modification I am prototyping in the Elastic Detection Engine looks like this:

```json
{
"query": """
event.category:process and event.type:start and
process.name:powershell.exe and
process.command_line:* -EncodedCommand * and
not host.name: ("JUMPHOST-01", "JUMPHOST-02") and
not process.command_line: "*OurDeploymentTool*"
"""
}
```

I am interested in the community's practical experience. Which method has proven most robust for you? How do you manage the lifecycle of these exceptions? Are there any pitfalls in creating too many host- or process-based exclusions that could inadvertently create blind spots?

- cost_cutter_ray