Is it possible to define various level for safety?

First of all, keep in mind that Rust is not a sandbox language. It fundamentally trusts the programmer and will allow the source code to turn off or bypass all safety restrictions. You can't use Rust's unsafe to protect systems from malicious or very badly broken Rust code. The safe/unsafe split is only a helpful tool for cooperative programmers.

Not-unsafe code is still allowed to do lots of dangerous, stupid, and destructive things. Non-unsafe code is allowed to delete data, expose sensitive information, be incompetent at controlling system access, and connect missile control to AI agents.

Currently unsafe is only focused on specifics of memory safety and integrity of the program itself (avoiding UB), which can have precisely defined boundaries. This works because the requirements are limited in scope, defined by the language, and pretty universal across all programs and purposes.

Adding protections for other categories of badness would require defining exactly what is allowed and where, how it affects data moving through the program, generic code that manipulates it, dynamically invoked code, etc. Assuming you want these features to actually do something and catch bugs in non-trivial cases, implementing them is challenging. For something like protecting a password you need to define what data is the password, track it as it passes through the program, and teach the compiler where it can safely end up and where it can't. In language design such features are known as "taint tracking" and "effect systems". It gets pretty complicated - .map() is generic, so it must be safe to call when it processes non-password, but not allowed to turn unsafe-to-handle password into safe-to-handle bytes just because you invert case of password's letters or something like that. You may have a web form that takes a password, and want to ensure that password-ness of the data is carried through your web framework, deserializer, handlers, and only make password handling require unsafe and not taint the whole web server and not lose the taint bit on the first dyn Future.