Evidence note: This article rests on primary announcements and project self-descriptions — a project’s own landing page, vendor engineering blogs from Docker, NVIDIA, Google and Microsoft — read alongside one industry survey reported by a vendor. None of the capability claims below were independently tested or benchmarked for this article, and the distinction matters: a vendor describing its own security boundary is a statement of intent and design, not a verified result. Where a specific figure, benchmark or security property appears, its evidence level is marked at the claim. No measurement in this article was produced by running the software.
A multi-agent studio that ships as a single static HTML file
The artifact at the center of this piece is described by its own site as a browser-only studio for designing and orchestrating multi-agent Model Context Protocol systems — tool authoring, multi-agent orchestration, retrieval-augmented generation and code execution, all running from a single static HTML file through WebAssembly, with no backend at all (project’s own description; not independently verified, and no third-party review of the claim was located). That is the entire claim and also the entire distribution model: one file, opened in a tab.
It is worth being precise about what is and is not established here. The project’s feature list is a self-description. Sources outside the project do not corroborate the architecture, the component choices, or the security properties attributed to them. Everything in the next three sections should be read as "the project states" rather than "it has been shown that."
The reason the claim is interesting anyway is that it sits at one extreme of a question the rest of this development cycle spent considerable engineering effort on from the opposite direction. Docker, NVIDIA, Google and Microsoft all shipped work in the same window that assumes agent code needs a boundary — and in every case that boundary is a container, a policy engine, a cryptographic binding, or a virtual machine. A static HTML file proposes that the browser’s own sandbox is enough. Those are not the same bet.
Why a no-backend studio is attractive to a one-person team
For a solo developer or a two-person team, the appeal is not ideological. A backend is an on-call rotation. A container runtime is a thing that breaks on a Tuesday. A per-tenant isolation layer is a thing that has to be designed before it can be maintained. A single HTML file has none of those properties, and for a team whose actual product is a game or a tool rather than an agent platform, that asymmetry is the whole argument.
The trust environment makes the appeal sharper. The 2026 Stack Overflow Developer Survey found that only 7% of developers trust AI output for important decisions — a figure reported in Docker’s reading of the survey (vendor-reported survey figure; the survey instrument and question wording were not independently reviewed for this article). Taken at face value, that number describes developers who intend to supervise model output closely rather than delegate to it. A local, inspectable, disposable environment fits that posture better than a hosted service does: the code the model wrote is right there, and closing the tab ends the session.
The gap between "fits my posture" and "covers my risk" is where the rest of this article lives. Low trust in model output is not the same thing as a bounded blast radius for model execution, and the two get conflated whenever the word "sandbox" appears without a subject.
What stands between a model-written tool and execution here
According to the project’s own account, tool source — whether written by a language model or by hand — passes an abstract-syntax-tree validation step, is registered lazily, and is just-in-time compiled into Pyodide on first call (project’s own description; not independently verified). SQL tools are described as running in DuckDB compiled to WebAssembly inside a Web Worker (same source, same caveat).
Read as a design, that is a three-stage gate with distinct purposes. The syntax-tree pass is a static check: it can reject source whose shape is disallowed before anything runs. Lazy registration means a declared tool is inert until something calls it. The just-in-time compile into a WebAssembly Python runtime is where execution actually happens, inside the browser’s own isolation model rather than the host’s.
What the project asserts about that final stage is the load-bearing claim of the whole product: that the WebAssembly boundary is the sandbox, and that relying on it makes local execution of model-written code safe without Docker and without per-tenant containers (project’s own characterization, attributed on its site to the author; not independently verified, and no security audit of this claim was located). This specific claim deserves more skepticism than the architectural ones, because it is a security conclusion drawn by the party that benefits from it, about a boundary whose coverage is uneven in ways the next sections make concrete.
An earlier look at this pattern — browser orchestration and shared context across model-written tools — found the same structural move recurring across several studios in this cycle: the validation step is real, and it is doing a different job than the isolation step.
Where the data sits
The project describes its built-in retrieval layer as using a MiniLM sentence-embedding model through Transformers.js to compute embeddings on-device, with the consequence that no data leaves the browser and the whole stack is gone when the tab closes (project’s own description; not independently verified).
The privacy framing here is genuinely strong, and it is also narrower than it first reads. On-device embedding means the corpus is not transmitted to an embedding API. It does not mean the corpus is isolated from the agent — the retrieval index exists precisely so tools can query it. If model-written code runs in the same tab that holds the index, then the corpus is inside the boundary rather than behind one. That is a reasonable design for a developer indexing their own documents. It is a different proposition for anything containing credentials, customer data, or material a prompt-injected agent could be induced to exfiltrate through a tool it was permitted to call.
Ephemerality cuts both ways too. A stack that vanishes on tab close leaves no residue — and also no audit trail. For a solo developer that is a feature. For anything that later needs to answer "what did the agent do," it is an absence.
Ten strategies, one boundary
The project states that its agentic layer offers ten orchestration strategies, naming among them a Supervisor pattern that routes to a single expert, a Mixture of Experts pattern that runs experts in parallel and then synthesizes, a Sequential Pipeline, and Plan & Execute (project’s own description; the count of ten and the specific roster are not independently verified).
Multi-strategy orchestration is not a fringe direction. NVIDIA describes developers increasingly running multiple models in parallel and chaining inference calls rather than serving a single model, and demonstrates the pattern across eight DGX Spark nodes (vendor-reported demonstration; the node count and the generalization about developer behavior are the vendor’s own and were not independently verified). Google’s open-source Agent Development Kit, paired with a live Gemini model, is described as supporting non-blocking tools in Python plus response-scheduling behaviors — delivering a tool result when the conversation is idle, interrupting, or staying silent — to control when results land in a voice conversation (vendor-reported capability).
The structural observation is that orchestration count and boundary count are independent variables. Ten strategies inside one tab means ten ways to compose calls that all terminate in the same execution context, sharing the same filesystem shim, the same retrieval index, and the same network origin. Richer orchestration raises the number of distinct code paths that reach execution; it does not add a second wall. A supervisor that routes to one expert and a parallel ensemble that fans out to six have identical isolation properties when all of them compile into the same runtime.
What the rest of this cycle put around agent code instead
The same window produced a cluster of announcements whose common premise is that agent execution needs a boundary the agent cannot author its way out of.
Docker describes a system letting AI agents running in isolated Docker Sandboxes connect to one another, collaborate across environments, and have their access managed centrally — agents in separate sandboxes, with the connection as the managed surface (vendor-reported capability). The architectural inversion is worth noting: isolation is the default and communication is the thing that must be granted.
Google describes a reference build combining its enterprise agent platform, the Agent Development Kit, its data warehouse, and a four-gate defense-in-depth stack — a model-level input and output filter, a managed key service, binary authorization, and an open-source policy engine — to produce governed, self-evolving agents, and reports remediation of live production outages in 1.8 seconds (vendor-reported architecture and figure; the 1.8-second figure is the vendor’s own, with no methodology, workload definition or sample size independently reviewed here — treat it as an illustrative claim rather than a benchmark).
NVIDIA contributes two pieces. One is a runtime security product framed around a specific failure mode: that an agent can complete its assigned task and still cross a security boundary, with the vendor citing recent incidents of agents circumventing controls (vendor-reported framing; the incidents are referenced by the vendor and were not independently verified). The other is a reference architecture for securing and governing agent workloads at scale, addressed explicitly at autonomous agents that work for hours while reading files, calling tools and reaching the internet, and that spawn further agents to collaborate with (vendor-reported architecture).
That last description is the one to hold next to the browser tab. An agent that runs for hours, spawns children, and touches the network is not a shape a single page is built to contain — and, to be fair to the project, is not the shape it claims to serve.
A credential boundary is not a process boundary
Google’s identity platform is reported to have added support for Demonstrating Proof-of-Possession, sender-constraining refresh tokens by cryptographically binding the long-lived credential to the client that holds it, while leaving short-lived access tokens as ordinary bearer tokens (vendor announcement). The same material points developers integrating multi-agent or Model Context Protocol workloads toward a secure token service for token delegation across agent chains (vendor-reported, same source).
The asymmetry in that design is the practical takeaway, and it is stated plainly rather than buried: the durable credential becomes non-portable, and the short-lived one does not. A stolen refresh token stops being useful to a thief who cannot prove possession of the right key. A stolen access token remains a valid bearer credential for its lifetime. Agent architectures concentrate exactly the wrong thing here — long-running chains hold access tokens in memory, pass them between steps, and sometimes hand them to code a model wrote minutes earlier.
This is the clearest case of boundaries not substituting for one another. A WebAssembly boundary says something about what compiled code can reach on the host. It says nothing about whether a token sitting in page memory can be read by other code in that same page, or sent to an attacker-controlled origin by a tool that was legitimately granted network access. Proof-of-possession binding and process isolation address disjoint threats, and neither one implies the other.
The measurement consequence
Microsoft makes an argument in this cycle that connects isolation to something other than security: that an AI coding agent’s evaluation is only as valid as its sandbox, because a correct answer may come from information the agent found on the machine rather than from the model — which invalidates the measurement, not just the isolation (vendor-reported argument).
That is the quietest and most useful point in the whole cluster. A leaky boundary does not only create risk; it destroys the ability to know whether anything worked. If a benchmark task’s answer is reachable from the filesystem, a passing result measures the environment. PlayAgit’s earlier coverage of how the sandbox decides whether an evaluation counts traced the same failure through a different runtime.
Microsoft’s adjacent releases extend the theme toward the supply of context rather than its containment: a practitioner playbook described as a method for determining whether coding agents choose a technology’s SDK, version and patterns correctly — and for fixing the sources agents rely on when they do not (vendor-reported); a plugin mechanism described as a way to share agentic artifacts such as instructions, skills and tool configurations across teams while keeping consumers supplied with fixes, updated guidance and compatible configurations (vendor-reported); and a September 2026 editor update reported to let developers explore pull requests without leaving chat, bring their team’s trusted model, and fix vulnerable packages when the IDE flags them (vendor changelog). All three are capability descriptions from the vendor and were not independently verified.
Choosing between a tab and a container
Placing all of the above on one axis gives four distinct things the word "sandbox" is being asked to mean, and a browser-only WebAssembly boundary covers them unevenly.
Host isolation — can executed code read, write or persist outside its runtime? This is the browser’s strongest suit, and the one the project’s claim is most defensible on, though still unverified. For a solo developer running a model-written data transform over files they deliberately loaded, this may genuinely be sufficient.
Data isolation — is the corpus separated from the code that can query it? Here a single tab offers very little, by design. On-device embedding protects the corpus from the network, not from the agent. Anyone whose index would be damaging to leak needs separation the tab does not provide.
Credential isolation — can a token be used by something other than its intended holder? Not addressed by a WebAssembly boundary at all. This is what sender-constrained refresh tokens and delegated short-lived tokens exist for, and it is the gap that bites hardest the moment an agent touches a real API.
Measurement validity — can a result be trusted to reflect the model rather than the environment? Also not addressed, and worse in a tab than in a container, because an ephemeral stack leaves nothing to inspect afterward.
A reasonable decision rule follows from that table rather than from the word. Stay in the tab when the work is exploratory, the data is the developer’s own, the credentials are scoped to read-only or absent, and nobody will later need to prove what happened. Reach for a container when the agent runs long enough to spawn children or hold a session, for a policy gate when a human will have to justify an agent action to someone else, and for a sender-constrained credential as soon as a token outlives a single call — which, in practice, is almost immediately.
The comparison that has not been run, stated as a proposal
No measurement in this article is original. The obvious experiment has not been performed and is offered here only as a proposal, not as a result.
The design would be narrow enough to actually finish. Take one model-written tool with a deliberately boundary-probing shape — attempting a filesystem read outside its working set, an outbound request to an unexpected origin, and a read of a credential placed in the ambient environment. Run it twice: once under a browser-only WebAssembly boundary, once inside an isolated container. Record, per attempt, whether the operation succeeded, whether it was refused, and whether any trace of the attempt survived the session. Then run a second pass in which the task’s answer is planted on the host, to test whether either environment lets a correct result arrive without the model having reasoned to it.
That design would produce exactly four data points per environment, which is the point: it would replace the word "sandbox" with a per-threat answer. Until it runs, the honest position is that the browser-only claim is plausible for host isolation and silent on the other three, and that the vendors building containers, policy gates and proof-of-possession bindings around agent code are not solving a problem a static HTML file has already solved — they are solving different problems in the same sentence.
Developer takeaway: before adopting any agent runtime on the strength of its sandbox, ask which of the four boundaries that sandbox covers. A single answer for all four is the signal to keep asking.