Who is accountable when untrusted code execution depends on both interpreter controls and host isolation?

Why This Matters for Security Teams

When untrusted code can execute, accountability is not solved by pointing to one layer of defence. Interpreter controls may reduce what the code can do, while host isolation limits blast radius if those controls fail. Security teams often assume that a safe runtime or sandbox shifts responsibility away from the product owner, but that assumption breaks down as soon as the deployment context changes.

The practical issue is that “sandboxed” is not a binary label. It depends on how the interpreter is configured, what interfaces are exposed, how the host enforces containment, and whether the operator preserves those protections in production. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it separates control ownership, system boundaries, and operational safeguards rather than treating security as a single product claim. That distinction matters when a host must compensate for interpreter weaknesses or when the product must constrain inputs and tool access.

In practice, many security teams encounter this only after a sandbox escape, privilege misuse, or unsafe plugin execution has already occurred, rather than through intentional shared accountability.

How It Works in Practice

Accountability should be split according to the control plane each party actually owns. The product team is responsible for defining the execution model, documenting assumptions, limiting exposed APIs, and ensuring the interpreter does not allow broad filesystem, network, or process access by default. The deployer is responsible for the host layer: container or VM isolation, seccomp or equivalent syscall filtering, least-privilege runtime permissions, secret scoping, and monitoring for abnormal process behaviour.

This is easiest to understand as a boundary problem. If the product claims code execution is constrained, then it must specify what is constrained, by whom, and under what conditions. If the deployer relies on that claim, the deployer still needs independent verification that the runtime environment actually enforces it. Guidance from the NIST SP 800-53 Rev 5 Security and Privacy Controls supports this layered approach: control inheritance is valid only when the inherited control is real, documented, and continuously maintained.

• Product teams should document the attack surface, especially file, network, and command execution capabilities.
• Deployers should isolate workloads with containers, microVMs, or other hardened boundaries, not just application flags.
• Both parties should define what happens when the interpreter fails closed, fails open, or is bypassed entirely.
• Logging should distinguish interpreter decisions from host enforcement so incidents can be attributed correctly.

This guidance tends to break down in shared platform environments where runtime policy is inherited from templates but not validated against the actual host kernel, container runtime, or orchestration settings.

Common Variations and Edge Cases

Tighter isolation often increases operational overhead, requiring organisations to balance developer convenience against containment strength. That tradeoff becomes more visible in AI-enabled applications, plugin systems, and code execution services where the interpreter is intentionally flexible but the host is expected to absorb the risk. Current guidance suggests that the more dynamic the execution model, the less reliable it is to rely on product claims alone.

There is no universal standard for this yet, especially where agentic tools, user-supplied scripts, and multi-tenant execution coexist. In those cases, accountability often extends beyond a single team: the product owner must describe the trust boundary, the platform team must enforce it, and the security team must verify that sandbox assumptions still hold after updates, patches, and orchestration changes. For runtime isolation patterns, the NIST Zero Trust Architecture view is helpful because it treats trust as continuously evaluated rather than implied by deployment location.

Edge cases also appear when third-party libraries, code interpreters, or automation agents are embedded into a larger service. In those environments, the safest assumption is that interpreter controls are necessary but not sufficient, and host isolation is compensating control rather than proof of safety.

Related resources from NHI Mgmt Group

• Who is accountable when a model loader turns untrusted input into code execution?
• Who is accountable when a workflow flaw exposes session secrets and code execution?
• Who is accountable when an exposed backup service is used for remote code execution?
• Who is accountable when a workflow platform vulnerability leads to code execution?