Skip to content

Forum

AI Assistant
Notifications
Clear all

Walkthrough: From zero to a secure, signed WASM tool pipeline in CI/CD.

1 Posts
1 Users
0 Reactions
3 Views
(@bella_selfhost)
Active Member
Joined: 1 week ago
Posts: 8
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#986]

Hey everyone! I've been diving deep into the whole "WASM as a sandbox for AI agents" idea for my home lab, and I keep seeing people talk about it like it's magic security pixie dust. The reality is more nuanced, and honestly, the *tooling* part is where most guides fall short. So I wanted to document my journey setting up a proper, secure pipeline for building and signing WASM modules meant to run agent tools.

The goal was simple: take a simple tool (let's say a calculator function that an agent could call), compile it to WASM, and get it from a git commit to a deployed, verifiable artifact without me manually touching anything. The trick is making sure the WASM module that ends up running is *exactly* the one that came from my trusted source code.

Here's the rough pipeline I built using GitHub Actions and `wasm-tools`:

* **Source:** A Rust crate in a monorepo (could be any WASM-compatible lang, but Rust's `wasm32-wasi` target is lovely).
* **CI Trigger:** On a push to main, the workflow kicks off.
* **Build Step:** Compiles the crate to `wasm32-wasi`, producing a `.wasm` file.
* **The Critical Signing Step:** This is where the real sandboxing trust starts. I use `wasm-tools sign` to add a cryptographic signature to the module. The private key for signing is stored in GitHub Secrets.
* **Verification & Registry:** The signed module is pushed to a private OCI registry (I use my local Harbor instance). Any runner in my lab that pulls and runs this module *must* verify the signature with the public key before execution.

The real "aha" moment for me was understanding the limits. This signing proves the module hasn't been tampered with *after* I built it, and the WASM runtime provides isolation. But it doesn't magically make the tool's *logic* safe—a malicious `calculate()` function could still try to burn CPU cycles. The isolation is real (no arbitrary syscalls unless you explicitly give it via WASI), but it's not a substitute for careful code review of the tool itself.

For my lab, this is perfect. I can have my local LLM agents safely call these signed, sandboxed tools for network scans, log parsing, or smart home controls without giving them the keys to the whole kingdom. It's a fantastic middle ground between "run nothing" and "run anything."

Has anyone else set up something similar? I'm particularly curious about how you're handling the public key distribution for verification across your worker nodes. I'm currently baking them into my runner images, but that feels a bit clunky.


selfhost or die


   
Quote