Sandboxing AI-Agent 3D Rendering and Asset Pipelines in MicroVMs

There is a category of product that has quietly become normal in the last two years: you describe a thing, and a 3D asset comes back. A product configurator that renders your sofa in eleven fabrics. A generative-3D startup that turns a prompt into a glTF. A CAD pipeline that ingests a customer's STEP file and emits a web-viewable mesh with LODs. A marketplace that thumbnails every uploaded asset. In all of them, somewhere in the middle, an AI agent writes a Blender Python script — set the camera here, swap this material, bake these normals, render at these samples — and then something has to actually run it.

I'm Ajay; I built PandaStack. This post is about where that script runs, and why the answer should be a Firecracker microVM that exists for the duration of one job and then stops existing. The parts I want to get across: a `.blend` file is a program, not a document, and the whole 3D ecosystem is script-driven by design; asset parsers are an enormous pile of C reached by attacker-chosen bytes; a render is CPU-and-RAM-shaped and fundamentally unbounded, which is precisely the shape that breaks shared pools; egress matters because agents install add-ons and fetch textures from URLs; determinism matters because customers notice when a render changes; and snapshot-then-fork turns a parameter sweep from N scene parses into one. I'll also be plain about what this design does not cover, which is GPU rendering.

A .blend file is a program wearing a document's clothes

This is the load-bearing fact of the whole post, and it surprises people who haven't shipped a 3D pipeline before. Blender scene files can carry embedded Python that runs when the file is loaded. Text datablocks can be flagged to register on load. Driver expressions — the little formulas that make one property follow another — are Python. Node groups, rigs, and geometry setups arrive with helper scripts attached because that is how riggers and technical artists work. The format was designed for a program that is fundamentally a Python application with a viewport bolted on, and it is very good at that job.

Blender is not careless about this. Auto-execution of embedded scripts is off by default, there is a `--disable-autoexec` command-line flag, and the UI warns you loudly when a file wants to run code. Set the flag. Set it explicitly, in every invocation, even though it's the default, because defaults are a property of a version and your version will change. But understand exactly what you've bought: you have closed the door where the *scene* runs code. You have not closed the door where *you* run code, and in an agent pipeline that door is wide open by design.

Disabling auto-run is necessary and nowhere near sufficient

The agent's entire job is to write a script and have it executed. `blender --background scene.blend --python render_job.py` is the pipeline. So the process running your renders is, by construction, a Python interpreter executing model-generated code with the full `bpy` API available to it — which includes the filesystem, `subprocess`, and the network, because Blender's Python is a normal CPython. Auto-run being disabled means the scene can't execute code on load. It does not mean nothing executes code.

• The agent's script is the payload — model output is untrusted input. Not because the model is malicious, but because it is steerable: the scene name, an object name, a material comment, or a texture filename can all carry prompt-injection text that the agent reads while deciding what to write. "Untrusted" here means "not authored by you", which is the only definition that matters.
• Add-ons are arbitrary code — a pipeline that lets a user or agent install an add-on to handle some exotic format is a pipeline that runs a stranger's Python at import time. Add-on installation is not sandboxed and was never intended to be.
• Drivers and handlers survive the file boundary — a scene can register frame-change handlers and driver expressions that fire during a render, not just at load. "I only opened it, I didn't run it" is a distinction the renderer does not make.
• Linked libraries pull in more files — a `.blend` can link external `.blend` libraries by path, and those paths can be relative, absolute, or point somewhere you didn't expect. Resolution happens at load, before any of your validation logic gets a turn.
• Format converters are scripts too — most FBX, OBJ, and glTF importers in the ecosystem are either Python or thin bindings over C. The Python ones execute; the C ones are the subject of the next section.

You cannot statically decide whether a scene file is safe. Determining what it does generally requires opening it, and opening it is the dangerous operation.

Every asset format bottoms out in a large pile of C

Set the scripting hazard aside for a moment and look at the bytes. A render job touches, at minimum: an image decoder per texture, a mesh format parser, a compression library, a color-management library, and often a volumetric or point-cloud reader. Follow any of them down and you land in native code with a long history and a lot of surface area.

