What breaks when a workflow engine can execute untrusted code inside the same environment that stores secrets?

Why This Matters for Security Teams

When a workflow engine can run untrusted code in the same runtime that holds secrets, the problem is not just code execution. It becomes secret exposure, workflow tampering, and unauthorized downstream action in one step. That is why NHI boundaries matter: the identity that executes automation must never share a trust zone with the credentials it can use. OWASP’s OWASP Non-Human Identity Top 10 treats credential handling and execution trust as separate failure domains.

This is also where real-world loss accelerates. NHIMG’s The State of Secrets in AppSec reports that organizations spend an average of 32.4% of security budgets on secrets management and code security, yet the average time to remediate a leaked secret is still 27 days. That gap is exactly what attackers exploit when a workflow system can both execute code and read secrets from the same environment. In practice, many security teams discover this only after a workflow runner has already been used to read tokens, alter jobs, and trigger legitimate-looking actions downstream.

How It Works in Practice

The failure starts with co-location. If the workflow engine, job runner, plugin system, or expression evaluator shares a process, container, pod, or mounted filesystem with secret material, any code path that reaches execution can often reach the secrets too. That includes environment variables, mounted files, in-memory tokens, metadata service credentials, and cached session material. Once the attacker can execute inside that boundary, the workflow engine may continue to issue calls that appear authorized because they are made by a trusted automation account.

The safer pattern is to separate concerns tightly:

• Run untrusted workflow logic in an isolated execution tier with no direct access to secret stores.
• Issue short-lived, task-scoped credentials only after policy checks at runtime.
• Prefer workload identity and token exchange over static API keys inside runners.
• Keep secrets in a dedicated vault or broker, with explicit retrieval and audit logging.
• Apply least privilege to the workflow identity, not just the human who created it.

For agentic or highly dynamic automation, this aligns with NIST SP 800-207 Zero Trust Architecture and the broader direction of runtime policy enforcement. Current guidance suggests that pre-granting broad access to a runner is too risky when code paths are not fully deterministic. NHIMG’s CI/CD pipeline exploitation case study shows how a compromised automation path can become a control-plane event rather than a single-job issue. These controls tend to break down when the runner needs persistent network reach, shared build caches, or plugin extensibility because each of those expands the blast radius beyond the original execution unit.

Common Variations and Edge Cases

Tighter isolation often increases operational overhead, requiring teams to balance speed and developer convenience against blast-radius reduction. That tradeoff is real, especially in systems that depend on reusable runners, shared secrets caches, or self-hosted automation nodes. Best practice is evolving, but the direction is clear: move from long-lived, environment-wide access toward per-task credentials and context-aware authorization.

One common edge case is plugin-driven automation. If third-party or user-supplied extensions execute inside the same trust boundary as secrets, the workflow engine can inherit the extension’s risk profile. Another is multi-step orchestration where a benign first step writes a malicious payload that a later step executes with higher privilege. In those cases, separating execution from secret retrieval is necessary but not always sufficient; policy must also inspect what the workflow is trying to do at request time, not just what role it has on paper.

NHIMG’s Guide to the Secret Sprawl Challenge is useful context here, because the more places a secret can live, the harder it is to keep untrusted code away from it. The operational rule is simple: if code can run, assume it can inspect, exfiltrate, or reuse anything in the same trust zone unless the architecture proves otherwise. That assumption is especially important for shared runners, legacy orchestration, and environments that mix build logic with privileged automation.

Related resources from NHI Mgmt Group

• Why do secrets create disproportionate risk in NHI environments?
• What is the difference between code scanning and runtime identity monitoring?
• How should teams reduce the risk from exposed NHI secrets?
• How does OneDrive auto-sync create secrets exposure in SharePoint?