WASI Preview 1, as an Erlang host interface.

Build an import map here when you want to choose exactly what a WASI program may reach. This is not an embedded WASI runtime: each syscall is an ordinary Erlang host function, so you can inspect it, trace it, replace it or refuse it, and the capability decisions are made in Erlang rather than inside somebody else's C library.

Grant capabilities explicitly, because nothing is ambient

Wasi = #{ stdout => group_leader(),
          dirs   => [{<<"/data">>, "/srv/app/data", read}],
          env    => #{<<"MODE">> => <<"production">>},
          args   => [<<"prog">>, <<"--flag">>],
          clocks => [monotonic],
          random => strong,
          net    => #{connect => [{tcp, <<"10.0.0.0/8">>, 443}]} },
{ok, Imports} = wasi_preview1:imports(Wasi).

Leave a key out and the module does not have that capability: the syscall returns ENOTCAPABLE. No dirs means no filesystem at all, not one rooted at the current directory. No net means no network at all, not a network restricted to somewhere sensible. No env means environ_get reports zero variables rather than leaking the host's. That is the opposite of the usual default, and it is the point: a module gets what you gave it and nothing else.

wasi_net parses the network grant, and wasi_sock runs the sockets behind it. docs/security.md says what a grant does not cover.

ENOTCAPABLE stays distinct from EACCES throughout, so the module (and whoever is debugging it) can tell "you were not granted this" from "the host operating system refused".

Path resolution, which is where sandboxes actually fail, is in wasi_path.