• Image decoders are the classic hunting ground — PNG, JPEG, TIFF, and OpenEXR parsers have collectively produced decades of memory-corruption bugs, and textures are the most attacker-controlled input in the entire pipeline. OpenEXR in particular is a rich, deeply-nested format with tiles, multi-part files, and several compression codecs; TIFF is famously a container format pretending to be an image format.
• Mesh and scene formats — FBX (via Assimp or a vendor SDK in most pipelines), OBJ, glTF with Draco compression, Alembic, and USD are all C++ readers parsing structured binary from an untrusted source. Draco in particular is compressed geometry, which means the decoder allocates based on numbers in the file.
• Volumes and point data — OpenVDB grids are sparse hierarchical structures whose shape is described by the file itself. A grid can claim a bounding box that is legal, enormous, and instantly fatal to your memory budget.
• USD composition is a graph, not a file — sublayers, references, payloads, and variant sets compose across files, and asset resolution can reach paths you did not audit. A single small `.usda` can describe a composition that takes minutes to resolve and gigabytes to hold.
• Font and SVG rasterizers sneak in — text objects, logos on a product configurator, decal SVGs. Two more parsers, two more decades of CVEs, arriving through a feature nobody thinks of as an attack surface.
• The boring failure counts too — the parser does not need to be exploited to hurt you. It just needs to segfault mid-render on a shared host, forty minutes into someone else's job.

A microVM is the right answer here for the same reason it is the right answer for media transcoding, which I wrote up in /blog/microvm-ai-agent-video-transcoding-isolation: the guest runs its own kernel behind hardware virtualization, so a heap overflow in an EXR reader gets you a compromised throwaway machine containing exactly one customer's scene. A container would have handed the same exploit a shared host kernel to pivot into. A container is a set of namespaces and cgroups around a process on your kernel — good hygiene, not a boundary.

The resource shape that breaks shared pools

Here is the operational failure that pages people, and it involves no attacker at all. Rendering is the least-bounded workload most teams ever run. The cost of a frame is a function of geometry after modifiers, texture resolution after loading, sample count, bounce depth, and the shape of a node graph — none of which you know until you have already committed the memory.

• One extra subdivision level is a 4x geometry multiplier — and it multiplies again per level. An artist (or an agent) bumping a subdivision modifier from 3 to 5 is a sixteen-fold increase in vertex count, applied at evaluation time, after the file was accepted.
• An 8K displacement map is not an 8K file — it is 8192 x 8192 floats resident, per channel, plus whatever the displacement generates in actual geometry. The file on disk may be a few tens of megabytes.
• Sample counts are a single integer — an agent that writes `samples = 10000` instead of `100` has not written invalid code. It has written a job that runs a hundred times longer, and nothing in the script will look wrong on review.
• Geometry nodes can instance without bound — a graph that scatters instances based on a computed density can produce an instance count nobody predicted, including the person who wrote the graph. Procedural generation is a loop whose trip count is data.
• Render times are legitimately long — this is the part that makes naive timeouts useless. A real CPU render taking forty minutes is not a bug, so you cannot distinguish "working" from "wedged" by duration alone. You need a hard ceiling per job plus resource fencing, not a heuristic.
• Failure is bimodal — jobs either fit comfortably or fall off a cliff. There is very little middle ground where a render is "a bit" over budget, which is why capacity planning by average never works here.

Now put twelve tenants on one render host. One of them ships a scene with a runaway instance count. Memory climbs, the kernel's OOM killer wakes up, and it reaps whichever process has the fattest score. That might be the offending render. It might just as easily be a perfectly reasonable thirty-eight-minute job at minute thirty-seven, belonging to someone else, who will now get an email saying their render failed and should please try again. The OOM killer does not care whose job was reasonable. It is not a scheduler; it is a fire axe.

Fences inside the guest

