Runtime command generation

A technique where malicious instructions are created at execution time rather than hardcoded into the payload. This makes the malware less predictable because the actual commands can change from run to run, reducing the reliability of signature-based detection and static command matching.

Expanded Definition

Runtime command generation is the practice of assembling or mutating commands during execution rather than embedding the full command sequence in a static payload. In NHI security, that matters because service accounts, API-driven automation, and agentic workflows can all become execution paths for dynamically built actions. The technique is not inherently malicious, but it is frequently associated with evasive malware, loader stubs, and post-compromise tooling that tries to avoid static detection. Guidance across vendors is still evolving on how to classify runtime command generation when it appears in legitimate automation versus hostile tradecraft. For defenders, the key distinction is whether command construction is deterministic, governed, and observable, or whether it is assembled from external input, environment data, or decoded fragments at run time. That distinction aligns with the control objectives in the NIST Cybersecurity Framework 2.0, especially detection and response expectations around anomalous execution. The most common misapplication is treating all dynamic command assembly as benign automation, which occurs when defenders only review source code and ignore runtime behavior.

Examples and Use Cases

Implementing controls against runtime command generation rigorously often introduces monitoring and tuning overhead, requiring organisations to weigh visibility gains against operational noise and false positives.

• Malware concatenates fragments from system variables, registry values, or downloaded strings to build a command only at launch time, reducing the value of static indicators.
• An AI agent with tool access constructs shell commands from user prompts and context objects, which can be legitimate but needs explicit allowlisting, logging, and validation.
• A compromise in a CI/CD runner causes a job script to fetch and assemble secondary commands from an attacker-controlled endpoint, bypassing simple signature checks.
• A defense team compares runtime command traces with governance baselines from the Ultimate Guide to NHIs to spot service accounts that execute unexpected task chains.
• Security engineers map the behavior to NIST Cybersecurity Framework 2.0 detection practices, using command telemetry to identify execution anomalies that static scanning would miss.

Why It Matters in NHI Security

Runtime command generation is dangerous in NHI environments because non-human identities often have broad tool access, long-lived secrets, and direct pathways into automation platforms. When commands are generated on the fly, malicious activity can blend into normal orchestration unless teams inspect execution context, not just code. NHI Mgmt Group research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which gives attackers multiple inputs to influence runtime behavior. The same Ultimate Guide to NHIs also reports that 97% of NHIs carry excessive privileges, making any successful command mutation far more consequential. In practice, defenders need command allowlisting, secret isolation, execution logging, and prompt or input validation for agents that can invoke tools. This term becomes operationally unavoidable after an incident reveals that a service account, script, or agent executed a command that no static review ever contained.

Related resources from NHI Mgmt Group

• Runtime Application Self-Protection
• Runtime Environment
• What is the difference between approving a command and approving its runtime context?
• What is the difference between runtime protection and NHI lifecycle management?