Detection engineering in the AI era is becoming a control gap

At a glance

What this is: This is an analysis of how AI is changing attack speed and variant volume, and why static detection engineering no longer keeps pace.

Why it matters: It matters because SOC, cloud, endpoint, and identity teams need detections that survive behavioural variation, not just indicator churn, especially where attacker automation compresses the window to detect and contain.

By the numbers:

• The platform investigates 100% of alerts across endpoint, identity, cloud, network, and SIEM.
• Less than 30% MITRE ATT&CK coverage is immature.
• 30 to 45% represents a decent in-house SOC.
• 60 to 70% is top-tier.

👉 Read INTEZER's analysis of detection engineering in the AI era

Context

Detection engineering is the discipline of turning telemetry into repeatable detections that catch adversary behaviour early enough to matter. In the AI era, that discipline is under pressure because LLM-assisted attackers can generate more variants, move faster, and adapt their approach more quickly than teams built around static indicators can absorb. The primary keyword here is detection engineering, but the real governance question is whether coverage is still validated against how attacks are executed, not just how they are labelled.

For identity and broader security programmes, the problem is not only endpoint or SIEM noise. When detection logic depends on weak telemetry, narrow MITRE mappings, or stale IOC lists, blind spots accumulate across identity, cloud, and operational workflows. That creates a governance gap between what a programme believes it sees and what it can actually investigate, which is why behavioural coverage and telemetry validation matter across SOC and identity-linked attack surfaces.

Key questions

Q: How should security teams improve detection engineering for AI-accelerated attacks?

A: They should shift from indicator-led rules to behaviour-led detections, then test those rules against multiple execution permutations before production. Teams also need continuous feedback from triage and investigation so detections improve as the environment changes. That combination is more durable than periodic tuning cycles and better suited to fast, variant-heavy attacker activity.

Q: Why do technique-level detection scores often overstate real coverage?

A: Because a technique label can hide shallow or partial coverage underneath it. If a rule only catches one sub-technique or one tool path, the broader score may look strong while an attacker uses another execution method and evades detection. The gap is between taxonomy and operational proof.

Q: What breaks when detections depend mainly on IOCs?

A: IOC-heavy programmes degrade quickly because infrastructure, hashes, and domains can be replaced or burned faster than rules are maintained. That creates noise, maintenance fatigue, and a false sense of visibility. IOCs still matter in investigation, but they are a weak foundation for primary detection logic.

Q: How do teams know if detection engineering is actually improving?

A: They should measure whether new detections survive variant testing, whether telemetry is complete enough to support triage, and whether alerts feed back into updated logic without long delays. If the programme only changes during quarterly reviews, it is probably drifting faster than it is improving.

Technical breakdown

Technique coverage vs sub-technique coverage

Many programmes map detections at the technique level and assume that covers the underlying behaviour. In practice, sub-techniques often represent materially different execution paths, tooling, or artefacts. A rule tied to one sub-technique may miss another variant that behaves differently but still satisfies the broader technique label. That matters because coverage dashboards can look healthy while the actual detection logic remains shallow. The issue is not the framework itself, but the temptation to treat mappings as evidence of operational coverage.

Practical implication: validate detections against sub-technique behaviour, not just high-level ATT&CK labels.

Why IOC-based detections degrade quickly

Indicators of compromise such as IPs, hashes, and domains are still useful in investigation, but they age badly as primary detection logic. Attackers burn them quickly, reuse changes, and alter infrastructure faster than manual rule maintenance can keep up. At scale, IOC-heavy programmes create churn, noise, and a false sense of protection. Behavioural detections are stronger because they focus on the sequence of actions, not the specific artefact left behind in one campaign.

Practical implication: move IOCs into enrichment and response, while using behaviour as the detection anchor.

Score-based detection and permutation testing

Score-based detection combines multiple weak signals until they cross a meaningful threshold. That is useful when no single event is conclusive, but several suspicious actions together create high confidence. Permutation testing does the other half of the job by stress-testing a rule against execution variants before it hits production. Together, these methods make detection logic more resilient to AI-generated attack variation and reduce the post-deployment tuning burden that overwhelms SOC teams.

Practical implication: test rules against multiple permutations and weight signals before production deployment.

NHI Mgmt Group analysis

AI does not change the core detection problem, it amplifies the cost of doing it badly. Attackers still execute on endpoints, create processes, move across networks, and touch identity and cloud systems. What changes is the speed and number of variants defenders must absorb. That means weak detections are no longer just incomplete, they become operational drag because every false assumption scales with attacker automation.