The guest's baked vCPU and RAM allocation is the outer wall — a render that exceeds it kills the guest, which is a contained, attributable event rather than a fleet incident. Inside that wall it's still worth setting explicit limits, because a failure that happens predictably in userspace gives you an error message, an exit code, and a report, while a failure that happens at the kernel level gives you a truncated log and a shrug.

# Runs INSIDE the per-job microVM, never on your host.

# --- The environment is a pinned INPUT, not ambient state ---------------
# A render that quietly changes because a base image bumped the color
# config is a support ticket you will not be able to answer.
export OCIO=/opt/blender/datafiles/colormanagement/config.ocio
export LC_ALL=C.UTF-8
export TZ=UTC
export PYTHONHASHSEED=0
export BLENDER_USER_SCRIPTS=/var/empty   # no user add-on dir to scan or load

# --- Hard fences. The guest's baked vCPU/RAM is the outer wall; these
# make the failure land in userspace with an exit code, instead of as an
# abrupt kernel-level execution forty minutes into a job. ----------------
ulimit -v 12582912   # 12 GiB address space -- the subdivision modifier dies
ulimit -f 8388608    # 8 GiB per file -- no accidental 40 GB EXR sequence
ulimit -t 3600       # 3600s CPU -- a runaway node graph gets reaped
ulimit -c 0          # no core dumps of a scene we are about to destroy

# --- The render ---------------------------------------------------------
# --factory-startup : ignore user preferences AND the user add-on
#                     directory. The scene renders on the toolchain we
#                     baked, not one it talked the machine into fetching.
# --disable-autoexec: refuse to execute Python embedded in the .blend on
#                     load. This is already the default. Set it anyway --
#                     defaults are a property of a version, and necessary
#                     is not the same as sufficient (we still run --python).
# --python-exit-code: turn a Python traceback into a non-zero exit rather
#                     than a cheerful 0 with no frames written.
# Everything after a bare -- is argv for OUR script, not for Blender.
timeout --signal=KILL 3600 \
  blender --background \
    --factory-startup \
    --disable-autoexec \
    -noaudio \
    /work/scene.blend \
    --python-exit-code 71 \
    --python /work/render_job.py \
    -- --seed "$RENDER_SEED" \
       --max-samples "$SAMPLE_CAP" \
       --out /work/out/frame_####.exr

rc=$?
if [ "$rc" -ne 0 ]; then
  # Staged output is discarded, not published. Zero frames beats one
  # wrong frame that a customer signs off on.
  echo "render failed rc=$rc" >&2
  exit "$rc"
fi

# The toolchain goes in the job report. "We changed nothing" should be a
# claim you can check, not one you have to believe.
blender --version | head -1        >  /work/out/toolchain.txt
sha256sum "$OCIO"                  >> /work/out/toolchain.txt
/usr/bin/time -v true 2>/dev/null  >> /dev/null || true

Note the ordering discipline: Blender processes command-line arguments in the order given, so `--factory-startup` and `--disable-autoexec` come before the scene file, and the scene file comes before `--python`. Getting that order wrong is a quiet way to load a file under settings you thought you had already replaced.

Egress: the agent wants to download things

Every 3D pipeline grows a fetch step. HDRIs come from an asset library. Textures are referenced by URL. An agent decides it needs an add-on for a format it hasn't seen. A USD composition references a layer on a remote path. Each of those is your render process making an outbound request on behalf of instructions it did not write.

The default should be deny, with an allowlist for exactly the hosts your own asset store lives on. This is the same argument I made in /blog/controlling-network-egress-untrusted-code, and it applies with extra force here because the render process is long-lived enough to be a comfortable place to sit. What per-sandbox network namespaces buy you specifically is that the policy is per *job* rather than per *fleet*: each PandaStack sandbox gets its own netns and TAP device, so a tenant whose pipeline legitimately needs to reach one external CDN doesn't force you to open that CDN for everyone.

