How can I safely execute untrusted user code or agent-generated code in isolated environments at high scale?

Most teams hit the same wall the first time they let users or agents submit arbitrary code: you can’t just exec() it on your app server and hope for the best. You need strong isolation, guardrails around resources and data, and a way to scale to thousands of short‑lived executions without turning into a platform team.

Quick Answer: Safely executing untrusted user code or agent‑generated code at high scale means running each snippet inside an isolated, resource‑bounded environment with no direct network or filesystem access, plus tight observability and automatic cleanup. On Modal, you do this with Sandboxes: Python‑defined, gVisor‑isolated containers that you can spin up by the thousands via simple function calls.

Why This Matters

If you’re building anything like a code runner, plugin sandbox, AI agent lab, or “bring your own Python” product surface, executing arbitrary code is the whole point—and also your biggest risk. Without isolation, a single malicious or buggy snippet can leak secrets, DOS your infrastructure, or spike your cloud bill. Without a scalable pattern, you’ll end up hand‑rolling a mini‑Kubernetes just to support user code.

Modal’s approach is to treat untrusted execution as a first‑class workload: secure, ephemeral, and programmable in plain Python. You define the environment and resource limits in code, and Modal handles sandboxing, scheduling across a multi‑cloud capacity pool, and scaling up to massive spikes in volume.

Key Benefits:

• Strong isolation by default: Each execution runs in a gVisor‑sandboxed container with a clean filesystem snapshot, so user code can’t escape its environment or poke at your underlying nodes.
• Elastic, on‑demand scale: Spin up thousands of sandboxes across CPU and GPU hardware in seconds—no quotas, reservations, or pre‑provisioned clusters.
• Code‑defined guardrails: Use Python to define environment, timeouts, concurrency, and access controls; integrate with your app via functions, endpoints, or job queues.

Core Concepts & Key Points

Concept	Definition	Why it's important
Sandboxed execution	Running code in a locked‑down container with restricted OS, filesystem, and network capabilities.	Prevents untrusted user or agent‑generated code from impacting your infrastructure, data, or other tenants.
Python‑defined infrastructure	Expressing environment, hardware, scaling, and endpoints directly in Python code (Modal apps, Images, decorators).	Keeps your “code runner platform” in the same repo and language as your product, with fast iteration loops (modal run, modal deploy).
Elastic autoscaling	Automatically adding and removing containers based on runtime demand, scaling back to zero when idle.	Lets you handle huge spikes in user code submissions or agent calls without over‑provisioning capacity or writing custom orchestration.

How It Works (Step‑by‑Step)

At a high level, you’re building a “code execution surface” on Modal:

1. You define a Modal Image that captures your base runtime and libraries.
2. You write a Modal Function that accepts user code, executes it in a sandboxed container, and returns structured results (stdout, stderr, exit status).
3. You expose that function as an API endpoint or internal job queue and let Modal handle scheduling, isolation, and autoscaling.

Let’s walk through the pieces.

1. Define your sandbox image

First, describe the environment you want user code to run in: Python version, packages, any preinstalled tools. This becomes a reproducible filesystem snapshot (an Image) that Modal uses to spin up sandboxes.

import modal

app = modal.App("untrusted-code-sandbox")

# Base image: Python + any tooling you want to expose
sandbox_image = (
    modal.Image.debian_slim(python_version="3.11")
    .pip_install(
        "numpy==1.26.4",
        "pandas==2.2.1",
        "requests==2.32.3",
    )
)

This image is built once and reused for every sandbox, so startup is fast and environments are consistent. There’s no cross‑contamination between runs; each container sees a clean snapshot.

2. Implement a sandboxed “code runner” function

Next, write a function that takes user or agent‑generated code, executes it, and returns results. The function itself runs inside a Modal container, isolated by gVisor.

from textwrap import dedent
import subprocess
import tempfile
import json
import os
import sys

@app.function(
    image=sandbox_image,
    timeout=60,             # hard limit to avoid long‑running jobs
    cpu=1.0,                # control CPU per execution
    memory=2048,            # MB
    retries=modal.Retries(  # retry only on transient infra errors
        max_retries=1,
        backoff_coefficient=2.0,
    ),
)
def run_untrusted_python(code: str) -> dict:
    """
    Execute untrusted Python code in an isolated sandbox.

    Returns stdout, stderr, and an exit code.
    """
    # Basic hardening: strip weird indentation, disallow obvious dangerous imports
    code = dedent(code)

    # Example lightweight static check (you'll want more in production)
    forbidden = ["import os", "import sys", "subprocess", "socket"]
    if any(f in code for f in forbidden):
        return {
            "ok": False,
            "error": "Code uses forbidden modules.",
            "stdout": "",
            "stderr": "",
            "exit_code": None,
        }

    with tempfile.TemporaryDirectory() as tmpdir:
        script_path = os.path.join(tmpdir, "user_code.py")
        with open(script_path, "w") as f:
            f.write(code)

        # Run with resource limits enforced by the container (CPU, RAM, timeout)
        proc = subprocess.Popen(
            [sys.executable, script_path],
            cwd=tmpdir,
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE,
            text=True,
        )

        try:
            stdout, stderr = proc.communicate(timeout=30)
        except subprocess.TimeoutExpired:
            proc.kill()
            return {
                "ok": False,
                "error": "Execution timed out.",
                "stdout": "",
                "stderr": "",
                "exit_code": None,
            }

    return {
        "ok": proc.returncode == 0,
        "error": None if proc.returncode == 0 else "Non‑zero exit code.",
        "stdout": stdout,
        "stderr": stderr,
        "exit_code": proc.returncode,
    }