Sub-technique blind spots are a governance failure, not a tuning issue. When organisations report technique-level coverage but cannot prove sub-technique depth, they are measuring taxonomy coverage rather than defensive truth. That is especially dangerous in environments where identity, cloud, and endpoint events intersect, because a missing sub-technique can sit exactly where an attacker needs to blend across control planes. The governance lesson is to audit what a rule actually catches, not what its label implies.

Detection engineering becomes a closed-loop control problem once AI accelerates adversary behaviour. A mature programme does not end at alert creation. It connects detection, triage, and investigation so every verdict improves future logic, which is the named concept here: detection-response latency. The shorter the feedback loop, the less time attackers have to exploit stale logic. Practitioners should treat feedback as part of the control surface, not a post-incident cleanup task.

Telemetry quality is now a prerequisite for credible coverage claims. A pipeline that ingests broken or incomplete logs can produce impressive charts and no usable evidence. That gap is especially visible when identity-linked or host-level events are missing the context needed for triage. In NIST CSF terms, this is a monitoring and detection integrity issue, not just an engineering detail. Practitioners should validate the data before trusting the rule.

AI-era detection strategy should be measured by adaptability, not by raw percentage targets. High coverage scores can be misleading if they depend on sprawl, duplicated mappings, or stale logic. The better question is whether the programme can absorb new attack permutations without collapsing into noise. For identity and SOC teams alike, the goal is maintained relevance under change, not a marketing-friendly ceiling.

What this signals

Detection engineering programmes now need to assume adversaries will generate more variants than any rulebase can comfortably enumerate. The practical response is to tighten the loop between telemetry validation, behavioural detection, and triage so the SOC is not relying on stale logic when the next campaign appears. detection-response latency: the shorter the time from alert creation to learning, the less room attackers have to exploit gaps.

For identity-linked environments, detection quality is only as strong as the signals feeding it. If service account activity, cloud logs, or endpoint telemetry are incomplete, the programme will misread access patterns and miss cross-domain attack chains. Teams should align their detection work with the NHI Lifecycle Management Guide where identity lifecycle gaps create the conditions for weak signals.

The broader signal for security leaders is that coverage numbers are no longer enough to defend programme maturity. A credible detection engineering function proves that rules are meaningful in the data, resilient to permutations, and continuously improved through investigation outcomes. That is where controls, not dashboards, become the real measure of preparedness.

For practitioners

• Audit coverage below the label level Reconcile every technique mapping with the exact sub-techniques, event sources, and artefacts the rule can actually detect. Treat any technique score that cannot be demonstrated in logs as a gap, not a success.
• Shift IOCs into enrichment workflows Use hashes, domains, and IPs to enrich cases and validate investigations, but anchor detections on behaviours such as process chains, unusual paths, and suspicious sequencing. That reduces churn and improves signal durability.
• Test detections against permutations before release Generate variant execution paths, tool substitutions, and reordered steps in a sandbox before deploying new rules. Keep a record of which permutations fail so you can close those gaps before production exposure.

Key takeaways

• AI is raising attacker speed and variant volume, which exposes detection programmes that still depend on static indicators and shallow mappings.
• Coverage scores can be misleading when sub-technique depth, telemetry quality, and behavioural validation are not independently verified.
• The most durable response is a closed-loop detection model that tests permutations, learns from every alert, and treats data quality as a control requirement.

Key terms

• Detection Engineering: The discipline of designing, testing, and maintaining detection logic so it remains useful against real attacker behaviour. It covers telemetry selection, rule quality, false-positive management, and the operational workflow needed to keep alerts actionable.
• Sub-technique coverage: Sub-technique coverage describes how precisely a detection maps to the specific method an adversary uses, not just the broad tactic or technique label. High-level coverage can look complete while leaving real execution paths undetected, which is why operational proof matters more than taxonomy alone.
• Score-based detection: Score-based detection combines several weak signals into a weighted threshold so that suspicious behaviour is detected only when the pattern becomes meaningful. It is useful in noisy environments because it reduces dependence on any single event and better reflects how attackers behave across a campaign.
• Permutation testing: Permutation testing is the process of validating a detection rule against multiple variants of the same attack behaviour before deployment. It helps teams find gaps caused by different tooling, execution order, or artefact changes, which is especially important when adversaries can generate many variants quickly.

What's in the full article

INTEZER's full article covers the operational detail this post intentionally leaves for the source:

• Concrete examples of score-based detection logic in SIEM environments and how weighting changes alert quality.
• Permutation testing approaches for validating detection rules before they reach production.
• Closed-loop workflows that connect automated triage, investigation, and detection tuning across the SOC.
• Coverage benchmark interpretations for teams comparing immature, strong, and top-tier detection programmes.

👉 The full INTEZER post covers score-based logic, permutation testing, and continuous detection tuning in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives security practitioners a practical foundation for linking identity controls to broader detection and response programmes.