• Deny by default, allowlist by hostname — your object store, your asset CDN, nothing else. Not "the internet minus a blocklist", which is a blocklist you will maintain forever and lose.
• Block link-local hard — the cloud metadata address is the single most valuable thing a render process can reach, and "fetch this texture from a URL" is a request-forgery primitive handed to you gift-wrapped.
• Resolve and fetch outside the guest where you can — the orchestrator downloads the asset, checks its size and type, and writes it in. Then the guest needs no egress at all, which is the easiest policy to reason about.
• Treat add-on installation as a build-time decision — if a format matters, bake support into the template and rebuild. If it doesn't matter enough to bake, it doesn't matter enough to `pip install` at render time.
• Log every allowed request against the job id — one job, one machine, one netns, so the network log is unambiguous. Attribution is free when the unit of isolation matches the unit of work.

Determinism, or: "the render changed and we didn't change anything"

Rendering is one of the few workloads where customers diff the output pixel by pixel. A product configurator that renders a sofa needs the blue one and the green one to differ only in the fabric. A regression suite for a generative-3D model needs today's output to be comparable with last month's. And when a customer says the render changed, you need to be able to say what changed — which means everything that could have changed has to be pinned and recorded.

• Pin the renderer version — a minor Blender release can change sampling, denoising, or a shader node's behaviour. That is a legitimate improvement and a breaking change at the same time.
• Pin the color config — OCIO configs define view transforms and display spaces. A different config is a different image, and it is the single most common cause of "the colors shifted" reports.
• Pin the seed — set it explicitly per job and record it. Cycles takes a seed; "random per frame" is a checkbox that will ruin your regression suite.
• Pin thread count where output depends on it — some renderers and denoisers are not bit-identical across thread counts. If yours isn't, the thread count is an input, not a tuning knob.
• Record everything in the report — renderer version, OCIO config digest, seed, sample count, denoiser, and the digest of every input asset. A report that lets you reproduce the run is worth more than one that describes it.

This is where snapshot-restore earns its place for reasons that have nothing to do with security. A PandaStack template's first spawn is a real cold boot of about 3 seconds; every create after that restores the baked snapshot — roughly 49ms for the restore step, 179ms p50 end to end and about 203ms p99. Every render job therefore starts from a byte-identical machine: same Blender build, same OCIO config, same libc, same OpenEXR, same everything. That is a much stronger guarantee than a container image tag, which pins a manifest but not the ambient state of the process that eventually runs. The same argument shows up in /blog/reproducible-build-sandboxes; rendering just has a customer who can see the difference.

The job shape: staged output, no credentials, one report

The design rule is the same one that makes import and billing pipelines survivable: the guest is pure. It reads inputs, produces artifacts into a staging directory, and writes a report. It holds no credential for your object store, no write key for the asset library, and no database DSN. It cannot publish, so a compromised or confused render cannot publish something wrong. The trusted orchestrator reads the staged artifacts out, checks them against the report, and uploads.

from pandastack import Sandbox
import json

class RenderFailed(Exception):
    pass


