Choose stronger isolation when untrusted code can originate from users, plugins, templates, or any path that might later become externally reachable. Sanitisation may still help, but it should not be the only barrier. Once the application could face arbitrary input, the containment boundary must sit outside the application process.
Why isolation becomes the right boundary once input can be arbitrary
Sanitisation is a transformation control, not a trust boundary. It can reduce risk when input is well understood and the remaining failure modes are narrow, but it is fragile when the application accepts content from users, plugins, templates, or other sources that may eventually become externally reachable. At that point, the safer decision is to assume the input can be hostile and move execution into a boundary that can contain damage.
That matters because sanitisation often fails in edge cases: an escaping gap, a parser mismatch, a new template feature, or a downstream component that interprets the same data differently. Containerised or isolate-based execution reduces the blast radius when those assumptions break, because the code runs inside a constrained runtime rather than inside the main application process.
What stronger execution containment changes in practice
Containerised and isolate-based execution are most useful when the code being run does not need full application trust. They let you separate the untrusted workload from sensitive data, privileged services, and long-lived process state. That separation becomes more important when the code path is reused across tenants, inputs, or plugins, because a single sanitisation mistake can otherwise become a direct path into the host application.
In practical terms, containment is about limiting what the code can touch, not just what it can receive. A good boundary constrains filesystem access, network reachability, environment variables, credentials, and process privileges. If the untrusted code only needs a narrow interface, keep the interface narrow and make the surrounding execution environment disposable or heavily restricted.
For container-specific implementation guidance, NIST SP 800-190 Container Security remains a useful reference point for image, runtime, and orchestrator risk. The same logic also applies when you are deciding whether a plugin, preview renderer, or code runner belongs in-process at all.
When sanitisation is enough, and when it is not
Sanitisation can be appropriate when the input is tightly constrained, the parser is stable, the output context is known, and the damage from failure is low. Examples include formatting helpers, simple markup filters, or validation steps that only pre-process data before a separate trusted component makes the security decision.
It is not enough when the input can influence code execution, data access, or privileged side effects. Once the application could face arbitrary input or derived content from an external source, sanitisation becomes one layer in a defence-in-depth model, not the final barrier. If a later parser, renderer, interpreter, or sandbox escape would expose the application itself, the safer choice is isolation first and sanitisation second.
That is especially true for template systems, extension ecosystems, and AI-adjacent tool runtimes, where small changes in input shape can change execution behaviour. If you cannot confidently prove that all dangerous interpretations are removed, do not rely on text cleanup alone.
Risk and Threat Considerations
Sanitisation failures tend to be high impact because they usually appear as a trust-boundary mistake, not a harmless formatting issue. The risk is amplified when untrusted content can reach renderers, interpreters, package hooks, or plugin code, because the same bug can move from content handling into code execution or data exfiltration.
Failure mechanism: An attacker supplies content that survives sanitisation, exploits a parser discrepancy, or triggers a later execution path that was assumed to be safe. If the code runs in-process or with broad host access, the failure can become full application compromise rather than a contained defect.
Impact: The likely consequences are credential exposure, unauthorized file or network access, cross-tenant spillover, and persistence inside the host runtime. Where secrets or internal tokens are available to the application process, the blast radius can extend well beyond the original input channel.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | Isolation is relevant to limiting what untrusted code can access. |
| Recommendation — Restrict untrusted execution to the minimum resources and permissions it needs. | ||
| NIST SP 800-53 Rev 5 | SC-39 — Process Isolation | The question is about separating untrusted execution from the main app process. |
| Recommendation — Use process isolation to confine untrusted code outside the trusted application process. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Choosing containers or isolates depends on hardened runtime and execution configuration. |
| Recommendation — Harden the execution environment so untrusted code cannot expand its reach. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The trade-off between sanitisation and isolation is an architecture decision. |
| Recommendation — Design the trust boundary so sanitisation is not the only control. | ||
Practitioner Guidance
What to prioritise: Treat any path that can execute user-influenced code, templates, or plugins as a containment problem first and a sanitisation problem second. If the code can later become externally reachable, design the execution boundary as if arbitrary input will eventually arrive.
What to verify: Confirm what the untrusted component can read, write, call, inherit, and persist. The key question is not whether input is escaped, but whether a failed escape would still be trapped inside a narrow, disposable runtime with no direct access to secrets or privileged services.
Decision rule: If a single sanitisation error would expose meaningful data, privileged actions, or host compromise, choose containerised or isolate-based execution. Reserve sanitisation-only approaches for low-impact transformations where the downstream interpreter and trust boundary are both tightly controlled.
Practitioner takeaway: Use sanitisation to reduce input risk, but use isolation to absorb the failure when sanitisation is imperfect, because imperfect sanitisation is a normal condition, not an edge case.
Related resources from NHI Mgmt Group
- When should teams choose a CLI-based scanner over a container-based deployment for application security testing?
- When should industrial teams choose identity-based segmentation over network redesign?
- How should teams secure non-human identities across cloud and SaaS?
- How should security teams decide whether JIT access is safe for non-human identities?