Guide · Updated 2026-10-31

How do I run untrusted LLM-generated code safely?

Treat code an LLM wrote as code from an unknown author. Run it behind a real isolation boundary, with no secrets inside, a network that reaches only the hosts you list, CPU and memory caps, state you can throw away or rewind, and a log of what happened. With kosa8 each run can get its own microVM with its own kernel, created with kosa8 sandbox create and deleted with kosa8 sandbox rm.

01Steps

Install kosa8. On an Apple silicon Mac or x86-64 Linux:
Create a sandbox with limits and an allow-list. This one gets 2 vCPUs, 2048 MiB of memory, and a network that reaches only the Python package index. Use --egress deny instead when the code needs no network at all; that blocks DNS too.
terminal
```
kosa8 sandbox create runner --cpus 2 --memory 2048 \
    --egress-allow pypi.org --egress-allow files.pythonhosted.org
```
Pull an image and take a clean checkpoint. A checkpoint captures memory, running processes and disk, so you can return to this exact state after every run.
terminal
```
kosa8 sandbox pull runner python:3.12-slim
kosa8 checkpoint runner --label clean
```
Run the generated code. Pass the code to a container inside the sandbox. No API keys or host folders are given to it.
See what it tried to reach. This shows the egress policy the host enforces and the counts of passed and refused traffic. Each refused attempt is also in the audit log as sandbox.egress.deny.
Rewind for the next run, or delete. Rewind puts the whole machine back to the clean checkpoint. When you are done, delete the sandbox.
terminal
```
kosa8 rewind runner --to clean --yes
kosa8 sandbox rm runner
```
Check the record. List recent actions and confirm the hash-chained log has not been altered.
terminal
```
kosa8 audit ls
kosa8 audit verify
```

02What can LLM-generated code do wrong?

Generated code can be wrong, or it can be hostile because the model was steered by text it read, such as a web page, an issue or a file carrying a prompt injection. Either way it runs with whatever access you give it: it can delete files, read credentials, send data to any host it can reach, install packages, or use all your CPU and memory.

OWASP's Top 10 for LLM applications lists this as Improper Output Handling (passing model output to a shell or interpreter without checks) and Excessive Agency (giving a model more tools and permissions than its task needs). Package hallucination adds a supply-chain angle: models suggest packages that do not exist, and an attacker can register those names. Code review and static checks help, but they do not change what the code can reach when it runs. The layers below do.

03Which layers make running untrusted code safe?

Six layers, each covering a failure of the others: an isolation boundary, no secrets inside it, a network allow-list, resource limits, disposable or rewindable state, and an audit log.

Isolation boundary. A kosa8 sandbox is a virtual machine with its own kernel, disk and private network, so a kernel exploit inside does not land in your host's kernel. The docs describe boot as a real kernel in under a second.
No secrets inside. Credentials never cross into a sandbox. When an agent needs a model API key, kosa8's egress broker on the host adds the key to each request after it leaves the VM; the sandbox only holds a placeholder.
Network allow-list. --egress-allow and --egress deny are enforced on the host, in the userspace network every frame from the VM passes through, so root inside the sandbox cannot lift them. In an allow-list sandbox DNS is answered by the host, for the listed names only.
Resource limits. --cpus (default 2), --memory in MiB (default 1024) and --disk in GB cap what one run can use.
Disposable or rewindable state. kosa8 checkpoint and kosa8 rewind restore memory, processes and disk; kosa8 sandbox rm deletes everything, and --wipe overwrites the disks first.
Audit. kosa8's daemon is the only writer of a hash-chained audit log, and kosa8 audit verify walks the chain.

04Can I use a Docker-based code executor with kosa8?

Yes. kosa8 serves a Docker-compatible API on a local socket, so frameworks that run generated code in Docker containers work by setting DOCKER_HOST, with no code changes. kosa8 has tested pages for the smolagents Docker executor and the OpenAI Agents SDK Docker sandbox.

Follow smolagents' Docker executor on kosa8 or OpenAI Agents SDK sandboxes on kosa8. One difference matters: containers started through the Docker API run in kosa8's shared engine, one always-warm VM that separates them from your machine by a VM boundary and from each other by ordinary container isolation. For a VM per run, use kosa8 sandbox as in the steps above, or have an organisation policy set require_sandbox, which makes every container get a machine of its own. Bind mounts work only below folders named with kosa8 daemon start --allow-mount DIR.

05Other options

Docker or Docker Sandboxes. Containers with --network none, memory and CPU limits and a non-root user are a reasonable floor for code you mostly trust. Containers share the host kernel. Docker Sandboxes is Docker's packaged way to run coding agents in an isolated environment.
gVisor. A user-space kernel that intercepts system calls, used as a container runtime (runsc) on Linux.
Firecracker or Kata Containers. MicroVM building blocks for Linux hosts with KVM, suited to running your own multi-tenant execution service.
E2B, Daytona or Modal. Hosted sandboxes you call over an API, a good fit when code should run in the cloud rather than on your machine.
A full VM in UTM or Lima. Strong isolation for occasional manual runs, without per-run checkpoints unless you script them.
Claude Code's built-in sandbox. /sandbox restricts file system and network access for commands Claude Code runs, with no extra install.

06Sources

Updated 2026-10-31