def run_render_job(job_id: str, tenant: str, scene_bytes: bytes,
                   agent_script: str, seed: int, max_samples: int) -> dict:
    """Run ONE agent-authored render in a machine that exists only for it.

    We are not going to review `agent_script`. Reviewing model output per
    job does not scale and does not work. We are going to run it somewhere
    its worst plausible behaviour is a machine we delete afterwards.
    """
    sbx = Sandbox.create(
        template="blender-cpu",     # custom template: toolchain baked in
        ttl_seconds=5400,           # renders are legitimately long.
                                    # Wedged renders are not.
        metadata={"job": job_id, "tenant": tenant, "kind": "render"},
    )
    try:
        # The untrusted bytes go in. Note what does NOT go in with them:
        # the object-store write key, the asset-library token, any other
        # tenant's scenes. The guest can produce files. It cannot publish.
        sbx.filesystem.write("/work/scene.blend", scene_bytes)
        sbx.filesystem.write("/work/render_job.py", agent_script)
        sbx.filesystem.write("/work/fences.sh", FENCES_SH)

        out = sbx.exec(
            "cd /work && mkdir -p out && "
            f"RENDER_SEED={seed} SAMPLE_CAP={max_samples} bash fences.sh",
            timeout_seconds=5100,   # inside the TTL, so the guest reaps
                                    # anything this call fails to catch
        )

        # FAIL CLOSED. A segfault in the EXR writer, an OOM from an 8K
        # displacement map, a 10,000-sample accident hitting the CPU
        # ulimit, and a traceback in the agent's script all land here --
        # and all produce exactly zero published frames.
        if out.exit_code != 0:
            raise RenderFailed(
                f"{job_id}: rc={out.exit_code} {out.stderr[-4000:]}"
            )

        # The report is the contract: renderer version, OCIO digest, seed,
        # samples, peak RSS, wall time, and a digest per frame. If you
        # cannot reproduce a render from its report, you do not have one.
        report = json.loads(sbx.filesystem.read("/work/out/report.json"))
        frames = {
            name: sbx.filesystem.read(f"/work/out/{name}")
            for name in report["frames"]
        }

        # The guest's own accounting has to agree with what it handed us,
        # or something was truncated and we publish nothing.
        if len(frames) != report["frame_count"]:
            raise RenderFailed(f"{job_id}: staged {len(frames)} frames, "
                               f"report claims {report['frame_count']}")

        return {"report": report, "frames": frames}
    finally:
        # The scene, the textures, the agent's script, the temp caches,
        # and anything the scene did to the machine all end together.
        sbx.kill()

The report is worth designing properly rather than treating as logging. Renderer version, OCIO config digest, seed, sample count, denoiser setting, peak RSS, wall time, and a content digest per output frame. Peak RSS in particular is the number that tells you whether a tenant is approaching the cliff, and it's only meaningful because the guest ran exactly one job — on a shared host, peak RSS is a property of the neighborhood.

Snapshot after scene load, then fork per variation

Now the part that changes the economics rather than just the safety. Product configurators and generative-3D evaluation both have the same shape: one scene, many variations. Eleven fabrics. Six camera angles. Four lighting setups. Sixty-four permutations of a material graph. The expensive, identical prefix of every one of those jobs is loading the scene — parsing geometry, resolving linked libraries, decoding and tiling every texture, building acceleration structures. On a multi-gigabyte scene that is minutes, and the naive pipeline pays it N times.

So don't. Load the scene once, snapshot the machine in that loaded state, then fork the snapshot per variation. A same-host fork on PandaStack is 400–750ms (cross-host is 1.2–3.5s), because the fork reflinks the rootfs and restores memory copy-on-write rather than re-doing any of the work. Each child wakes up with the scene already parsed and the textures already resident, changes one parameter, and renders. I covered the general mechanism in /blog/snapshot-and-fork-explained; a render sweep is close to the ideal case for it, because the shared prefix is enormous and the per-variant delta is a handful of properties.

from concurrent.futures import ThreadPoolExecutor
from pandastack import Sandbox
import json


def render_sweep(job_id: str, scene_bytes: bytes, variants: list[dict],
                 seed: int) -> list[dict]:
    """One scene parse, N renders.

    The naive version pays the multi-gigabyte scene load once per variant.
    This pays it once, freezes the loaded state, and forks from there.
    """
    parent = Sandbox.create(
        template="blender-cpu",
        ttl_seconds=7200,
        metadata={"job": job_id, "role": "sweep-parent"},
    )
    try:
        parent.filesystem.write("/work/scene.blend", scene_bytes)
        parent.filesystem.write("/work/fences.sh", FENCES_SH)

        # Parse geometry, resolve linked libraries, decode and tile every
        # texture, build acceleration structures -- everything that is
        # IDENTICAL across all N variants. Then stop, before rendering.
        warm = parent.exec(
            "cd /work && bash preload_scene.sh scene.blend",
            timeout_seconds=1800,
        )
        if warm.exit_code != 0:
            raise RenderFailed(f"{job_id}: scene preload {warm.exit_code}")

        # Freeze the loaded state. Every child descends from this exact
        # machine, which also means every child has a byte-identical
        # toolchain -- the comparison across variants is honest.
        parent.snapshot()

        # Same-host fork: 400-750ms per child, versus minutes to re-parse.
        children = parent.fork_tree(
            len(variants),
            metadata={"job": job_id, "role": "sweep-child"},
        )

        def render_one(pair):
            child, variant = pair
            try:
                # Forked guests share the parent's entropy and RNG state.
                # Derive a DISTINCT, RECORDED seed per variant rather than
                # letting the renderer pick -- otherwise "random" means
                # "identical" across the fan-out, which is a confusing
                # afternoon of debugging noise-free noise.
                variant = {**variant, "seed": seed + variant["index"]}
                child.filesystem.write(
                    "/work/variant.json", json.dumps(variant, sort_keys=True)
                )
                out = child.exec(
                    "cd /work && bash fences.sh --variant variant.json",
                    timeout_seconds=1800,
                )
                if out.exit_code != 0:
                    return {"variant": variant, "error": out.stderr[-2000:]}
                return {
                    "variant": variant,
                    "report": json.loads(
                        child.filesystem.read("/work/out/report.json")
                    ),
                    "frame": child.filesystem.read("/work/out/frame_0001.exr"),
                }
            finally:
                child.kill()

        with ThreadPoolExecutor(max_workers=16) as pool:
            return list(pool.map(render_one, zip(children, variants)))
    finally:
        parent.kill()

