TL;DR: AI threat detection can surface anomalous activity faster than signature-based tools, but it still depends on baselines, human judgment, and approval gates for high-impact actions, according to Panther. The operational question is no longer whether to use ML, but where automation ends and accountable decision-making begins.
NHIMG editorial — based on content published by Panther: What Is AI Threat Detection? Where It Helps Most and Where It Still Needs Human Review
By the numbers:
- 67% of organizations are now shifting to behavior-based detection.
- 90 zero-day vulnerabilities were exploited in the wild in 2025, with 48% targeting enterprise technologies.
- The total detection-and-containment timeline drops from 299 days without extensive AI deployment to 201 days with extensive AI deployment, a 98-day difference.
Questions worth separating out
Q: How should security teams use AI without turning it into a control dependency?
A: Security teams should use AI for summarisation, correlation, and prioritisation, then keep containment in deterministic controls such as access policy, segmentation, and revocation.
Q: Why do identity and privilege signals matter so much in AI threat detection?
A: Because many real incidents move through valid credentials, delegated access, and over-privileged accounts rather than obvious malware.
Q: What do teams get wrong about anomaly detection in operations?
A: They often assume an anomaly score is the same as a validated incident.
Practitioner guidance
- Build identity-aware detection baselines Feed the SOC with identity, PAM, and NHI signals alongside endpoint and cloud telemetry so anomaly scoring can distinguish routine admin activity from compromised access patterns.
- Set human approval gates for disruptive actions Require analyst approval before account disables, host isolation, network segmentation changes, or any response that can interrupt production services.
- Version and test detection logic as code Store detection rules in a reviewable codebase, track changes, and test them against known adversarial cases so alert logic can be audited and tuned without guesswork.
What's in the full article
Panther’s full blog covers the operational detail this post intentionally leaves for the source:
- A deeper walkthrough of how Panther structures AI SOC workflows across ingest, triage, and escalation.
- Examples of detection logic and rule design that show how the platform packages signals for analysts.
- Operational examples of where human review is still required before account disables, isolation, or other disruptive actions.
- Platform-specific details on detection logic stored in Python or YAML for teams already standardising on code-first workflows.
👉 Read Panther's analysis of AI threat detection, human review, and SOC workflow design →
AI threat detection and human review: where do controls still break?
Explore further
Behaviour-based detection is now an identity problem as much as a SOC problem: once stolen credentials become the second most common initial access vector, identity telemetry becomes detection telemetry. That means IAM, PAM, and NHI governance can no longer sit beside SOC analytics as separate programmes. They have to share baselines, alert logic, and escalation criteria. The practical conclusion is that identity context must be built into threat detection design.
A question worth separating out:
Q: How can organisations tell whether their AI security model is actually working?
A: They should test whether the control stack can explain who acted, what data was touched, and what purpose the action served. If those three signals cannot be correlated in one incident view, the model is likely monitoring access without governing behaviour. That is a visibility gap, not a complete AI security posture.
👉 Read our full editorial: AI threat detection still depends on human review and context