LLM Descriptive Patterns

Expanded Definition

LLM Descriptive Patterns are a way to express malicious behaviour in language that can be matched against code structure, not just exact strings or known samples. The point is to identify intent that survives reimplementation, where the same abuse pattern may appear in different syntax, packaging, or naming. That makes the term useful in security research, malware analysis, and detection engineering.

The boundary matters: this is not the same as a simple signature, nor is it a full behavioural model of every runtime action. It sits between brittle indicators and broader analysis by focusing on descriptive traits that remain stable across variants. In practice, analysts use it when they need to recognise a family of malicious techniques without waiting for a perfect hash, filename, or exact source fragment.

For a broader governance lens on AI systems that generate or transform code and text, NIST AI 600-1 Generative AI Profile gives useful context on managing model risk, although LLM descriptive patterns are a detection concept rather than an AI management control.

Examples and Use Cases

In practice, LLM descriptive patterns appear where defenders need to spot harmful logic that has been rephrased or slightly refactored.

• Detection engineering teams translate a plain-language abuse description into code-matching rules that flag equivalent malicious intent across multiple samples.
• Malware researchers use the approach to group related payloads even when imports, variable names, or formatting have changed.
• Threat hunting teams apply descriptive patterns to identify suspicious code fragments that share structure with known hostile tooling but do not reuse the same strings.
• Security review workflows use the method to compare emerging code against a pattern of unsafe behaviour rather than a single known file.

The main tradeoff is precision versus coverage. Broader descriptive patterns catch more variants, but they can also match benign code that uses similar structures for legitimate purposes. Narrower patterns reduce false positives, but they may miss rewritten or obfuscated implementations.

Where the subject extends into adversarial AI behaviour, the MITRE ATLAS adversarial AI threat matrix is a useful companion reference for understanding attacker methods around AI-enabled systems.

Security Implications

The security value of LLM descriptive patterns is that they improve resilience against basic evasion. Attackers often change filenames, comments, formatting, API wrappers, or surrounding code to avoid exact-match detection. A descriptive pattern can still recognise the underlying malicious structure when the implementation has been rewritten.

The failure mode is overconfidence in brittle indicators. If a team depends only on static signatures, variants that preserve intent but alter presentation may pass through detection, analysis, or triage. That can delay containment, weaken malware clustering, and increase the time needed to understand whether a new sample is part of an existing campaign or an unrelated tool.

There is also an analytic risk: if the pattern is too loose, benign software can be flagged because it shares a surface-level structure with hostile code. Practitioners should treat this as a recognition aid, not proof of maliciousness by itself. The useful signal is pattern similarity plus context, not pattern similarity alone.

For AI-assisted detection and code-analysis programmes, this is one reason organisations increasingly pair descriptive patterning with human review and additional telemetry rather than relying on one layer of matching.

Domain and Governance Relevance

LLM descriptive patterns matter most in detection engineering and malware research, but they also touch AI governance when LLMs are used to generate, refactor, summarise, or triage code. In that setting, the key question is whether the model is helping analysts preserve the meaning of hostile logic or accidentally normalising it into something that looks safe.

For identity and non-human identity contexts, the connection is indirect. The term does not primarily describe machine identity, privilege, or credential lifecycle, but it can surface when descriptive patterns are used to recognise code that abuses tokens, secrets, or service accounts inside automated workflows. That makes it relevant to governance of tool-using agents only when their code or outputs are part of the detection problem.

Where teams operate agentic or code-generating systems, the practical governance issue is consistency: the same malicious intent may appear in many implementation forms, so review criteria need to focus on behaviour and structure rather than literal text. The concept is therefore useful anywhere defenders need to preserve semantic detection across rapidly changing code.

Related resources from NHI Mgmt Group

• What are the signs that an LLM bias test is missing important discrimination patterns?
• What are the different Agentic AI interaction patterns and their NHI implications?
• How should security teams use LLM-based identity risk scoring in production?
• Why do approve-all access patterns create identity risk?