Why do fixed traffic rules miss low-and-slow attacks?

Why This Matters for Security Teams

Low-and-slow activity is dangerous because it exploits the gap between what is “normal” in a short window and what becomes clearly abusive only after time has passed. Fixed traffic rules are often tuned to catch bursts, so they miss gradual credential probing, token reuse, and tool chaining that stays under threshold. That matters even more when the traffic comes from NHIs, where compromise can look like legitimate automation for hours.

Current guidance suggests treating NHI abuse as an identity and behaviour problem, not only a network-volume problem. The NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks highlights how limited visibility and excessive privilege make gradual abuse harder to see. External advisories also show why speed matters: once secrets are exposed, attackers move fast, as reflected in CISA cyber threat advisories and incident reporting from Anthropic on AI-orchestrated abuse. In practice, many security teams encounter low-and-slow compromise only after a benign-looking automation path has already been used for access expansion.

How It Works in Practice

Fixed rules usually depend on thresholds such as requests per minute, failed logins, or API call volume. That approach works for spikes, but low-and-slow attacks are designed to stay below the line. A more durable approach is to combine anomaly detection with identity context, so the system watches for drift in behaviour, not just counts. For NHI traffic, that means correlating source identity, time of day, target sensitivity, command sequence, and credential age.

The practical shift is to detect patterns such as a service account that touches a new endpoint every few hours, a token that is reused across unusual destinations, or a workflow that slowly expands scope. The NHI Management Group’s 52 NHI Breaches Analysis is useful here because it shows how identity misuse often begins with small, scattered actions before becoming an obvious incident. Standards-oriented teams can map this to MITRE ATLAS adversarial AI threat matrix for attacker tradecraft and use policy-driven controls to evaluate requests in real time.

• Set baselines by identity, workload, and peer group, not only by endpoint or IP.
• Track cumulative behaviour over hours and days, including changes in target diversity and privilege use.
• Use short-lived secrets and rotation so slow abuse has less time to compound.
• Feed detections with IAM, vault, API gateway, and workload telemetry together.

For teams managing autonomous workloads, this is especially important because agents can chain tools, retry intelligently, and move laterally without a human-like burst pattern. These controls tend to break down in environments with weak identity telemetry and shared service credentials because the behaviour signal is too diluted to distinguish abuse from routine automation.

Common Variations and Edge Cases

Tighter behavioural detection often increases tuning effort and false positives, requiring organisations to balance sensitivity against operational noise. That tradeoff becomes more visible in batch systems, scheduled integrations, and CI/CD pipelines where repetitive access is normal.

Best practice is evolving, but current guidance suggests making exceptions explicit rather than relaxing detection globally. For example, a nightly job may legitimately create a repeated call pattern, while a compromised NHI may mimic that rhythm and slowly widen its access. In those environments, static thresholds should be paired with allowlisted workflows, context-aware policy checks, and review of credential age and scope. The NHI Management Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now helps frame why long-lived access and weak visibility create this detection gap. This is also where OWASP NHI Top 10 is relevant, because agentic and automated systems can turn a quiet foothold into staged privilege expansion.

Low-and-slow detections also break down when logs are incomplete, when secrets are shared across multiple services, or when alerting looks at single events instead of identity journeys over time. In those cases, the rule is not just “lower the threshold,” but “measure the right thing.”

Related resources from NHI Mgmt Group

• How can organizations counter AI-driven cyber attacks?
• Why do Microsoft first-party apps create extra risk in consent phishing attacks?
• Why do GitHub-based supply chain attacks create identity risk for cloud environments?
• What breaks when ad manager accounts are treated as low-risk marketing access?