Why do formula engines create hidden NHI and secrets risk?

Why This Matters for Security Teams

Formula engines look harmless because they are often framed as business logic, not an execution surface. In practice, they run inside an application process that already holds non-human identity privileges, so any unsafe formula evaluation can turn a calculation feature into a credential-abuse path. That is why the issue is not limited to code injection. It becomes a secrets problem, a lateral-movement problem, and a blast-radius problem.

Security teams often miss the distinction between user input and runtime authority. A formula that can reach environment variables, cloud metadata, database clients, or embedded tokens can expose everything the service account can touch. NHIMG research on the Guide to the Secret Sprawl Challenge shows how widely secrets tend to spread once they are available inside execution paths, and OWASP’s Non-Human Identity Top 10 treats overprivileged machine identities as a primary risk factor, not a side effect.

The practical lesson is simple: if a formula engine can evaluate attacker-controlled expressions in the same trust zone as NHI credentials, the engine inherits the full security posture of that identity. In practice, many security teams encounter this only after a formula parser has already been used to exfiltrate tokens or reach systems that were never meant to be user-accessible.

How It Works in Practice

The dangerous pattern is usually a server-side formula evaluator that accepts expressions for routing, transformation, validation, pricing, or report generation. If that evaluator has access to secrets, object handles, reflection, dynamic imports, file access, or shell-like functions, the formula layer becomes an execution bridge. The attacker does not need a traditional remote shell if the formula engine can read configuration, call internal APIs, or invoke privileged helpers.

The control objective is to separate expression evaluation from privileged runtime authority. Strong designs treat formulas as data, not code. That means sandboxing the evaluator, removing direct access to process memory and secrets stores, and ensuring the application never loads long-lived credentials into the same context that parses untrusted input. Current guidance suggests that ephemeral, task-scoped credentials reduce exposure far better than static service secrets when dynamic computation is unavoidable.

For agentic or highly dynamic systems, the best-practice direction is toward workload identity and runtime authorization. A formula worker should authenticate as a narrowly scoped workload, receive only the minimum secrets needed for that task, and revoke them immediately after completion. NIST’s Cybersecurity Framework 2.0 supports this least-privilege posture, while NHIMG’s 52 NHI Breaches Analysis shows how quickly machine identity exposure becomes an enterprise incident when controls are weak.

• Use a hardened expression language with no filesystem, network, or reflection access.
• Store secrets outside the formula runtime and inject them only when the business task requires them.
• Prefer short-lived tokens over static credentials, with automatic revocation on task completion.
• Log formula evaluation, secret access, and unusual expansion of permissions as separate events.

These controls tend to break down in legacy monoliths where the evaluator, secrets client, and application service account all share the same process and memory space.

Common Variations and Edge Cases

Tighter formula controls often increase engineering overhead, requiring organisations to balance developer flexibility against credential containment. That tradeoff is especially visible in finance, ERP, workflow automation, and low-code platforms, where formula engines are used for legitimate business logic and cannot simply be removed.

There is no universal standard for this yet, but current guidance suggests treating any formula engine that can read variables, call functions, or access helper libraries as a privileged subsystem. In lower-risk environments, a read-only evaluator may be acceptable if it cannot reach secrets or internal services. In higher-risk environments, formulas that affect payments, approvals, or provisioning should be reviewed like code, with explicit allowlists and request-time authorization checks.

Edge cases also include multi-tenant SaaS, where one tenant’s formula payload may be able to influence shared runtime state, and CI/CD-style automation, where a formula step inherits deployment tokens. NHIMG’s CI/CD pipeline exploitation case study is a useful analogue because the same failure mode appears: a small amount of untrusted input meets a highly privileged machine identity. In those cases, secret segregation matters more than parser correctness alone.

Related resources from NHI Mgmt Group

• Why do feature toggles create hidden risk in observability platforms?
• Why do mobile apps create account takeover risk when they store secrets on device?
• Why do access gateways create outsized risk in identity and NHI programmes?
• Why do non-human identities create more risk than many human accounts?