APP-016 Sandboxed Execution of Untrusted Code
Description
Code that did not come from the organisation's own build pipeline, including customer-supplied code, third-party plug-ins and code a model generates, executes only inside a confined environment separated from the host and from other tenants. The confined environment runs with the least privilege the task needs: no ambient credentials, an explicit allow list of outbound network destinations, a filesystem that is read-only or scoped to the task and limits on processor, memory and run time. The categories of external code permitted to execute and the conditions under which each runs are documented and approved. Execution events, including denials and breaches of a resource limit, are logged.
Rationale
A feature that lets a model write code and a runtime execute it is the current instance of the mobile code problem NIST wrote SC-18 for. Nothing in the library required that execution to be confined. Issued in S4 from the disposition register working id NC-20. AIG-029 holds prompt injection controls, including the privilege separation that decides what a tool call is allowed to ask for; APP-016 holds what the runtime does once the call is made, whatever caused it. APP-010 separates development, test and production environments, a different boundary. INF-015 separates tenants, which the sandbox sits inside. The usual mechanism is a container with a restricted system call profile and a network policy, or a microVM for each execution. The observable is the privilege set the environment runs with, not the product that provides it.
Applicability (9 profiles)
Applies where the deployer executes model-generated or third-party code. Where the sandbox is a provider feature the deployer holds the provider's description of its limits.
Applies where the deployer executes model-generated or third-party code. Where the sandbox is a provider feature the deployer holds the provider's description of its limits.
Framework Mappings (10)
| AIS-11 | Agents Security Boundaries | informative |
| AIS-13 | AI Sandboxing | full |
| MDS-13 | Secure Model Format | informative |
| AML.M0032 | Segmentation of AI Agent Components | informative |
| NIS2-CIR-6.9 | Protection Against Malicious and Unauthorised Software | informative |
| CM-7(6) | Least Functionality | Confined Environments with Limited Privileges | full |
| SC-18 | Mobile Code | full |
| MS-2.6-004 | AI System Safety Risk Evaluation | MS-2.6-004 | informative |
| ASI02 | Tool Misuse and Exploitation | informative |
| ASI05 | Unexpected Code Execution (RCE) | full |
Evidence (3)
Runtime configuration of the confined environment: the privileges it holds, the outbound network allow list, the filesystem mounts with their mode and the limits on processor, memory and run time.
Example: Sandbox runtime manifest for the code execution service, exported 2026-09-03, with a restricted system call profile, a deny-all egress policy carrying three allowed destinations and a 30 second execution limit.
Test: Read the runtime configuration for each service that executes external code. Verify: (1) the environment runs without ambient credentials, with no cloud instance role or injected secret reachable from it, (2) outbound network access is denied by default with named exceptions, (3) the filesystem is read-only or scoped to the task with no writable path shared between executions, (4) processor, memory and run time limits are set, (5) the environment is separated from the host and from other tenants by a boundary named in the architecture record.
Live test of the confinement, running probe code inside the environment that attempts to read host credentials, reach a destination outside the allow list, write outside its scoped filesystem and exceed a resource limit.
Example: Sandbox escape test walkthrough, 2026-09-04, recording the four attempts and the denial returned for each, with the corresponding log entries.
Test: Submit probe code to the execution service in the presence of the assessor. Verify: (1) an attempt to read the host credential endpoint fails, (2) a request to a destination outside the allow list is refused, (3) a write outside the scoped filesystem fails, (4) an execution that exceeds the run time or memory limit is terminated, (5) each attempt appears in the execution log with its denial.
Register of the categories of external code permitted to execute, the conditions under which each runs and the approval of each category.
Example: External code execution register v1.2, approved 2026-07-21, covering customer-authored transforms, marketplace plug-ins and model-generated analysis code, each with its permitted environment and approver.
Test: Request the register of permitted external code categories. Verify: (1) each category a running service actually executes appears in the register, (2) each entry names the conditions under which that category runs and the environment that confines it, (3) each entry carries an approver and a date, (4) no service executes a category absent from the register, tested against the execution log for the period.
Questions (3)
Does code from outside your own build pipeline execute only inside a confined environment?
Customer-supplied scripts, third-party plug-ins and code a model writes at run time all count. If any of them executes in the application process, the answer is no.
Which restrictions apply to the environment that runs external code?
The credential question is the one that decides the blast radius: an environment that can reach the cloud instance metadata service holds the privileges of the host regardless of its other limits.
What boundary confines the execution?
Options run from strongest to weakest by how much of the host is reachable after an escape. An interpreter restriction is defeated by any bug in the interpreter.