Sandboxed execution for code and high-impact tool use

Control objective

Sandboxed execution checks that any code an AI agent generates, and any high-impact tool it runs, executes inside an isolated environment rather than directly on production systems, so a malicious or buggy snippet cannot reach the bank's network, data, or infrastructure. This matters because agents that write and run code can be tricked (via prompt injection or poisoned inputs) into exfiltrating data or pivoting across systems; isolation contains the blast radius. The control requires that 100% of generated code runs sandboxed with no network access by default, and that 100% of it is statically scanned before execution. To implement it, route every code-execution and high-impact tool action through an ephemeral, locked-down container or microVM with no outbound network unless an allow-list is explicitly granted, minimal filesystem access, and strict CPU/memory limits; run a static analysis and secret-and-malware scanner on the code first and refuse to execute anything that fails. Log the code, the scan verdict, the sandbox profile applied, network egress attempts, and the execution outcome as evidence. The thresholds are absolute: any code that runs outside the sandbox, with default network access, or without a prior static scan is a breach that must block execution and trigger investigation. Aligns with OWASP ASI05, MAESTRO L4, and MITRE AML.T0051.