A pattern where text is interpreted as executable code while the application is running. It increases risk because any failure in upstream validation can become immediate execution, which is why safer designs use structured parsing and explicit action handling instead.
Expanded Definition
Runtime code evaluation is broader than simple input handling problems because the application turns text into executable instructions while it is already running. In secure engineering terms, that means the boundary between data and behaviour has been removed, so a malformed string, attacker-controlled payload, or unsafe template can change program flow immediately. This is why the concept sits close to injection risk, but it is not identical to every injection class. Some implementations are explicit and narrow, while others are implicit, hidden in helper functions, dynamic templates, or plugin logic. Definitions vary across vendors and languages, but the security concern is consistent: runtime evaluation creates a direct path from untrusted input to execution. NIST Cybersecurity Framework 2.0 is useful here because it frames the need to identify, protect, detect, and respond to software weaknesses that can become exploitable at runtime, especially when validation is weak or absent.
The most common misapplication is assuming runtime evaluation is safe because the code path is “internal,” which occurs when attacker influence reaches the evaluated text through logs, configuration, prompts, or chained parsing.
Examples and Use Cases
Implementing runtime code evaluation rigorously often introduces design constraints, requiring organisations to weigh developer flexibility against the cost of tighter parsing, stronger review, and reduced dynamic behaviour.
- A scripting feature lets administrators enter expressions that are interpreted during request handling, creating execution risk if the input is not strictly constrained.
- A template engine builds commands or queries from user-supplied fields instead of from structured parameters, making downstream execution dependent on string content.
- An automation tool evaluates configuration fragments at runtime, so a compromised config source can alter system behaviour without code changes.
- An AI-enabled workflow converts generated text directly into executable actions, which is especially dangerous when the model output is not treated as untrusted input and validated first. Guidance from OWASP’s LLM guidance is relevant here because prompt-to-action chains can blur the data-execution boundary.
- A legacy application uses dynamic expression evaluation for business rules, and developers keep it because it is convenient, even though safer alternatives such as whitelisting and structured policy engines would be more predictable.
Why It Matters for Security Teams
Security teams care about runtime code evaluation because it collapses multiple control failures into a single event: weak validation, unsafe abstraction, and excessive execution privilege. Once text is allowed to become code, ordinary input review is no longer enough, and teams need to examine the full path from source to sink, including configuration, automation, and any agentic or AI-assisted component that can generate executable output. This is particularly important in modern applications that combine prompts, plugins, and API calls, because a model or agent may produce seemingly harmless text that becomes operationally dangerous when interpreted by a runtime. The right response is usually to replace evaluation with structured parsing, constrain allowed actions, and ensure that execution authority is separated from untrusted content. NIST’s AI and cyber guidance also supports the principle that systems should be designed to limit unsafe transformation of input into action, especially where software behaviour is dynamically controlled. Teams often discover the real impact only after an unexpected command runs, a policy bypass occurs, or a prompt injection chain reaches execution, at which point runtime code evaluation becomes operationally unavoidable to address.
For adjacent guidance on defensive prioritisation, the NIST Cybersecurity Framework 2.0 provides a useful governance lens for identifying and reducing exploitable software behaviour.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Security includes managing software flaws and unsafe runtime behavior. |
| OWASP Agentic AI Top 10 | Agentic AI guidance warns against turning untrusted model output into actions. | |
| NIST AI RMF | AI RMF addresses managing AI system risks that can lead to unsafe code execution. | |
| NIST AI 600-1 | The GenAI profile stresses controls for unsafe outputs and downstream misuse. | |
| OWASP Non-Human Identity Top 10 | NHI guidance is relevant when runtime evaluation uses credentials, tokens, or automation identities. |
Limit secret exposure and execution authority when automated identities can trigger runtime actions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
