The Stof open-source runtime, as its own page describes it, is built for logic you do not own or fully trust. It was presented in a Show HN post titled “Run AI-generated logic safely inside your app”, which makes the project’s page the only source we have.
In one sentence, the mechanism is this: a JSON-compatible document holds functions, and Stof instantiates that document as a small wasm environment. Its author says the functions cannot access or manipulate anything but their own document. Those are the author’s claims, BriefFlash has not tested them, and nothing in the material points to an independent review.
How does the Stof open-source runtime work?
Per the project’s page, a Stof document is a JSON document with functions inside it, and those functions are scoped to just the document that contains them. Stof instantiates the document as a small wasm environment, which the author says makes the functions safe to call.
The design choice that matters is that scope. Rather than giving a program a general-purpose engine and trying to restrict it, the project bundles logic with its data and treats that one document as everything the functions can see. If that holds, the boundary is simple to describe. Whether the implementation enforces it is a separate question the available text does not answer.
Stof is also called a superset of JSON by its author, meaning any valid JSON is valid Stof with extra capabilities such as functions, and the isolation guarantees are said to carry over. The project says documents can be sent over the wire easily, so one plausible use is an app receiving logic from a model or a third party as a document and running it in place. That reading is ours, not the project’s.
Why not use WebAssembly directly?
The author’s stated reason is practical: WebAssembly by itself is large in binary form and needs a lot of tooling. Stof is pitched as a lighter route to a similar kind of isolation. The material gives no sizes, benchmarks or overhead figures, so that comparison is unchecked.
Background, not a statement about Stof: WebAssembly (wasm) is a portable binary instruction format with a sandboxed execution model. It was designed for browsers and is now also used on servers to run code in isolation. How Stof compares with containers, JavaScript isolates or existing wasm runtimes is unknown, because nothing we have measures it.
Why does AI-generated logic raise the stakes?
Because running code directly inside an app gives that code the app’s own access. A model can produce code that is wrong or unsafe, and code can be shaped by untrusted input. Our coverage of a new study on how far AI agents are from autonomy is the reliability backdrop for why containing agent-generated logic is a live engineering concern.
What does a wasm sandbox cover, and what does it leave out?
A sandbox limits what code can touch; it does not judge whether the code is right. The table sets general sandbox background against what the Stof material says.
| Concern | General sandbox background | What the Stof material says |
|---|---|---|
| Reach into the host app | A sandbox is meant to confine code to what it is given | The author says functions cannot access or manipulate anything but their own document |
| CPU, memory and time | Resource exhaustion is a common weak point in any sandbox | Not stated; whether limits are enforced is unknown |
| Calls back into the host | The interface to the host app is another common weak point | Not stated in the available text |
| Wrong or manipulated output | Containment does not decide whether output is correct or safe to act on, and does not stop prompt injection | Not addressed |
We would ask about the host interface first. That is an inference from how sandboxes commonly fail, not a finding about Stof, and we hold it with moderate confidence: isolation inside the document means little if the way functions call back into the app is loose.
What do we not know about Stof yet?
Most of what a team would need to judge it. The available text is also cut off, so features beyond the pitch may exist.
- License: the project says open-source, but the material names no license.
- Authorship and maturity: who builds and maintains it.
- Performance and overhead against plain WebAssembly or other sandboxes.
- Whether CPU, memory and time limits are enforced on functions.
- How functions interact with the host application.
- Whether any independent security review or real-world adoption exists.
A Show HN post is not verification. Show HN is a section of a developer discussion forum where makers present their own projects, so a post there is self-description, not independent review.
Who might use Stof, and who should wait?
Developers and technical founders building apps or agents that must run AI-generated or third-party logic have reason to look, especially for prototypes. Teams handling sensitive data or hostile input should wait for answers to the gaps above. Before any production use, a team would reasonably check:
- The actual license and how the project is maintained.
- Whether resource limits exist and can be configured.
- What the host interface exposes to functions.
- Whether anyone independent has reviewed the isolation.
- How it behaves against deliberately hostile input in your own tests.
Frequently asked questions
What is Stof and who is it for?
Stof is a project that describes itself as an open-source runtime for logic you do not own or fully trust. It packs functions into a JSON-compatible document and runs them in a small wasm environment. It targets developers building apps or agents that must execute AI-generated or third-party logic, though its claims are the author’s and untested.
How is Stof different from using WebAssembly directly?
Its author says WebAssembly alone is large in binary form and needs a lot of tooling, while Stof can be sent over the wire easily and is a superset of JSON for compatibility. These are the project’s own comparisons. No sizes, benchmarks or overhead figures appear in the available material.
Does a sandbox make AI-generated code safe to run?
A sandbox limits what code can access, which helps contain mistakes. It does not decide whether the output is correct or safe to act on, and it does not prevent prompt injection or bad model output. Resource exhaustion and the interface to the host app are common weak points in any sandbox.
Is Stof truly open source, and under what license?
The project describes itself as open-source, but the material available to BriefFlash names no license, so we cannot confirm it. A license decides what developers may do with the code, so check the license terms the project publishes before building on it.
