They often assume the parser is the main control point and overlook the code-generation step. In reality, the dangerous moment is when a library turns evaluated content into source code and feeds it to the runtime compiler. That optimisation changes the trust model and should be reviewed like any other execution boundary.
Why This Matters for Security Teams
Expression evaluation looks harmless when teams focus on the parser, tokenizer, or input filters. The real security boundary is often the moment a library optimises evaluated content into executable source and hands it to the runtime compiler. That is where trust changes, and where a data problem becomes an execution problem. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference point for treating that boundary as a control decision, not just a correctness step.
This mistake shows up most often in systems that use templating, rules engines, policy expressions, or “safe” helper functions that later expand into code paths. Teams assume allowlists on symbols or operators are enough, but generated code can still introduce side effects, scope leakage, or unexpected runtime access. NHI Management Group’s Ultimate Guide to NHIs notes that 30.9% of organisations store long-term credentials directly in code, which is exactly the kind of surrounding condition that turns expression handling into a higher-impact execution path.
In practice, many security teams encounter expression evaluation abuse only after a benign-looking optimisation has already widened the execution boundary.
How It Works in Practice
Secure handling starts with recognising that expression evaluation has two distinct phases: interpretation and execution. Interpretation is where the input is parsed into an abstract syntax tree or similar structure. Execution is where that structure is transformed into code or invoked against a runtime that can reach secrets, files, network calls, or identity context. If the library generates source code, the review must cover the generated artefact, not just the original expression string.
For practitioners, the most useful questions are: what language features can the expression access, what objects are exposed, and what happens when the expression compiles successfully? A library that supports arithmetic only is very different from one that permits method calls, object traversal, or custom resolvers. OWASP guidance on injection risks remains relevant here, but expression evaluation often creates a narrower and more deceptive attack surface because it looks domain-specific rather than code-like.
A practical control set usually includes:
- Predefining a minimal grammar and forbidding runtime code generation unless explicitly justified.
- Restricting the object model, so expressions cannot reach ambient authority such as filesystem, process, or secret stores.
- Running evaluation in a sandbox with no implicit credential access or network egress.
- Reviewing compiler or JIT integration as an execution boundary in threat models and change control.
- Logging both the original expression and the generated artefact when the platform supports it.
For identity-sensitive workloads, NHI Management Group’s Ultimate Guide to NHIs is relevant because expression systems often run inside services that already hold API keys or service account tokens. If that runtime also has broad standing access, a single unsafe evaluation path can become a privilege amplifier. Mapping the surrounding controls to NIST SP 800-53 Rev 5 Security and Privacy Controls helps teams anchor review, logging, and least-privilege expectations to a control framework rather than an ad hoc code review.
These controls tend to break down in plugin-heavy platforms, low-code rule engines, and legacy systems that rely on dynamic compilation because the runtime exposes more authority than the expression language was ever designed to constrain.
Common Variations and Edge Cases
Tighter expression controls often increase developer friction, requiring organisations to balance flexibility against the risk of runtime code generation. That tradeoff is especially visible when business teams want configurable formulas, custom routing logic, or tenant-specific rules without a redeploy.
There is no universal standard for this yet, but current guidance suggests treating “safe expression” libraries as security components only when their execution model is fully documented and tested. If the library can fall back to script engines, reflection, or dynamic compilation, it should be reviewed as potentially code execution capable, even if the intended use case is limited.
Two edge cases deserve attention. First, some platforms evaluate expressions in one trust zone but execute generated code in another, which can bypass expected sandboxing. Second, expression engines embedded in workflow or agentic systems may gain indirect access to secrets through service credentials, making the effective blast radius much larger than the expression itself. For broader governance context, the Ultimate Guide to NHIs is a useful reference for understanding how excessive privileges and weak rotation magnify adjacent application risks.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and 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-06 | Dynamic evaluation paths can expose service credentials and secrets. |
| OWASP Agentic AI Top 10 | Runtime code generation creates execution risk similar to tool-using AI components. | |
| CSA MAESTRO | MAESTRO emphasises runtime governance for autonomous or dynamic execution flows. | |
| NIST AI RMF | AI RMF helps frame controllability and traceability of dynamic decision logic. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is critical when expression engines run inside privileged services. |
Inventory identities used by expression runtimes and remove standing access wherever possible.