The seed detail in that code is not decoration. Forked guests inherit the parent's memory, which includes seeded RNG state, so a fan-out that relies on the renderer choosing a random seed will produce N identical "random" results — a genuinely disorienting bug, and one of a family described in /blog/snapshot-clone-randomness-problem-explained. Derive the seed explicitly from the variant index, record it in the report, and the sweep becomes reproducible as a set rather than merely as individual jobs.

Where this doesn't apply: GPU rendering

I want to be plain about this rather than let it sit as an implication. Firecracker does not give you GPU passthrough. It deliberately exposes a minimal device model — a handful of virtio devices — and that minimalism is exactly why the hypervisor attack surface is small enough to run untrusted code on. PCIe passthrough of a discrete GPU is not part of that model. If your pipeline needs CUDA or OptiX, this is a different substrate and you should evaluate it separately; the honest options there are dedicated GPU hosts or a GPU cloud, with a correspondingly different isolation story that you should reason about on its own terms.

What this pattern does cover is a large and often-underestimated share of real 3D work: CPU rendering with Cycles or an equivalent, format conversion and validation (STEP or IGES to mesh, FBX to glTF, mesh to USD), decimation and LOD generation, UV unwrapping and baking, thumbnailing and preview generation, rigging and animation-export checks, and — the reason you're probably here — running agent-authored scripts against scenes at all. Most of that is CPU-bound and embarrassingly parallel, which is the workload shape microVM fan-out is best at. Image generation has an analogous split, and I sketched it in /blog/microvm-genai-image-generation-isolation.

Shared render host vs container per job vs microVM per job

