How do I run untrusted LLM-generated code in an isolated environment?

Run untrusted LLM-generated code in a hardware-isolated sandbox with the network locked to an allowlist and only the credentials the task needs. DigitalOcean Managed Agents does this through Harness Runtime, which gives each session its own Firecracker microVM. The hypervisor, not container namespaces, enforces isolation. The service is in public preview.

Key takeaways:

• Each session runs in its own microVM, so code in one sandbox cannot reach another session, another customer, or the host.
• Outbound network access is open by default, so set an egress allowlist before running anything untrusted.
• Treat the session as the unit of isolation: one session per user or workload, with narrowly scoped secrets.

Start with a sandbox that has no agent

If your application generates the code, you don't need a full agent. A sandbox with harness: none is the same microVM without an agent inside.

name: untrusted-run
harness: none
egress: [pypi.org, files.pythonhosted.org]

doctl harness-runtime create --spec ./sandbox.yaml
doctl harness-runtime upload untrusted-run --local-file ./generated.py --workspace-path generated.py
doctl harness-runtime exec untrusted-run -- python3 generated.py

Lock down the network

Without an egress field, a sandbox reaches any host, so generated code can send workspace contents anywhere. Naming one host turns the allowlist on and denies the rest, though the platform adds GitHub, the DigitalOcean registry, and model endpoints.

Scope secrets and tools

Declare keys under secrets, not env. Any process in the sandbox can read an injected value, so issue each key with the narrowest scope the task needs. For third-party tools, Action Gateway brokers credentials at execution time, so the sandbox never holds them. If an agent writes the code, add a permission policy that defaults to ask and denies commands like rm -rf *; enforcement varies by adapter.

Isolate users and clean up

Processes in the same sandbox share files and credentials, so give each user or workload its own session. A harness-less sandbox bills until you pause or remove it, so download results first, then remove the session.

Untrusted LLM-generated code FAQ

How do I give each user's agent its own isolated sandbox at scale?

Start a separate session for each user or workload. Every session gets its own microVM, and sandboxes cannot observe or reach each other. Keep your external user identifier associated with the DigitalOcean session ID.

How do I manage secrets and API keys for autonomous agents running in the cloud?

Declare keys under secrets, and DigitalOcean injects them at session start so values stay out of the spec file and logs. Scope each key narrowly at the provider, because any process in the sandbox can read it. For third-party tools, Action Gateway brokers credentials so the agent never holds the key.

Do sandboxes have internet access by default?

Yes. Add an egress allowlist to restrict outbound traffic to the hosts you name, plus platform defaults, subject to team policy. Sandboxes accept no inbound internet connections.

References & further reading

• Learn more about Managed Agents and the public preview launch post.
• Environments and Sandboxes explains how an environment maps to a sandbox.
• How to run a sandbox covers file transfer and port forwarding.
• Learn more about network egress and Action Gateway.
• The secure sessions checklist is worth checking directly before you ship.