Known-Bad Detection

Known-bad detection is a control model that blocks threats by matching them to previously catalogued indicators such as domains, hashes, or phrases. It works well when attackers reuse infrastructure or content, but it is fragile when the attack is generated fresh each time and no stable fingerprint survives.

Expanded Definition

Known-bad detection is a pattern-matching control that blocks activity by comparing it to previously observed indicators, such as malicious domains, file hashes, IP addresses, command strings, or reused prompts. In NHI and agentic environments, it is often used as a fast first-pass filter for repeat abuse, especially where infrastructure, payloads, or tool invocation patterns recur. The approach aligns with the broader detection logic described in the NIST Cybersecurity Framework 2.0, but it is not a substitute for identity-aware verification or behavioural controls.

Definitions vary across vendors when the term is applied to agents, because some products treat any blocklist as known-bad detection while others reserve it for threat-intelligence backed matching. For NHI governance, the useful distinction is operational: known-bad detection is retrospective and exact-match oriented, while adaptive adversaries can mutate quickly enough to bypass it. That makes it strongest as one layer in a broader defence model, not as the primary decision point for privileged service accounts, API keys, or AI agent tool access. The most common misapplication is using blocklists as the main control for fresh, generated attacks, which occurs when teams assume a new payload will still match an old fingerprint.

Examples and Use Cases

Implementing known-bad detection rigorously often introduces coverage gaps, requiring organisations to weigh fast blocking of repeat threats against the risk of missing novel, one-off attacks.

• Blocking outbound calls from an AI agent to a domain previously tied to credential theft, using a threat intel feed as the match source.
• Rejecting a service account login when the token hash appears on a known compromise list, then forcing rotation through the NHI Lifecycle Management Guide.
• Filtering prompt content that reuses a catalogued jailbreak phrase, while accepting that a reworded attack may bypass the rule.
• Detecting repeated abuse of a CI/CD secret by matching destination IPs and command patterns documented in the Top 10 NHI Issues.
• Using hash-based malware blocking alongside behaviour analytics, because the same malicious binary may be recompiled and evade a static signature.

In practice, the control works best where replay is common and time-to-block matters more than perfect novelty detection. It is a familiar technique in email security, endpoint protection, and threat-intelligence pipelines, but in NHI environments it must be paired with inventory, rotation, and least privilege.

Why It Matters in NHI Security

Known-bad detection matters because NHI compromise often begins with something reusable: a leaked API key, a stolen token, a copied payload, or an already documented attacker domain. NHI Mgmt Group reports that 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, which means a blocklist can provide meaningful containment when the same artefact reappears. But its value drops sharply when the attacker regenerates content, rotates infrastructure, or uses an AI agent to vary every request.

That is why known-bad detection should be treated as a compensating control, not a governance strategy. It can reduce noise, shorten response time, and prevent obvious repeats, but it cannot prove identity, intent, or authorization for an agent. In NHI programs, the blind spot is especially dangerous when service accounts, secrets, and automation are assumed safe simply because prior indicators have not fired. Organisational resilience improves when detection is paired with secret rotation, scope reduction, and continuous validation of non-human access paths. Organisations typically encounter the limits of known-bad detection only after a fresh campaign bypasses the blocklist, at which point the control becomes operationally unavoidable to revisit.

Related resources from NHI Mgmt Group

• What breaks when fraud detection relies only on known-bad indicators?
• When should organizations prioritize the detection of shadow AI agents?
• What are effective practices for operationalizing NHI threat detection?
• How do organisations reduce false positives in secret detection pipelines?