A bounded execution environment
Execution isolation prevents one program from reading, changing, impersonating, or disrupting resources outside its assigned boundary. A sandbox is a deliberately restricted execution environment for code that may be faulty or hostile. Processes, containers, virtual machines, language runtimes, browser sites, and trusted execution environments provide different boundaries.
Name each mechanism
Memory protection separates address spaces. User and group identities control operating-system objects. Namespaces change which processes, mounts, users, and networks are visible. Capabilities and syscall filters limit privileged operations. Control groups limit resources. Mandatory policy can constrain information flow. Virtual machines add a guest kernel and hypervisor boundary.
Do not use "sandboxed" as a complete claim. State the adversary, protected assets, allowed interfaces, shared mechanisms, and maximum effect of an escape.
Boundary design
Remove host mounts, runtime sockets, debug interfaces, device access, ambient capabilities, package installation, metadata credentials, and unrestricted egress. Give the workload a narrow identity and short-lived credentials. Bound CPU, memory, processes, storage, network, and output size so a hostile workload cannot deny service through normal permitted operations.
Treat files, logs, and messages leaving the sandbox as untrusted. A sandbox can contain execution and still allow data exfiltration through an approved response or network destination.
Failure and residual risk
Containers share a host kernel. Virtual machines share a hypervisor and hardware. Language sandboxes depend on a runtime and native extensions. Side channels, shared devices, speculative execution, management planes, and supply-chain compromise can cross apparent boundaries. A privileged container or mounted runtime socket can make the boundary nominal.
Isolation can fail closed for confidentiality and still fail open for availability when the shared host exhausts resources. Recovery that restarts the same compromised image does not restore trust.
Pomerium boundary
Pomerium can authenticate and authorize access to a sandbox service. It does not create the runtime isolation or inspect every effect of code inside it. Operators must protect the Pomerium runtime from untrusted workloads and must keep sandbox credentials, egress, host interfaces, and direct upstream paths narrow.
Evaluation checklist
- What exact memory, file, process, network, device, syscall, credential, and resource boundaries are enforced?
- Which kernel, hypervisor, runtime, hardware, and management components are shared?
- Can permitted output, egress, or resource use still expose data or deny service?
- Does the workload have a host mount, runtime socket, debug path, device, capability, or broad cloud identity?
- What test proves both containment and clean recovery after an escape attempt?
