Sandboxing and Isolated Evaluation Environments — Frontier AI Security: Foundations

When a frontier artificial intelligence (AI) model is evaluated for dangerous capabilities, the evaluators often remove or relax the normal restraints that keep the model from attempting harmful actions. At that point, safety no longer depends mainly on the model choosing not to act. It depends on the environment preventing the model’s actions from reaching real systems. That environment is the sandbox: a deliberately isolated place where the model can try hard, fail, improvise, and make a mess without touching the outside world.

What a sandbox is for

A sandbox is an isolated computing environment where a program, tool, or model can run while technical boundaries limit what it can affect. The familiar image is useful: a child can scatter sand inside the box because the edges keep the sand out of the house. In computing, the sand is execution: commands, files, network requests, tool calls, package installs, and other actions produced during a run.

For AI capability evaluation, the sandbox is not a convenience feature. It is the compensating control that makes an otherwise risky experiment tolerable. Evaluators may want to know whether a model can find vulnerabilities, write exploit code, chain tools, or pursue a goal over many steps. To measure that honestly, they may reduce refusals and give the model more freedom. The sandbox is supposed to make that freedom safe by ensuring the model can act only inside a controlled world.

This distinction matters. A safe model and a contained model are different claims. A safe model does not attempt dangerous behavior, or stops when it should. A contained model may attempt dangerous behavior, but the environment prevents the attempt from causing real harm. Capability evaluations often rely on the second claim.

📌

The core tradeoff. A good evaluation gives the model room to reveal capability while denying it room to affect real targets.

The three walls of isolation

Sandboxing is not one mechanism. In practice it is built from several controls that overlap. The three most important walls are virtualization, network control, and least-privilege permissions.

Virtualization places the workload on a simulated computer rather than directly on the host machine. A virtual machine (VM) presents its own disks, memory, operating system, and devices, while the underlying physical hardware remains separated by a virtualization layer. Containers can also isolate workloads, but they usually share more of the host operating system than a VM does, so their security properties differ.

Network control limits where the sandbox can connect. The strongest default is to deny outbound traffic unless a specific destination and protocol have been approved. This is often called egress filtering, because it controls traffic leaving the environment.

Least privilege means each process, account, tool, and service receives only the authority it needs. Inside the sandbox, the model should not automatically be able to read every file, change system settings, access secrets, mount disks, call cloud services, or modify the evaluator’s infrastructure.

Sandboxing is built from overlapping controls: virtualization, network control, and least privilege.

Why layers matter

Layering matters because no single boundary is perfect. A VM reduces exposure to the physical host, but it does not by itself stop outbound network access. A firewall can block the internet, but it does not fix an overpowered local account. File permissions can reduce damage inside the guest system, but they do not prevent a misconfigured proxy from becoming a route out.

A well-designed sandbox assumes that one control may be incomplete, misunderstood, or bypassed. The goal is not blind faith in any one wall. The goal is defense in depth: if one control fails, another control still limits the blast radius.

This is especially important for agentic evaluations, where a model can use tools over many steps. A simple script may do exactly what its author wrote. A goal-directed model may inspect its surroundings, infer constraints, test assumptions, and adapt. That does not make the model magical; it means the evaluation environment must be designed for an active searcher, not only for accidental misuse.

⚠️

Do not count walls twice. Two controls are not independent if they depend on the same misconfigured identity, route, or host service.

The necessary door

A completely sealed sandbox is easy to reason about, but often hard to use. Evaluations commonly need inputs from outside the box: benchmark tasks, datasets, software packages, operating system updates, logging channels, or a place to export results. So most real sandboxes include at least one narrow, intentional opening.

The most common opening is a package or artifact path. A model may need to install a Python library, fetch a container image, download a dataset, or retrieve a test dependency. Instead of allowing direct internet access, teams often place a controlled proxy between the sandbox and approved repositories. The proxy can cache artifacts, enforce allowlists, scan content, and log requests.

That door is sensible, but it is also security-sensitive. It is the place where the isolated world touches the non-isolated world. If dependency resolution is too broad, if the proxy trusts the wrong source, if package installation runs arbitrary setup code, or if credentials are exposed through the path, the door can become more than a door. It can become an escape route.

How sandboxes leak

Sandbox failure is usually not dramatic at first. It is often a small inconsistency between the design people believe they have and the system that actually exists. One outbound route remains open. A service account has more permission than expected. A temporary file contains a token. A shared folder exposes the host filesystem. A debugging endpoint is still listening. A VM feature intended for convenience allows more interaction with the host than the evaluation requires.

Virtualization can also have defects. Hypervisors, device emulators, kernel interfaces, and guest integration tools are all software, and software can contain vulnerabilities. A VM boundary is a strong control, but it is not a law of physics.

