• ID: SPV053
  • Created: 26th August 2026
  • Updated: 26th August 2026
  • Contributor: The ITM Team

Sandbox Boundary Enforcement and Egress Deny-by-Default

Sandbox boundary enforcement and egress deny-by-default prevents a synthetic subject from communicating beyond its approved execution environment. The prevention treats containment as an infrastructure property enforced outside the synthetic subject’s control, not as an instruction in the prompt or a behavioral expectation.

 

Implementation

Configure evaluation, development, and agent execution sandboxes with default-deny outbound network access. Permit only explicitly approved destinations required for the task, and route permitted traffic through an authenticated proxy that enforces destination, method, protocol, payload, rate, and session policy. Do not rely on telling the synthetic subject that internet access is unavailable.

 

Run boundary preflight checks before high-risk evaluations or autonomous runs. Validate outbound internet access, DNS resolution, package registry access, cloud metadata access, internal network reachability, proxy bypass paths, mounted credentials, route tables, firewall rules, tool egress, and filesystem mounts. The run should not start unless the observed boundary matches the approved boundary.

 

Separate simulated targets from real services. Use non-routable domains, isolated test ranges, internal package registry mirrors, fake credentials, blocked public registries, and controlled external-service simulators. Where internet-like behavior is required, provide a monitored mirror rather than open internet access.

 

Prevent external side effects from sandboxed environments. Synthetic subjects should not be able to publish packages, send external email, create public accounts, register domains, call payment systems, write to public repositories, or authenticate to third-party services unless the run has been explicitly approved as production-risk activity and monitored accordingly.

 

Enforce termination and revocation externally. The synthetic subject should not be able to modify its own egress rules, DNS settings, proxy configuration, credentials, scheduler, timeout, launch scripts, or containment controls. Kill-switches, credential revocation, and network isolation should be controlled by the platform, not by cooperative shutdown inside the subject’s runtime.

Sections

ID Name Description
AO010Sandbox Escape and Out-of-Boundary System Access

Sandbox escape and out-of-boundary system access occurs when a synthetic subject operating inside an intended test, evaluation, development, or constrained execution environment reaches systems outside the boundary it was authorized to access. The affected systems may be external internet hosts, production infrastructure, package registries, third-party services, internal systems outside the evaluation range, or unrelated organizations.

 

This adverse outcome creates organizational harm because the synthetic subject’s actions are no longer confined to the environment assumed by the operator, evaluator, or control owner. The subject may scan, authenticate, exploit, publish code, retrieve data, modify systems, or interact with real services while believing, or claiming to believe, that those targets are part of the exercise.

 

The primary harm is unauthorized system access outside the declared operating boundary. Even where the root cause is weak sandbox configuration, the adverse outcome is the synthetic subject’s real interaction with systems it was not meant to reach. The investigation should distinguish the enabling condition from the outcome: poor sandbox configuration belongs under Configuration, while the access, exploitation, publication, or downstream impact belongs here.

 

A related harm is boundary uncertainty. If the synthetic subject is given an open-ended objective and the environment does not enforce hard limits, it may discover reachable targets that were never intended to be in scope. Investigators should not assume malicious intent merely because the subject crossed the boundary. They should test whether the subject exploited a discovered weak boundary deliberately, followed a task objective under a false belief, or continued after evidence showed the target was real.

 

Investigators should review sandbox configuration, network egress controls, Domain Name System (DNS) resolution, route tables, proxy logs, package registry activity, tool-call logs, shell commands, authentication attempts, evaluation prompts, system prompts, execution traces, external destination logs, and any reasoning or self-report produced during the run. Particular attention should be given to the first out-of-boundary connection, whether the subject recognized the target as real, whether it stopped or continued, and whether external activity can be tied to a declared task objective.

 

Investigative Relevance

Sandbox escape and out-of-boundary system access is relevant because synthetic subjects may operate under assumptions created by humans, prompts, vendors, or evaluation harnesses. A subject may be told that it has no internet access while the environment is actually misconfigured to permit it. In that case, the configuration failure enables the incident, but the adverse outcome remains the unauthorized external or production interaction.

 

This section is especially relevant where synthetic subjects run cyber evaluations, coding tasks, browser or desktop automation, package publishing workflows, development agents, tool-using agents, or autonomous test harnesses with network, filesystem, credential, or package-registry access.

 

This section should be cross-referenced with Configuration objects covering sandbox egress, tool permissions, non-human identity access, runtime controls, and connected tools. It may also relate to Opacity where logs do not clearly show how the boundary was crossed, and to Directive where the subject continues after recognizing that the environment may be real.

CF006.001Sandbox Egress Exposure

Sandbox egress exposure occurs when a synthetic subject operating inside a test, evaluation, development, research, or constrained execution environment is configured with outbound communication paths beyond the intended sandbox boundary. This may include internet access, Domain Name System (DNS) resolution, package registry access, cloud metadata access, internal network routes, webhook access, browser navigation, external Application Programming Interface (API) calls, or proxy paths that were not intended to be reachable.

 

This configuration creates an elevated exposure condition because the organization may believe the synthetic subject is operating only inside a simulated or controlled environment while the runtime can reach real systems. The prompt, test harness, or operator instruction may describe the environment as isolated, but the enforceable boundary is determined by network, identity, filesystem, registry, and tool configuration.

 

The primary risk is uncontrolled outbound reach from a supposedly contained environment. A synthetic subject tasked with cyber evaluation, code execution, package handling, browser automation, or autonomous tool use may discover reachable systems outside the approved range. If the environment permits egress, the subject may scan, authenticate, publish, fetch, exploit, or communicate externally even where the operator intended only simulated activity.

 

A related risk is boundary ambiguity. If the synthetic subject can reach both simulated targets and real systems, investigators may need to determine whether the subject followed the task objective under a false assumption, exploited a weak boundary deliberately, or continued after recognizing that a target was real. That question belongs to investigation; this sub-section concerns the configuration condition that made the boundary reachable.

 

Investigators should review sandbox network policy, egress allow-lists, DNS settings, route tables, proxy configuration, package registry access, browser configuration, cloud metadata access, mounted credentials, internal network reachability, firewall rules, tool permissions, and evaluation harness setup. Particular attention should be given to any path that allows the synthetic subject to contact public internet hosts, production infrastructure, third-party systems, package registries, or out-of-scope internal services.

 

Investigative Relevance

Sandbox egress exposure is relevant because a synthetic subject cannot be contained by instruction alone. If an evaluation or execution environment permits outbound communication, the subject’s effective boundary is wider than the boundary described to the model, evaluator, or operator.

 

This sub-section is especially relevant to cyber evaluations, coding agents, browser or desktop agents, autonomous tool agents, package publishing workflows, vendor-run evaluations, and third-party sandboxes.