I built a runtime to isolate untrusted code using wasm sandboxes.
Basically, it protects your host system from problems that untrusted code can cause. We’ve had a great discussion about sandboxing in Python lately that elaborates a bit more on the problem [1]. In TypeScript, wasm integration is even more natural thanks to the close proximity between both ecosystems.
The core is built in Rust. On top of that, I use WASI 0.2 via wasmtime and the component model, along with custom SDKs that keep things as idiomatic as possible.
For example, in Python we have a simple decorator:
from capsule import task
@task(
name="analyze_data",
compute="MEDIUM",
ram="512mb",
allowed_files=["./authorized-folder/"],
timeout="30s",
max_retries=1
)
def analyze_data(dataset: list) -> dict:
"""Process data in an isolated, resource-controlled environment."""
# Your code runs safely in a Wasm sandbox
return {"processed": len(dataset), "status": "complete"}
import { task } from "@capsule-run/sdk"
export const analyze = task({
name: "analyzeData",
compute: "MEDIUM",
ram: "512mb",
allowedFiles: ["./authorized-folder/"],
timeout: 30000,
maxRetries: 1
}, (dataset: number[]) => {
return {processed: dataset.length, status: "complete"}
});
It's still quite early, but I'd love feedback. I’ll be around to answer questions.
That being said this is useful even if it wasn't for the running AI agent code aspect, being able to limit ram and cpu usage and time outs makes it easier to run coding based games/applications safely (like battle snakes and Leetcode)
I made a small example that might give you a better idea (it's not eval, but shows how to isolate a specific data processing task): https://github.com/mavdol/capsule/tree/main/examples/javascr...
And yes, you are spot on regarding LeetCode platforms. The resource limits are also designed for that kind of usage.
import { task } from "@capsule-run/sdk";
export default task({
name: "main",
compute: "HIGH",
}, async () => {
const untrustedCode = "const x = 10; x * 2 + 5;";
const result = eval(untrustedCode);
return result;
});
At that point it might be just easier to convince the model to write JS directly
It's not too hard to compile a C extension for Python to a WebAssembly and bundle that in a .so file in a wheel. I did an experiment with that the other day: https://github.com/simonw/tiny-haversine?tab=readme-ov-file#...
Since the runtime uses standard WASI and not Emscripten, we don't have that seamless dynamic linking yet. It will be interesting to see how the WASI path eventually converges with what Pyodide can do today regarding C-extensions.
componentize-py – Python to WebAssembly Component compilation
+
jco – JavaScript toolchain for WebAssembly Components
I'm curious how Wasi 0.3 cross language components will go for something like this.
That's the crux of how usable this is going to be for people's use cases, and it's better to document the limitations upfront.
For Python, the main limitation is indeed C extensions. I'm looking for solutions. the move to WASI 0.3 will certainly help with that.
I'd find this a lot easier to trust it if had the Python code that runs in WASM as an entirely separate Python file, then it would be very clear to me which bits of code run in WASM.
Posted this yesterday as well, but seems like a really nice emerging pythonic way to call out to remote infrastructure (see: Modal[1]).
[1]: https://modal.com/docs/examples/hackernews_alerts#defining-t...