What fails when SOC detections only look for human-paced or scripted activity?

Why Human-Only Detection Misses the Relevant Threat Shape

Detections built around human cadence assume long dwell times, interactive pacing, and obvious step-by-step actions. Script-only detections assume repetitive, uniform execution. Agentic activity sits between those patterns: it can move quickly enough to avoid human timing assumptions, while still varying enough to avoid a rigid automation signature.

That gap matters because SOC logic often treats “fast” and “scripted” as separate buckets, then overlooks behaviour that is neither. The result is blind spots in triage, alert suppression, and anomaly scoring, especially when an actor is using ordinary infrastructure or familiar machine activity patterns to blend in.

What fails is the detector’s underlying model of intent. If the rule set cannot recognise a variable, tool-driven actor as distinct from both a person and a deterministic job, it will misclassify the activity as normal background noise or low-risk automation.

Why the Middle Ground Produces Under-Detection

Human-paced detections usually rely on expectations such as session length, number of actions per minute, or the likelihood that a person will pause between steps. Script detections usually rely on repeated sequence similarity, fixed intervals, or rigid payload patterns. Agentic systems can change pace, branch conditionally, and vary their actions just enough to sit outside both sets of assumptions.

That creates two failure modes. First, defenders undercount real activity because the system does not look “human enough” to satisfy the human-behaviour rule and does not look “machine enough” to trip the script rule. Second, the SOC may over-trust ordinary service noise, assuming that any non-human burst is just background automation rather than an actor with decision-making capacity.

For practitioners, the key issue is not whether the actor is human or automated in a generic sense. It is whether the detector can observe behaviour, tool use, and authorization context closely enough to distinguish bounded automation from autonomous action that changes its own path.

What Detectors Need to Measure Instead of Human Versus Script

Better detection starts with behavioural context rather than actor stereotypes. Useful signals include unusual tool chaining, changing request order, cross-system traversal that does not match normal job logic, and privilege use that is technically valid but operationally odd for the time, source, or sequence involved.

Teams should also look for the relationship between pace and variability. A legitimate batch job is usually consistent in timing and shape. A semi-autonomous workflow may compress time, but it also adapts. That combination is what makes the pattern hard to catch with simple thresholds or static signatures.

Where this becomes most important is in alerts that are only tuned for one side of the spectrum. Detection engineering should ask whether the control measures action consistency, decision variability, and privilege context, not just speed or repetition. MITRE ATT&CK Enterprise Matrix and MITRE D3FEND are useful references for mapping those behaviours to adversary techniques and defensive countermeasures.

Risk and Threat Considerations

When detections only model human pace or scripted repetition, the main risk is a coverage gap that lets autonomous or semi-autonomous activity look ordinary. That can delay investigation, suppress alerts, and hide privilege use until the activity has already expanded its reach.

Failure mechanism: The SOC applies brittle thresholds that assume either a person or a fixed script, so variable machine-led behaviour falls between the rules and never becomes suspicious enough to escalate.

Impact: The organisation gets weaker telemetry on real compromise paths, lower confidence in detections, and a larger window in which tool-using activity can traverse systems without being challenged.

Practitioner Guidance

What to prioritise: Review detections that key off only dwell time, repetition, or fixed execution cadence. If those are your primary filters, add checks for sequence change, tool chaining, and cross-system movement so the logic can see behaviour, not just tempo.

What to verify: Confirm that normal batch jobs, admin scripts, and approved automations have known profiles. If you cannot describe the expected pattern, you cannot reliably tell benign automation from adaptive activity.

Common mistake: Treating every fast event as automation and every irregular event as human. The more useful question is whether the activity shows bounded operational logic or adaptive decision-making that changes its route.

Practitioner takeaway: Detection that only distinguishes people from scripts will miss the most operationally awkward class of activity, so build for behavioural variability and context, not for actor stereotypes.

Related resources from NHI Mgmt Group

• When do non-human identities pose the greatest risk to organizations?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?
• Why is visibility important for Non-Human Identities?