We built security for perfect humans. Attackers didn’t.
Automating tier-one triage didn't remove human error from security operations, it just relocated it upstream into detection logic nobody revisits.
Session Details
What if the biggest vulnerability in your security architecture is not a missing control, but a wrong assumption about human behaviour?
Automating tier-1 triage was supposed to fix the human problem in security operations. Fewer analysts touching alerts. Less fatigue. Less inconsistency. And by most metrics, it worked.
Except the breaches kept happening.
Here is what we got wrong. When we automated the bottom of the stack, the errors did not disappear. They relocated. They moved upstream into detection logic, threshold configuration, and playbook design, sitting quietly in decisions made by smaller teams, written down once, and rarely revisited. We traded hundreds of small, visible, recoverable errors for a handful of large, invisible, catastrophic ones.
And attackers noticed before we did.
They are not just exploiting technical vulnerabilities. They are exploiting the gap between how security systems expect humans to behave and how humans actually behave under pressure. That gap used to live on the analyst floor. Now it lives in the assumptions baked into your automation stack, and it is considerably harder to see.
Drawing from real environments where automated playbooks closed genuine incidents as false positives and detection logic written years ago was still silently shaping triage decisions, this session examines exactly where upstream error now lives, why it is so much harder to spot than the alert fatigue it replaced, and why the humans left in the loop are being asked to make harder decisions with less context than ever before.
The industry declared victory on tier-1. But the attack surface for human error did not shrink. It just moved somewhere we stopped looking.
Attendees will leave with a practical framework for auditing their own automation stack, not just for whether it works, but for where the assumptions inside it were last examined, who made them, and what has changed since.
Because the most dangerous line of code in your SOC might not be something an attacker wrote. It might be a detection rule nobody has touched in years.
There's More Where This Came From
Browse hundreds of sessions and build an agenda around the topics that matter to you.








