A multi-tenant SaaS analytics platform lets customers upload their own transformation scripts, which run on the provider's shared worker fleet. Security is concerned that a malicious script could read other tenants' data or tamper with the underlying host. Which architectural control best addresses this risk?

Sandboxing executes untrusted code inside a constrained environment, such as a dedicated microVM, a hardened container profile or a language-level runtime, that limits which system calls, files, memory and network destinations the code can reach. Because the platform cannot know in advance what a customer script will do, the control has to contain behaviour at runtime rather than predict it. Static analysis before execution is useful hygiene, but it cannot prove that arbitrary code is safe; obfuscated or novel logic passes the scan and then runs with the full privileges of the shared worker, which is exactly the exposure the scenario describes. A web application firewall inspects HTTP requests for attack patterns; it is not designed to judge the behaviour of a legitimate upload whose payload is code, and it does nothing once the script is running. Tenant-specific encryption at rest protects stored media, but a script executing on the host can reach decrypted data in memory or call the same services the platform uses, and it can still damage the host itself. Exam caveat: sandboxing is listed under cloud application architecture in Domain 4, so expect it alongside containers and microservices rather than as a data-protection control. Operational check: confirm that each execution gets a fresh isolated environment, that host mounts and privileged calls are denied, that outbound network access is allow-listed, and that resource quotas stop a runaway script.