Sandboxes for AI Agents That Run Code: What to Check First

A sandbox for an AI agent is an isolated place where generated code runs, with its own working files, a short list of reachable network destinations, and no access to company credentials or live systems unless a task explicitly grants it. An agent that runs scripts needs one because code can be wrong, can be steered by content the agent reads, and can act at machine speed. Before you allow any execution, check what the run can read, write, reach and keep, and who is notified when it tries something outside those limits.

Key takeaways

• A sandbox is the execution boundary. It is not an optional setting once an agent writes and runs scripts.
• Block outbound network access by default, then allow named destinations one at a time with a stated reason.
• Give each run its own working folder, decide what may persist, and keep every other folder out of reach.
• Keep credentials outside the sandbox and pass in only narrow, short-lived access for a single task.
• Log every execution, every blocked attempt and every file change so a person can review what happened.

Why does an agent that runs code need its own sandbox?

When a language model only drafts text, the worst common outcome is a bad sentence that a person reads before anything happens. When the same model writes a script and executes it, the output becomes an action. A script can delete files, call an external address, install a package, or send data to a service it was never meant to touch. The model does not need bad intent for this to go wrong. A wrong assumption about a file path, a misread column in a spreadsheet, or a dependency that changed since the last run is enough.

Input is the second risk. Agents read emails, web pages, tickets and documents, and any of them can contain text written to redirect the agent. The OWASP prompt injection guidance treats this as a design problem to plan for, not a rare edge case: untrusted content can try to override the instructions the agent was given. A sandbox does not stop the model from being persuaded. It limits what a persuaded agent can reach, and that limit is the reason to build one.

What does the sandbox have to isolate?

Isolation covers four surfaces: process, files, network and identity. Process isolation keeps the code from touching the host machine or other workloads. File isolation gives the run its own working directory and blocks reads from folders outside the task. Network isolation controls which addresses the code can reach. Identity isolation makes sure the run does not inherit a personal login, a browser session or a broad service key that happens to exist on the machine.

Many teams stop at process isolation because it has the most familiar name. The other three decide whether a mistake stays small. Check each surface on its own and write down the answer. A vague answer for any one of them means the environment is not ready for real data.

Limit network access before anything else

Network access carries the largest consequence because it is how data leaves. Default to no outbound connections. When a task needs a service, allow that specific host and only the methods the task requires. A script that reads a public price list does not need write access to a payment provider, and a script that builds a weekly report does not need the open internet. Permissions for each allowed destination should be reviewed the same way you would review a human's access, as described in least privilege for AI agents.

Allowed destinations can also point somewhere you did not intend. Test whether the sandbox can reach internal admin pages, other machines on the same network, and cloud metadata addresses that sometimes expose temporary credentials. Ask the platform provider how name resolution and redirects are handled, and whether allowed hosts are enforced at the network layer or only in the code the agent writes. The second option is weaker, because generated code can call anything it is able to construct.

The safest default for a script is that it can reach nothing it was not explicitly given.

Control file access and what survives a run

Give each run an empty working directory and mount only the input files the task names. Outputs should go to a designated folder that a reviewer can open. Decide whether the sandbox is wiped after every run. Persistent state is useful for long jobs, but it is also where stale files, leftover tokens and corrupted data accumulate. When an agent must reuse information from one run to the next, store it through the approved memory or database layer, not as a loose file that the next run trusts without checking. For data systems, a read-only connection is often the right starting point, as explained in connecting an agent to a database with read-only access.

Illustrative scenario: a small distributor lets an agent clean a weekly export of order data. The sandbox receives one CSV file, writes a cleaned version to an output folder, and has no route to the shared drive. One week the export contains a cell that looks like a command. Because the run has no network route and no write access outside its folder, the script fails with an error and writes a log entry, and nothing else changes. A person reviews the log on Monday and corrects the source export.

What should you check before allowing code execution?

Use the following list as a review before the first real run. Each line should have a written answer and an owner.

• Which languages and libraries can run, and who approves a new package before it is installed?
• Which network hosts are reachable, listed by name, with a reason for each?
• Which folders are visible to the run, and is each one read only or writable?
• How long can a run last, and what memory and processor limits stop it?
• Which credentials, if any, enter the sandbox, and are they short-lived and scoped to one task? Compare the options in where an agent's passwords and API keys should live.
• What is logged: the code that ran, the inputs, the outputs, blocked connection attempts and file changes?
• Who is alerted when a run hits a limit, and what can the agent do next without asking?
• Can the environment be deleted and rebuilt from a known definition quickly?
• Has someone tried a deliberately hostile input, such as a document with instructions to send data elsewhere, before real records arrive?

If nobody on the team can answer one of these lines, the agent should not receive execution rights for that task yet. A narrower task with a complete answer sheet is a better first step than a broad task with gaps.

How does Be Human handle sandboxes in managed operations?

Be Human designs the execution boundary as part of the first engagement rather than as a later addition. The first role defines which scripts the agent may run, the sandbox policy for network, files and credentials, the approval points for installing packages or writing outside the output folder, and a success criterion that shows whether the boundary is working. In managed operations, the team reviews run logs and blocked attempts, tests permissions on a recurring schedule, maintains integrations when a provider changes an address or token format, and handles incidents by pausing execution while the cause is traced. The memory, tools and permissions remain under the company's control throughout. If you are unsure which task deserves execution rights first, take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

Is a sandbox the same as a container? A container is one common way to build a sandbox, because it packages a process with its own file view and resource limits. A container alone does not decide what the code can reach over the network or which credentials it can see. Those rules must be set on purpose, whichever technology provides the isolation.

Can I let the agent run code on my laptop or a shared server? You can test on a laptop with fake data, but a shared server or personal machine usually holds logins, tokens and files that a script could reach by default. Use a separate environment with no inherited access for anything that touches real company records. Keep the test environment and the production environment clearly distinct.

Does a sandbox stop prompt injection? No. A sandbox cannot make the model ignore hostile instructions, and it cannot judge whether a request is legitimate. What it does is limit the damage when an instruction succeeds, by keeping network, file and credential access small. Pair it with approval steps for any action that changes data or sends something outside the company.

How do I know the sandbox is working? Test it on purpose. Ask the agent to reach a host it should not reach, read a folder it should not see, and write outside its output directory, then confirm that each attempt is blocked and logged. Repeat these checks after any change to permissions, packages or providers, because boundaries tend to drift when nobody is watching them.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.