Expression injection occurs when attacker-controlled input is interpreted as executable logic inside an application or workflow engine. In automation platforms, that can let a malicious editor break out of the intended data-processing context and reach system functions, command execution, or sensitive environment access.
Expanded Definition
Expression injection is a logic abuse issue, not just a validation flaw. It happens when untrusted input is evaluated as part of an expression language, template, rules engine, or workflow condition, allowing the attacker to influence control flow rather than only data values. In NHI and agentic systems, that distinction matters because the injected expression may be executed with the privileges of a service account, automation runner, or AI agent. Guidance varies across vendors on how broadly the term should be applied, but the core risk is consistent: attacker-controlled text becomes executable semantics. In mature governance programs, expression handling is treated alongside input sanitisation, policy enforcement, and privilege containment, with reference architectures such as the NIST Cybersecurity Framework 2.0 used to anchor detection and response expectations. The most common misapplication is assuming a field is "only configuration," which occurs when editors can submit content that the runtime later interprets as code.
Examples and Use Cases
Implementing expression handling rigorously often introduces friction for legitimate automation authors, requiring organisations to balance developer flexibility against the cost of tighter parsing, allowlisting, and review.
- A workflow engine lets an operator enter conditional logic for routing approvals, but a crafted value can reference hidden variables and alter the approval path.
- A CI/CD pipeline evaluates a build-time expression from repository content, creating a path from a pull request comment to secret exposure or command execution.
- An AI agent or assistant tool interprets user-supplied text as part of a template, and the injected expression causes the agent to call functions outside the intended task boundary.
- A policy-as-code rule accepts untrusted parameters, and the expression engine resolves system context that should never be reachable from a tenant-facing input.
- GitHub-adjacent automation and other NHI-heavy workflows often fail when long-lived credentials are reused across parser boundaries, a pattern discussed in Ultimate Guide to NHIs and reflected in the way expression misuse can expand blast radius.
When organisations need a standards lens for hardening these paths, NIST Cybersecurity Framework 2.0 is useful for mapping control expectations around secure configuration and monitoring.
Why It Matters in NHI Security
Expression injection is especially dangerous in NHI environments because machines execute quickly, at scale, and often with standing privileges that humans would never be granted. Once an attacker can alter logic rather than just data, they may reach secrets, token minting paths, webhook handlers, deployment actions, or privileged APIs. That turns a single malformed input into an access-path problem across automation estates. NHIMG research shows that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which helps explain why logic injection into secret-bearing workflows is so consequential. The same governance pressure appears in broader NHI hygiene issues: NHIs outnumber human identities by 25x to 50x, and 97% carry excessive privileges, so an injected expression can become a rapid privilege amplifier when controls are weak. The issue also intersects with secret placement patterns described in the Ultimate Guide to NHIs, especially where automation reads secrets from code or CI/CD variables rather than a hardened vault. Organisations typically encounter this consequence only after a workflow has already exfiltrated secrets or executed an unexpected action, at which point expression handling becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers insecure secret handling and injected trust in machine identities. |
| NIST CSF 2.0 | PR.DS | Expression injection can expose data by abusing software that processes sensitive inputs. |
| OWASP Agentic AI Top 10 | LLM-03 | Agentic tool use can be subverted when prompts or fields become executable logic. |
Treat any expression-capable input path as untrusted and isolate it from secret-bearing NHI workflows.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
