Yes, inside an isolated sandbox. The deciding factor is not the code but what the code can reach. An agent that writes and runs a script to analyse a file it was given, in a container with no network, no credentials and no route to live systems, is safe. An agent that runs code on a server with production access is not.
Why is running code different from calling a tool?
A tool is a fixed action with fixed inputs: "look up the customer", "draft the refund". Its reach is known before the agent uses it. Code is open-ended. A few lines can read any file the process can see, open a network connection, or call any interface whose key sits in the environment.
That is why code execution breaks the usual way of bounding an agent. You cannot list in advance every action a script might take. You can only limit the space it runs in.
What does a safe sandbox look like?
| Property | Safe setting | Why |
|---|---|---|
| Network | None, or a named allowlist | Stops data leaving and code fetching more code |
| Credentials | None in the environment | A script cannot use a key it cannot see |
| Files | Only the inputs the agent was given | Limits what can be read |
| Live systems | No route at all | Changes happen through governed tools, not scripts |
| Lifetime | Destroyed after each run | Nothing persists for the next run to misuse |
| Resources | Time and memory caps | Prevents runaway jobs |
| Record | Code, inputs, outputs, exit status filed | The run can be reconstructed |
The same thinking applies to internet access; our answer on whether an AI agent can access the internet safely covers the network side.
What may the agent do with code, and what stays with a person?
The agent may write and run code to transform, analyse or check data it has been given: reconciling two exports, testing a calculation, producing a chart, parsing an awkward file. Results come back as output, which the agent can use in a draft.
It may not deploy code, schedule it, change a system's configuration, or run anything against production data stores with write access. Querying a data warehouse is a special case: read-only queries through a governed connection are fine, and our guide on letting an AI agent run queries on your data warehouse safely sets out the controls. Any code meant to run in a live system goes through your normal change process, with a person reviewing and releasing it.
A worked example
Take an insurer's finance analyst who asks an agent to compare two claims extracts that should match but do not. The agent writes a short script, runs it in a sandbox holding only the two files, and finds 140 claims present in one extract and not the other, all from a single day.
The script also tries to import a library that is not installed. With no network, it cannot download it, so the agent rewrites the step using what is available. The output goes to the analyst with the code attached. The analyst raises a ticket with the data team. At no point could the script have reached the claims system, because nothing in the sandbox led there.
Which controls make the answer hold?
- Isolation by default. Every run starts in a fresh, empty environment.
- No secrets. Keys stay in a secrets manager the sandbox cannot reach. If the agent needs data from a system, a governed tool fetches it and passes it in.
- No network unless named. If a run truly needs a package source, allow that one address.
- Code is part of the record. The script, its inputs and outputs are filed with the verdict, so a reviewer can see exactly what ran.
- Review of sandbox permissions. Include them in access reviews; our guide on how to run an access review for AI agents covers the routine.
Banks and other regulated firms often add a rule that code outputs used in a decision are reviewed by a person; see how banks use AI agents safely. The topic guide, agent governance is a bound, not a model, explains why the sandbox is a bound the model cannot talk its way out of.
Questions people ask
Can the agent run code that a person wrote?
Yes, if the code is approved and versioned like any other tool. At that point it is a fixed tool, and its reach can be assessed in advance.
What if the code produces a wrong result?
The output is a draft input to the agent's work, not a decision. Keeping code and outputs in the record means a reviewer can find the error and see what relied on it.
Is a sandbox enough for prompt injection?
It limits the damage. A malicious instruction in a file can still produce a misleading result, but it cannot reach your systems or send data out from a properly isolated sandbox.