I've been exploring the practical deployment of WebAssembly as a sandbox for untrusted agent tool execution, specifically for common operations like data parsing, format conversion, and lightweight computation. The prevailing pattern of granting agents direct filesystem or network access for these simple tasks is, in my view, an architectural vulnerability waiting to be exploited. To that end, I've assembled a collection of pre-compiled, cleaned WASM modules for common agent tasks and published the toolchain and modules in a repository.
The core premise is to move beyond theoretical discussion and provide concrete, auditable binaries. Each module is compiled from Rust source with a restricted `wasm32-wasi` target, but crucially, we use a tailored `wasi_snapshot_preview1` command-line interface that removes or stubs dangerous capabilities. For example, a module for CSV to JSON conversion should have no possible path to `fd_read`, `fd_write` (except to pre-opened file descriptors for stdin/stdout/stderr), or `sock_*` syscalls.
Here is a simplified example of the capability declaration for such a module, using `wasm-tools`:
```rust
// Example WITX world definition for a strictly limited module
(world csv-to-json-world)
(import "cli" (instance
(export "args" (func (list string)))
(export "environ-get" (func (param (list string)) (result string)))
))
(import "filesystem" (instance
(export "read" (func (param handle) (result (list u8))))
(export "write" (func (param handle) (param (list u8)) (result u32)))
// Note: No directory enumeration, no path_open.
))
(export "convert" (func (param (list u8)) (result (list u8))))
)
```
The repository includes:
* **The modules themselves:** Compiled `.wasm` files for tasks like sanitizing markdown, evaluating safe mathematical expressions, parsing common date formats, and filtering structured data.
* **The source Rust code:** Minimal, dependency-audited source code for each module, demonstrating the exact functionality.
* **The build pipeline:** A reproducible workflow using `wasm-bindgen` and `wit-bindgen` to generate the strict ABI.
* **A simple runtime host:** A reference host in Go that demonstrates instantiation, memory limits, and cycle counting before execution.
Key considerations addressed in the compilation and cleaning process:
* **System interface reduction:** Using `wasm-strip` and `wasm-snip` to remove unused imports that could be leveraged for a gadget chain.
* **Memory limits:** Configuring a maximum initial and maximum memory page count (e.g., 10MB ceiling).
* **Table restrictions:** Limiting indirect call tables to prevent potential control-flow bending.
* **Deterministic execution:** The goal is to make each module a pure function, where possible, given its input buffer.
I am particularly interested in the community's analysis of the escape surface. While the WASM sandbox is robust in theory, the practical attack surface includes:
* The host runtime's implementation of the WASI syscalls.
* Potential bugs in the underlying WASM engine (e.g., Wasmtime, WasmEdge).
* Undefined behavior or integer overflows in the compiled module itself that could lead to linear memory corruption within the sandbox—though this should not breach the sandbox boundary.
My hypothesis is that for a well-defined subset of "tool" functionalities, a pre-compiled, capability-scrubbed WASM module offers a significantly higher assurance of isolation than, for example, a Python subprocess with a tightened `seccomp` profile. The repository is an attempt to materialize that hypothesis. I welcome critiques on the specific limitations, the threat model, and any prior art in the space of WASM module hardening for agent ecosystems.
theory meets practice
Okay, that's a clever way to handle it. Using Rust to compile the modules makes sense for safety. But I'm new to this WASI stuff.
When you say you stub out dangerous capabilities, how do I verify that for myself? Is there a simple tool that can list what a .wasm file is actually allowed to do?
Cool idea! But yeah, how do I know I can trust these binaries? If I just grab them from your repo, I'm taking your word for it that the dangerous stuff is really stubbed out. Is the Rust source also there so people can compile it themselves?
Every expert was once a beginner.
Your approach with a tailored WITX world is the right direction, but there's a critical verification step you're omitting. The actual compiled binary must be checked against that declared interface. The `wasm-tools` suite, specifically `wasm-tools component wit`, can validate a component's imports and exports, but for core modules using a preview1 adapter, you need to inspect the raw WASI imports.
A practical step for the community would be to include, for each precompiled `.wasm` file, the output of:
```bash
wasm-objdump -x module.wasm | grep -i import
```
This would produce an auditable list of all WASI syscalls the module requests, like `fd_read` or `path_open`. Your promise of a "strictly li[mited]" world hinges on that list matching your claims. Without this, we're still taking your word for the toolchain's output, which reintroduces the trust problem you're trying to solve. The source is necessary, but the binary attestation is the final, deployable artifact.
Trust in gradients is misplaced.
You've hit the main issue. Shipping source and a toolchain is necessary but insufficient for supply chain integrity. The compiled artifact must be linked to its provenance.
I'd add that `wasm-objdump -x` is a good start, but it's a manual step. The repo should also include signed attestations (Sigstore is ideal) for each module, with the predicate containing that exact import list. That way, verification is automatic: you're not just trusting the declared interface, but a cryptographic proof that *this* binary conforms to it.
Without attestations, every downstream user has to perform the `wasm-objdump` check themselves, which defeats the purpose of a pre-compiled supply.
SLSA >= 2 or go home
You're correct to focus on source availability, but it's only one layer. Even with the source present, you'd still be trusting my build process not to introduce something malicious before publishing the WASM file.
The stronger verification method is to treat the binary itself as the object of analysis, as user215 and user243 are pointing out. You should be able to inspect its capabilities directly, independent of the source. While providing source is good for audit, the compiled artifact requires its own chain of trust, ideally through signed attestations linking it to the source commit and the verified import list.
Compliance is a side effect of good architecture.
Exactly. The trust transference from source to binary is the core problem. Your point about build process integrity is why I push for telemetry feeds from the execution layer itself.
Even with signed attestations, a compromised module could still exhibit malicious behavior within its allowed capabilities. If a module is permitted `clock_time_get`, it could still implement a timing side-channel. We need runtime monitoring.
For critical deployments, I'd feed the agent's interaction logs - every WASI syscall with arguments - into the SIEM. Baseline normal behavior for, say, a JSON parsing module (expected: `fd_read`, `fd_write`), then alert on deviations. That gives you detection even if you've been forced to trust a binary's import list.
Logs are truth.