How do AI app builders run generated code safely?

Why generated code is untrusted code

Not because a model is malicious. Because nobody read it before it ran.

Two things follow. First, generated code can do something destructive by accident — delete a directory, exhaust memory, open a connection somewhere unexpected. Second, and less obviously, what a model writes is influenced by the text it is given, and that text can include content from elsewhere: a page it fetched, a file you uploaded, a dependency's README. Code that runs instructions that arrived from outside your conversation is exactly the thing sandboxing exists for.

The three strengths of isolation

Logical isolation means one system enforces separation between tenants in software. Your data is not accessible from another account because the application says so. It is a real control and the weakest of the three, because a bug in the enforcing layer is a bug in the boundary.

Container isolation gives each workload its own filesystem and process namespace while sharing a kernel with its neighbours. It is a strong practical boundary, and every serious platform hardens it further. Its limit is the shared kernel: a kernel exploit is a cross-tenant event.

Virtual machine or microVM isolation gives each workload its own kernel. This removes the largest escape class, at the cost of more resources per workload. It is where several platforms in this category are moving.

Most tools use a combination — for instance, containers for development workloads and something different for published apps.

The question most people forget to ask

Where does the preview run?

A preview feels like a rendering. It is an execution. If a tool is careful about published apps and casual about previews, the boundary you care about is the casual one, because previewing is what you do fifty times a day while building.

Ask three things of any tool: what is the boundary, does the preview run inside it, and is one project's boundary ever shared with another's.

What the documentation actually says

Some tools in this category document this well, and it would be dishonest to pretend otherwise. v0 states that each VM-backed chat has its own sandbox and that "files, env vars, and running processes never cross from one chat to another". Replit describes per-user isolated sandboxes on hardened containers, with a migration to microVMs publicly under way because there is no shared kernel. Both are more detailed on this than most.

Others are quieter. Lovable describes itself as "a multi-tenant platform with logical isolation between workspaces and projects". Base44 does not publicly document its isolation model at the time of writing.

sup3rapp runs every project in its own sandbox, previews included. On this specific axis we are not claiming to be ahead of Replit or v0 — we are claiming to be in the same category as them, and saying so plainly is more useful to you than a comparison table that pretends otherwise.

The other boundary: what the model can touch

Isolation is about where code runs. There is a second boundary about what the model can do at all.

In some systems the model has tools that write files and run commands directly. In others it proposes structured edit operations — create, replace, delete, rename — which a deterministic executor validates against an allowlist and applies atomically. The model itself has no filesystem and no network.

The second design means the boundary is a piece of ordinary software you can audit and test, rather than a set of instructions asking a model to behave. Given that the model's behaviour is probabilistic and the executor's is not, that is the safer place to put your trust.