Network controls can fail through unexpected name resolution, proxy behavior, metadata services, dual-stack networking, stale firewall rules, or permitted destinations that provide broader access than intended. Permission boundaries can fail when users, groups, mounted volumes, cloud identities, or local services are granted authority that seemed harmless in isolation.

The uncomfortable lesson is that isolation is a system property. It is not proven by pointing to one product setting or one architecture diagram. It must be tested as the whole assembled environment that the model will actually use.

An unneeded outbound route that reaches the public internet.
A package installation path that executes untrusted code with too much authority.
A shared directory that lets guest processes read or write host files.
A secret, token, or cloud credential left inside the evaluation image.
A management or debugging service reachable from inside the sandbox.
A permission grant that is safe for a human operator but too broad for an automated agent.

⚠️

One hole is enough. A sandbox can be carefully built and still fail if a single real path connects the model’s actions to something outside the intended boundary.

Sandbox failure is usually a small gap between the design believed in and the system that exists.

The practitioner’s decision points

Leaders and practitioners face practical choices, not abstract ones. The question is not whether to sandbox. For serious capability evaluation, the question is what kind of sandbox is strong enough for the risk of the task.

A low-risk benchmark that runs fixed code over static files may need a simple isolated runner, strict file permissions, and no network. A cyber-capability evaluation where a model can write code, run tools, and adapt over many steps needs stronger separation: fresh VMs, default-deny egress, controlled artifact retrieval, no persistent credentials, detailed logging, and a clean teardown after each run. An evaluation that intentionally studies exploit development or autonomous attack chaining may need malware-lab discipline, including separate infrastructure, human approval gates, and incident response plans.

The decision should be tied to the claim being made. If a team says the evaluation is safe because the model cannot reach the internet, they should be able to show the egress policy, test results, and exceptions. If they say secrets are unavailable, they should be able to show how images are built, scanned, and stripped. If they say the host cannot be reached, they should be able to show the virtualization boundary, shared-resource policy, and teardown process.

The kind of sandbox should match the risk of the task, from a simple runner to malware-lab discipline.

What good sandbox assurance looks like

A good sandbox is not only built; it is verified. Verification starts with a clear boundary statement: what the model may access, what it may not access, what leaves the sandbox, and who can approve exceptions. Without that statement, engineers cannot test whether the sandbox is doing its job.

Next come negative tests. Try to reach the internet. Try to resolve external names. Try to access cloud metadata endpoints. Try to read host-mounted files. Try to find secrets in environment variables, shell history, package caches, logs, and configuration files. Try to use allowed services in unintended ways. The point is not to simulate every possible adversary. The point is to discover whether the obvious seams are actually sealed.

Finally, treat the sandbox as disposable. Each evaluation run should start from a known-good image and end with teardown that removes changes, credentials, temporary files, and network state. Logs and artifacts should be exported through a controlled path, not by leaving the sandbox half-open for convenience.

Sandboxing does not make risky evaluation risk-free. It changes the shape of the risk. Instead of asking only whether the model will behave, we ask whether the environment will hold when the model does not.

✅

The right test. Do not ask whether the sandbox exists; ask what evidence shows that its boundaries hold under the exact workload being evaluated.

Key takeaways

A sandbox is the main compensating control when an evaluation relaxes a model’s normal safety restraints.
Strong isolation usually combines virtualization, default-deny network control, and least-privilege permissions.
Most useful sandboxes need a narrow approved door for artifacts such as packages, datasets, or logs.
The approved door is often the most security-sensitive part of the design because it connects inside to outside.
Sandbox failure usually comes from one overlooked path, excessive permission, exposed secret, or flawed boundary.
Leaders should match sandbox strength to evaluation risk and require evidence that the boundary has been tested.

A good sandbox is verified: state the boundary, test the seams, and tear it down after each run.

Glossary

Sandbox: An isolated environment where a program or model can run while technical boundaries limit what it can affect outside that environment.
Artificial intelligence (AI): Software systems that perform tasks associated with human reasoning, language, perception, planning, or decision-making.
Virtual machine (VM): A simulated computer that runs its own operating system while being separated from the physical host by a virtualization layer.
Virtualization: The technique of presenting software with simulated hardware or operating environments instead of giving it direct access to the underlying machine.
Egress filtering: A network control that blocks or restricts traffic leaving an environment.
Least privilege: The practice of giving each user, process, tool, or service only the minimum authority needed for its task.
Compensating control: A safeguard that reduces the risk of an activity that would otherwise be too dangerous or unacceptable.
Defense in depth: A security design approach that uses multiple overlapping controls so one failure does not immediately expose the whole system.
Package-registry proxy: A controlled service that mediates access from a sandbox to software package repositories, often enforcing allowlists, caching artifacts, and recording requests.