Build Security
I am worried about an incomplete sandbox giving users false sense of security, but I also see upsides.
Users understand that running untrusted code can be dangerous, but it's surprising that merely viewing Rust code can be dangerous too! That's because an IDE may run cargo check or an LSP may run proc macros (which runs build.rs of its deps too, not only the macro). Some editors ask when opening a new project, or don't run anything until you save a file, but that's still a click away from accidentally running arbitrary code.
I don't think it's even feasible to properly isolate Rust libraries at run time to prevent malware from causing damage when run in the same process as trusted code, but for proc macros a WASM sandbox seems like an obvious choice that could improve safety and make them more deterministic too.
Proc macros are very difficult to review for hidden malware. Metaprogramming adds more ways to obscure what code is generated and run. It's helpful to also look at the code generated by proc macros, but smart malware authors know to only attack when nobody is looking. It would be useful if the sandbox made it hard for proc macros to guess when they're building for cargo expand vs other situations.
Sandboxing of build.rs seems hopeless, because scripts for system libraries need to be able to search the system and build or link arbitrary code. However, build.rs scripts are also typically small and simple, so it's feasible to review their code.
So together some kind of review + approval for build.rs and a sandbox for proc macros could at least make browsing of Rust code safe. That isn't enough to run arbitrary code without reviewing it, but at least makes it safe to review arbitrary code.
Discussion in the ATmosphere