• Script execution on file open — Shared render host: a scene with embedded Python or a registered handler runs code in a long-lived process that has seen every tenant's assets and holds your asset-store credentials. Container per job: the code runs confined to the container, which is real progress, but the container shares your kernel and often your credential-bearing environment. MicroVM per job: the code runs in a guest with its own kernel, no credentials, and a lifetime measured in minutes.
• Parser exploitation — Shared render host: a heap overflow in an EXR, TIFF, or Draco decoder is host compromise. Container per job: better containment, but a kernel-reachable bug in the parsing path is still a host problem, because there is exactly one kernel. MicroVM per job: hardware-virtualized boundary; a successful exploit owns a throwaway machine containing one customer's scene.
• Runaway resource use — Shared render host: one runaway instance count or 8K displacement map drives the box into OOM and the kernel reaps whichever job looks tastiest, including a stranger's forty-minute render at minute thirty-seven. Container per job: cgroup memory limits genuinely help, though CPU and I/O contention still cross the boundary and a container OOM is often less legible than you'd like. MicroVM per job: fixed vCPU/RAM baked into the guest plus a hard TTL, so a pathological scene exhausts its own machine and is reclaimed automatically.
• Egress control — Shared render host: policy is per fleet, so the union of every tenant's legitimate asset sources is the policy for all of them. Container per job: per-container network policy is achievable and commonly skipped, because it is a separate system from the thing that launches the job. MicroVM per job: each sandbox already has its own network namespace and TAP device, so a default-deny allowlist is per job by construction.
• Reproducibility — Shared render host: Blender build, OCIO config, and library versions are whatever the host has drifted to, so "nothing changed" is unfalsifiable. Container per job: an image tag pins the filesystem, which is most of the way there, though the running process still inherits host kernel and ambient state. MicroVM per job: every job restores the same snapshot generation of the same guest, byte-identical, including the guest kernel.
• Attribution — Shared render host: peak RSS and CPU seconds describe the neighborhood, not the job, so "why was mine slow" has no honest answer. Container per job: cgroup accounting is decent per container. MicroVM per job: one job, one machine, one log stream, one resource profile you can put in front of a customer.
• Cost of isolation — Shared render host: effectively free per job, which is why everyone starts here and why every render pipeline eventually acquires an incident. Container per job: cheap, plus an image pull the first time on each node. MicroVM per job: on PandaStack a create is 179ms p50 (~203ms p99) because every create restores a baked snapshot rather than cold-booting, and a same-host fork for a sweep variant is 400–750ms. In front of a render measured in minutes, that is a rounding error.
• Sweep economics — Shared render host: N variants means N scene loads unless you build your own in-process variant loop, which reintroduces shared fate between variants. Container per job: same, since containers don't share a warmed process state across instances. MicroVM per job: snapshot after scene load, fork per variant, pay the parse once.

The cost row is what makes the whole design practical rather than aspirational. "One VM per render job" sounds extravagant until the create is a fifth of a second in front of a job that takes twenty minutes. Capacity holds up too: each PandaStack agent pre-allocates 16,384 /30 network subnets, so concurrency is bounded by host CPU and memory — which for rendering it always was — rather than by network slot exhaustion when a configurator's sweep fans out two hundred variants at once.

The summary

3D pipelines look like file processing and behave like code execution. A `.blend` can carry Python that runs on load; disabling auto-run is necessary and does not help you, because the agent's whole purpose is to write a script you then execute. Underneath that sits the parser layer — EXR, TIFF, PNG, Draco, OpenVDB, USD, FBX — a large amount of C reached by bytes a stranger chose, in a process that in most architectures holds the credentials to your asset store. And on top of it sits a workload whose resource cost is unknowable until you have already committed the memory, running next to eleven other tenants under an OOM killer with no opinion about fairness.

One disposable microVM per job addresses the whole family at once. Embedded scripts and agent-authored scripts both run in a guest with its own kernel and no credentials. Parser exploitation lands in a machine containing exactly one customer's scene. Runaway geometry exhausts a fixed budget and gets reclaimed by a TTL instead of taking down neighbors. Egress is default-deny per job rather than per fleet. Determinism comes from restoring the same snapshot every time, so the toolchain is byte-identical run to run and "we changed nothing" is checkable. And the sweep pattern — snapshot after scene load, fork per variation — turns the most common real workload in this space from N scene parses into one, at 400–750ms per fork.

The one thing this pattern doesn't do is GPU rendering, and no amount of enthusiasm changes that: Firecracker's device model is minimal on purpose, and that minimalism is the same property that makes it safe to run a stranger's scene file. CPU renders, format conversion, validation, baking, thumbnailing, and agent scripting are the target. That's most of the pipeline, and it's all of the part that runs untrusted input.

For adjacent patterns: media transcoding on untrusted uploads is in /blog/microvm-ai-agent-video-transcoding-isolation, per-job egress policy in /blog/controlling-network-egress-untrusted-code, the fork mechanics behind the sweep in /blog/snapshot-and-fork-explained, the randomness trap that bites every fan-out in /blog/snapshot-clone-randomness-problem-explained, and the general case of hostile files meeting permissive parsers in /blog/microvm-per-tenant-csv-import-pipeline-isolation.