Test Untrusted AI-Generated Code Safely in a Sandbox

Updated 8 November 2026 · Standard formula, shown below

A sandbox lets you inspect and run untrusted AI-generated code with less risk to your computer and data by limiting what the code can access. You’ll set up an isolated environment, keep it away from sensitive files and networks, and test with disposable inputs. This reduces exposure but cannot guarantee safety, so never treat a sandbox as permission to run code you do not understand.

What You’ll Need

A computer with current security updates and enough free storage to create a virtual machine (VM) or use a reputable, isolated container environment.
A virtualization tool if you choose a VM, plus a trusted, current guest operating system installation image.
The code and any required dependencies, obtained without granting the code access to personal files or credentials.
Non-sensitive test data and a way to record the code’s expected behavior and observed output.

Step-by-Step

Review before running. Read the code and identify its language, entry point, dependencies, and actions. Look for file deletion or modification, shell commands, network connections, credential access, downloads, hidden or obfuscated code, and commands that change system settings. Search unfamiliar functions and dependencies in reliable documentation. If you cannot explain a risky operation, do not run the code; ask for clarification or inspect it manually.
Choose an isolation method. For code you do not trust, a VM is generally easier to isolate and discard than running it directly on your normal desktop. Use a container only if you understand its configuration: containers share the host operating-system kernel and can expose host files, sockets, or devices if configured carelessly. For especially sensitive systems or high-risk code, do not run it on a computer containing valuable data; use a dedicated, disposable machine or seek qualified security help.
Create a clean environment. Install a current guest OS in a VM using a trusted image, or create a narrowly configured container. Apply security updates before introducing the code. Create a standard, non-administrator account for the test. Do not sign in to personal accounts, copy browser profiles, add SSH keys, or provide cloud credentials. Keep the host OS and virtualization software updated too.
Set strict boundaries. Disable shared folders, clipboard sharing, drag-and-drop, USB passthrough, and host integration features unless a specific test requires one. If a shared folder is necessary, make it a dedicated folder containing only disposable test files; do not share your home directory or entire drive. Avoid privileged containers, host networking, and access to the container engine’s control socket. Give the environment only the CPU, memory, and disk space it needs.
Restrict networking. Start with the VM’s or container’s network adapter disconnected or block outbound access using the isolation tool’s controls. This helps prevent data exfiltration, remote commands, and unplanned downloads. If the program genuinely needs network access, allow only the necessary destinations through a controlled network or firewall, and use dummy credentials. Do not assume that a code review or a container alone prevents network activity.
Prepare a disposable test. Take a VM snapshot or create a fresh container before running anything. Use synthetic data, not real customer records, personal documents, tokens, passwords, or private keys. Note what the program should do and which files it is allowed to create or change. If dependencies must be installed, check their sources and names first; installing a package can itself execute code. Prefer a fresh environment with no unrelated packages.
Run with limited permissions. Use the environment’s normal user account, not an administrator or root account. Run one command at a time, with explicit input and a reasonable timeout if available. Watch output and resource use. Stop the process if it unexpectedly accesses files, attempts network connections, changes settings, launches unrelated processes, or consumes excessive CPU, memory, or disk space. Do not paste commands you do not understand into a privileged shell.
Inspect results without trusting them. Compare output with the expected behavior using harmless test cases. Review files created or changed inside the environment and check logs or network activity with the tools available to you. A clean-looking result does not prove the code is harmless: it may behave differently with other inputs or after a delay. Do not copy executables or generated scripts to your host and run them without a separate review.
Dispose of the environment. Shut down the VM and revert to its clean snapshot or delete it. Remove disposable containers, images, and test files when no longer needed. If you suspect the code escaped isolation, disconnect the host from networks, do not enter credentials, and get help from a qualified security professional. A snapshot rollback is cleanup, not proof that a host compromise did not occur.

Common Mistakes

Running code on the host “just once.” A short script can still read files, install software, or send data elsewhere.
Assuming containers are virtual machines. Containers share the host kernel; a privileged or poorly configured container can expose host resources.
Leaving integrations enabled. Shared folders, clipboard access, mounted drives, and device passthrough can bridge the isolation boundary.
Allowing unrestricted internet access. Code may download more code or transmit data, even if its visible purpose seems harmless.
Using real secrets or data. Environment variables, shell history, logs, and test files can reveal credentials or private information.
Trusting a successful run. One test only shows what happened with that environment and input; it does not establish that every code path is safe.

Tips

Keep a written record of the environment settings, command, input, and observed output so you can reproduce the test.
Use a fresh snapshot for each independent test. Do not reuse an environment after running suspicious code.
Review dependency names carefully; similarly named packages can be unrelated or malicious. Avoid installing dependencies you do not need.
Test with small, harmless inputs first, then add cases that check expected errors and boundary behavior.
Separate inspection from execution: reading source, checking documentation, and reviewing dependency manifests can reveal issues without running the program.

Troubleshooting

The program cannot access a file: Keep the restriction in place if the file is not essential. If it is needed, copy a sanitized test file into a dedicated, disposable share and grant access only to that location. Remove the share after testing.

A dependency or download fails: Do not turn on unrestricted networking as a quick fix. Verify the package name and source, then consider downloading approved dependencies separately and placing them in the disposable environment. If you cannot verify the source, stop.

The VM or container becomes slow or unresponsive: Stop the process or shut down the environment through the virtualization tool. Do not increase privileges to make it work. Check resource limits and logs after reverting or recreating the environment.

You see unexpected network or file activity: Stop execution and disconnect the environment’s network. Preserve relevant logs if you need to investigate, but do not reconnect it to your normal files or accounts. Recreate the sandbox from a clean image before any further testing.

You cannot configure isolation confidently: Do not run the code. Ask an experienced administrator or security professional to set up a disposable environment; uncertainty about the boundary is a reason to pause, not to weaken it.

Frequently Asked Questions

Is a virtual machine completely safe?
No. VMs reduce exposure, but vulnerabilities and configuration mistakes can still create risk. Keep software updated, disable unnecessary integrations, and avoid sensitive data.

Is a container enough to test untrusted code?
Not automatically. Containers share the host kernel, and unsafe privileges, mounts, or sockets can expose host resources. Use a carefully restricted container or choose a VM when you need a stronger boundary.

Can I let the code access the internet?
Only when the test requires it and you can limit access. Begin offline; if network access is necessary, use a controlled connection and dummy credentials, and monitor activity.

Should I use my real project files?
No. Use copies with sensitive information removed, or create synthetic test data. Keep the original files outside the sandbox.

What if the code looks harmless?
Appearance is not evidence of safety. Review the source and dependencies, then test only in isolation with least privilege and disposable data.

Does deleting the sandbox remove every risk?
It removes that environment, but does not prove nothing affected the host or an external service. If you observed suspicious behavior, disconnect and seek qualified help.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.