Blocklists fail when attackers route execution through a function or opcode that is not yet listed, or when harmless-looking wrappers resolve to dangerous behavior at runtime. In practice, this creates bypasses that allow code execution to pass as safe. Structural analysis is stronger because it evaluates how the model will behave, not just whether a known bad name appears.
Why Blocklists Miss the Real Failure Mode
Blocklists are useful for spotting known bad names, but they are brittle when the scanner is supposed to judge whether a model can execute unsafe behaviour through alternative paths. A structurally equivalent wrapper, alias, helper function, or runtime resolution step can preserve the same outcome while avoiding the blocked token. That means the control is measuring vocabulary, not effect, and the gap matters most in environments where execution can be assembled dynamically. NIST’s control families on configuration and system integrity help explain why name-based filtering alone is not a reliable assurance signal: the check has to be tied to the behaviour being allowed, not the label attached to it. NIST SP 800-53 Rev 5 Security and Privacy Controls In practice, many security teams discover the bypass only after a harmless-looking wrapper has already been accepted by the scanner.
How Structural Analysis Changes the Decision
Structural analysis asks what the model will actually do, rather than whether a banned term appears in the prompt, policy, or generated code. That usually means checking the execution chain, data flow, control flow, and any indirection that changes meaning at runtime. For model scanners, the practical question is whether the scanned artefact still reaches a prohibited capability once aliases, imports, tool calls, or generated instructions are resolved. A blocklist can reject obvious high-risk names, but it cannot keep pace with renamed functions, polymorphic wrappers, or new attack surface introduced by orchestration layers.
In practice, stronger analysis combines syntax-level checks with semantic inspection. For example, a scanner may need to assess whether a script invokes file access, shell execution, network retrieval, or tool invocation even when those actions are hidden behind helper abstractions. The same logic applies to agentic or LLM-integrated systems: a model output that appears benign may become unsafe once it is passed into an executor, plugin, or workflow engine. The scanner therefore needs to trace the path from input to effect, not just match terms in isolation.
- Check resolved behaviour, not just static names.
- Inspect wrapper functions, aliases, and indirection layers.
- Evaluate runtime effects where generated content is later executed.
- Treat new helpers as risk-bearing until their behaviour is verified.
This guidance breaks down when the scanner cannot observe the execution context or when runtime resolution happens in a separate system the scanner never sees.
Where Blocklists Still Help, and Where They Do Not
Tighter filtering often reduces obvious misuse, but it also increases maintenance overhead, requiring organisations to balance simple enforcement against constant rule updates. Blocklists are still useful as a first-pass tripwire for known abusive primitives, especially when the threat set is narrow and stable. The tradeoff is that they are poor at generalising across renamed constructs, transformed payloads, and layered abstractions. Where there is no consensus, the practical position is clear: blocklists are a containment measure, not an assurance measure.
They are most effective when the scanner’s job is to catch repeat offenders in a controlled environment, or when paired with a second control that examines semantics. They are weakest when attackers can change the surface form without changing the underlying action. That includes generated code, model-assisted orchestration, and systems where a safe-looking phrase is only resolved into dangerous behaviour after deployment. Structural analysis is the better default whenever the question is “what capability is being enabled?” rather than “is this exact bad string present?”
For that reason, the real edge case is not whether a blocklist works at all, but whether the organisation has wrongly promoted it into the role of primary safety decision. When that happens, bypasses become predictable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 — Baselines for Configuration | Scanner controls must validate behaviour against a secure baseline, not just blocked terms. |
| Recommendation — Assess scanner decisions against expected safe behaviour, not keyword lists alone. | ||
| CIS Controls v8 | 16 — Application Software Security | Structural analysis addresses unsafe application behaviour that simple blocklists miss. |
| Recommendation — Apply application security testing that evaluates code paths and runtime effects. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Blocklist bypass often enables hidden execution through interpreters or wrappers. |
| Recommendation — Map scanner bypasses to execution paths and hunt for interpreter-abuse patterns. | ||
| OWASP Agentic AI Top 10 | A2 — Tool Invocation Security | Agentic systems can turn benign-looking output into unsafe tool execution at runtime. |
| Recommendation — Inspect tool-call paths and validate the resolved action before allowing execution. | ||
Practitioner Guidance
What to prioritise: Treat the scanner as a behavioural gate, not a keyword gate. The first thing to validate is whether the inspection step can follow aliases, wrappers, and runtime resolution to the actual effect being enabled.
What to verify: Confirm that a blocked term and a blocked capability are not being conflated. If the control only proves that a name was absent, it is not strong enough to approve execution, tool use, or generated code paths.
Decision rule: If the model output can reach an executor, plugin, interpreter, or workflow engine, require structural or semantic analysis before trust is granted. If no such execution path exists, blocklists can remain a supporting control rather than the deciding one.
Common mistake: Teams often tune blocklists until they look comprehensive and then assume coverage has improved. In practice, that usually just raises the number of known phrases that are caught while leaving the underlying mechanism unchanged.
Practitioner takeaway: The more a system can transform, resolve, or execute content at runtime, the less value a blocklist has as a primary safety control, because the decisive question is behavioural equivalence, not lexical match.
Related resources from NHI Mgmt Group
- What breaks when security teams rely on model output instead of verifying the authorization event?
- What breaks when MCP servers rely on custom middleware instead of a standard interceptor model?
- What breaks when teams rely on symptom-level bug reports instead of root-cause analysis for AI workflows?
- What breaks when organisations rely on direct model access instead of a gateway?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
