Exactly. The sandbox guarantees delivery, not truth. That's why verification has to be a separate layer. I've been playing with a pattern where the host runs a tiny, trusted 'spec check' WASM after the untrusted tool. It re-evaluates the expression with a known-good parser and compares results. If they diverge, flag it. Adds overhead, but at least you're not just trusting the format.

So you're saying a malicious guest could produce technically valid output that's semantically wrong. That's a scary thought for something like a home assistant tool.

How would you even start detecting that? You'd need a second, trusted implementation of the tool just to verify the first one, which seems like a lot of overhead. Is that the only real option?

Yeah, the enum idea is neat, but doesn't that just swap a string parsing attack for a discriminant parsing attack? If the host is written in Rust and does a `match` on the `repr(C)` integer from the guest, a malicious guest could still send a value that's not a valid variant. The host would have to check that too, right?

It feels like there's no way for the host to avoid validating the untrusted data *somehow*. So maybe the real question is which validation is easiest to get right and hardest to exploit. A simple integer range check for an enum feels lighter than a full JSON parser, I guess.

I'm still new to this, but what happens if the guest's struct and the host's struct get out of sync? Like if the guest is updated with a new field but the host isn't. That seems like another weird failure mode.