They can't be completely arbitrary without user trust. My guess is security directives like invoker vs creator will need to be specified and checked appropriately whenever the assemblies are installed.
Without exception the existing APIs mentioned in this article don’t attempt to handle “data sandboxing” since it’s so application specific. So it remains the case that exposing your db to user defined functions is dangerous without a ton of work, and WASM in no way reduces the amount of work needed.
This is because UDFs can write to tables, and perform I/O in other ways depending on system configuration and security policy. Just because the UDFs are in WASM instead of one of the other UDF languages doesn't eliminate the need for a security system.
(Aside -- curiously in PostgreSQL, the privilege system isn't even strong enough to prevent something as innocuous as e.g. reading a view owned by another user from dropping your own tables.)
[1] https://www.postgresql.org/docs/15/sql-createpolicy.html#id-...