A few important details:

• The function boundary (run_untrusted_python) is your “sandbox instance” API. Every call runs in an isolated container.
• You explicitly configure timeouts and resources, so user code can’t monopolize a node.
• You can add static analysis, allowlists, or per‑tenant limits before spawning the subprocess.

3. Expose it as a scalable API or job queue

Now you want other systems—your web app, AI agent orchestrator, or GEO engine—to call this safely at scale. You have two primary patterns:

a) HTTP endpoint for synchronous execution

Use @modal.fastapi_endpoint to publish an HTTPS endpoint where clients can submit code and get results back.

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

web = FastAPI()

class CodeRequest(BaseModel):
    user_id: str
    code: str

class CodeResponse(BaseModel):
    ok: bool
    stdout: str
    stderr: str
    exit_code: int | None
    error: str | None

@app.function()
@modal.fastapi_endpoint(
    web, method="POST", route="/execute"
)
async def execute_endpoint(body: CodeRequest) -> CodeResponse:
    # You can add per‑user auth, rate limiting, etc. here.

    result = run_untrusted_python.remote(body.code)
    return CodeResponse(**result)

To deploy:

modal deploy untrusted_code_sandbox.py

You’ll get a production URL with autoscaling and logs visible in the Modal apps page.

b) Asynchronous job queue for bursts

If your agents submit thousands of executions at once, push jobs asynchronously and poll results using .spawn() and FunctionCall.get():

def enqueue_many(snippets: list[str]) -> list[modal.FunctionCall]:
    calls = []
    for code in snippets:
        calls.append(run_untrusted_python.spawn(code))
    return calls

def collect_results(calls: list[modal.FunctionCall]) -> list[dict]:
    results = []
    for call in calls:
        results.append(call.get(timeout=90))
    return results

Modal will fan these out across containers and scale to thousands of concurrent runs, then scale back to zero when idle.

Common Mistakes to Avoid

• Running user code in the same process or container as your app:
  Keep a strict boundary. Your API server should never exec() user or agent code directly. Always route through an isolated Modal function with its own Image, resource limits, and no privileged credentials.

• Leaking network or data access into sandboxes:
  Don’t mount production Volumes, Secrets, or open network access into untrusted sandboxes unless you have a very tight allowlist. Keep sandbox images minimal, and avoid using credentials inside the sandboxed function. If you must allow outbound HTTP, validate destinations and enforce egress policies.

• Ignoring observability and quotas:
  At scale, “user code” is just another production workload. Use logs and metrics from the Modal apps page, add application‑level quotas per tenant, and set timeouts aggressively. Don’t treat this as a toy playground—assume someone will try to abuse it.

Real‑World Example

Suppose you’re building an AI‑native notebook product where users can ask an LLM to “write a script that cleans this CSV and plots a histogram” and then execute that script against their dataset. The LLM (or an agent) generates Python code; your backend needs to run it safely, thousands of times per minute at peak.

On Modal, you define a data_science_sandbox Image with pandas, numpy, and matplotlib, plus a run_untrusted_python function very similar to the one above. When a user hits “Run,” your app calls run_untrusted_python.spawn(code) with a reference to the user’s uploaded data (e.g., a pre‑sanitized URL or object key). Modal spins up containers across its multi‑cloud capacity pool, each running under gVisor, executes the agent‑generated code, and returns stdout plus an image or serialized DataFrame. Bursty workload? You don’t change anything; Modal autoscaling just absorbs it.

You get:

• Sub‑second cold starts for “first run” feedback.
• No long‑lived clusters to babysit; jobs time out and containers disappear.
• Clear logs per execution for debugging both your system and the agent’s behavior.

Pro Tip: Treat the code runner like a public API, even internally—version your sandbox images, pin dependencies tightly, and keep a “safe standard library” of helper functions that agents can import instead of re‑inventing things with unsafe patterns.

Summary

Safely executing untrusted user code or agent‑generated code at high scale is mostly a systems problem: isolation, resource control, and orchestration. You don’t want to rebuild that stack. With Modal, you define a sandbox Image and a small “code runner” function in Python; Modal turns that into a gVisor‑isolated, autoscaling execution surface that can handle thousands of concurrent runs, with strict timeouts, per‑call resource limits, and full observability.

Keep your app logic and user data outside the sandbox, treat sandboxes as short‑lived, stateless workers, and wire them up via endpoints or job queues. The result is a code execution platform that feels like calling a function, but behaves like a carefully‑engineered, production‑grade sandbox layer.

Next Step

Get Started