Wait. I don't understand the threat vector modelled here. Any agent or two isolated ones that the do Webfetch and code exec, even in separate sandboxes, is pretty much game over as far as defending against threat vectors goes. What am I missing here?
Well, if wasm process is limited on the syscalls it can make, the blast radius is limited. For example you can block network access, and disk access for tools that don't need those capabilities.
That being said, this doesn't sound like they're really thinking through the risks.
> Dynamic Tool Building - Describe what you need, and IronClaw builds it as a WASM tool
If the agent can write it's own insecure plugins, and the wasm processes isn't properly isolated, you've really gained nothing.
even if it is isolated, like no network or host access. Like say the malicious prompt created a wasm tool that patched your project code to leak information like adding a logger.warning. but LOG_LEVEL was set to error or whatever that prevented this from surfacing during testing or dev/beta.
Again running on that was container that code does not reveal anything. But then another isolated wasm tool was responsible to build the binary and ship it to prod.
Shotgunned all over prod logs are spotted by a log watcher within minutes of deploy. Whew... right?
