That one time I allowed my Security Engineer to make policy changes to our EDR

It took months to figure out why every device, from hypervisors in the data center to my own laptop, was running at 100% CPU every night.

Hundreds of alerts.
Hundreds of emails by morning.
I had a hunch, but no proof.

Here’s how it started.

I asked my Security Engineer to safelist a single fullpath for a DLL for one of our developers. Simple enough, right?

Except I never said, “only this one line, and only in this one policy.”
He copied all the whitelist entries from one policy, about a hundred lines, and pasted them across every policy.

And hidden in that list was this little gem:

\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

That one line effectively disabled Script Control in Cylance PROTECT (now Arora), which is designed to block PowerShell scripts and stop lateral movement.

Around that same time, our SOC partner, Arctic Wolf, convinced us to switch to Agent-based scanning.
Those scans use PowerShell.
Normally they’d be blocked.

But now they weren’t.
They got stuck in a loop every night from 9 p.m. to 2 a.m., hammering every device in our environment.

Perfectly aligned with my SEIM alerts.

After months of chasing ghosts, I finally reached out to Arctic Wolf’s team, who now own Cylance, and asked a very specific question.

Their response:

“The only thing I can see that might cause this is you’ve whitelisted PowerShell across all your policies.”

💡 Bingo.

I deleted that single line, and overnight, everything went back to normal.

Months of headaches and night sweats, all because of copy and paste.

The deeper truth

When people override policies, it’s still people who interpret, investigate, and remediate.

People over Policies.

How do you balance giving your team autonomy with protecting critical systems from human error?