A loader that starts in one runtime, such as Python, but pulls in and executes a payload in another runtime, such as JavaScript under Bun. This complicates static analysis because the visible package language does not fully describe the behaviour that occurs at execution time.
Expanded Definition
A cross-runtime loader is a package or bootstrap mechanism that begins execution in one runtime and then loads code for a different runtime at execution time. In NHI and agentic software chains, this matters because the package name, manifest, and repository language can make the component look ordinary while the real execution path is hidden until runtime.
Definitions vary across vendors, but the security concern is consistent: analysis tools that only inspect the declared language or top-level entry point can miss the secondary interpreter, embedded script, or runtime bridge that actually performs privileged actions. That makes the term especially relevant in mixed-language build pipelines, polyglot applications, and agent tooling that invokes local interpreters or browser-like runtimes. For broader context on how identity and execution risks accumulate across service components, see Ultimate Guide to NHIs and the control lens in NIST Cybersecurity Framework 2.0.
The most common misapplication is treating a cross-runtime loader as a harmless packaging quirk, which occurs when reviewers assume the declared language fully captures execution behaviour.
Examples and Use Cases
Implementing detection for cross-runtime loaders rigorously often introduces more build and inspection overhead, requiring organisations to weigh visibility into hidden execution paths against slower dependency review and more false positives.
- A Python package installs cleanly, but its startup script launches Bun to run JavaScript that fetches configuration and executes privileged tooling.
- A Node package embeds a Python interpreter and uses it to process secrets or automate cloud actions outside the expected JavaScript dependency graph.
- A CI helper appears to be a standard library wrapper, yet it pulls code from another runtime at install or first run, bypassing static language checks.
- An NHI-focused agent toolkit loads a secondary runtime to access local files, tokens, or APIs after the primary process has already passed review.
- Supply chain triage uses runtime-aware scanning to trace the real entry point and compare it against package metadata, source trees, and execution traces. NHIMG guidance in Ultimate Guide to NHIs is useful when reviewing whether a package’s declared purpose matches its actual access pattern.
Teams often pair this with runtime policy checks described by NIST Cybersecurity Framework 2.0, especially when execution crosses trust boundaries or touches production credentials.
Why It Matters in NHI Security
Cross-runtime loaders are a supply chain blind spot because they can disguise high-risk behaviour behind a benign-looking package language. That creates a direct governance problem for service accounts, API keys, and automation tokens, since the loader may execute with inherited privileges that were never intended for the secondary runtime. NHIMG research shows that 30.9% of organisations store long-term credentials directly in code, which makes hidden execution paths especially dangerous when the code path is not obvious at review time.
Security teams should treat these loaders as a signal to inspect runtime handoffs, secret access, and provenance of nested interpreters. The issue is not just malware concealment; it is also unauthorised tool use by otherwise approved automation. The operational question is whether the secondary runtime can inherit identity context, access secrets, or call external services without an explicit approval boundary. That is why runtime-aware governance and least-privilege enforcement must be aligned with Ultimate Guide to NHIs and the control expectations in NIST Cybersecurity Framework 2.0.
Organisations typically encounter the impact only after a dependency is flagged during an incident review, at which point cross-runtime loading 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, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Cross-runtime loaders obscure true execution paths and can hide NHI abuse behind package metadata. |
| OWASP Agentic AI Top 10 | AGENT-04 | Agent toolchains may invoke secondary runtimes that expand execution authority beyond review scope. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access must extend to hidden runtime transitions and inherited credentials. |
| NIST Zero Trust (SP 800-207) | SC-7 | Runtime-to-runtime handoffs create trust boundaries that zero trust should treat as untrusted by default. |
| NIST AI RMF | Cross-runtime loaders can alter model or agent behaviour in ways that require risk governance. |
Inspect package runtime handoffs and verify the actual interpreter chain before approving execution.
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
