The example on permission isn't great.
It said the library you used cannot access your database password from env and send it over the internet unless you allow so.
When you're putting database password in the env, most likely you need to permit env var and network access for your database client library. Then at the same time, the library in example can do that malicious thing.
The problem here is, deno request the permission per process, not per library import
One thing you can do is explicitly revoke permissions. This allows you to start the program with more permissions and then give them up as the tasks that required them are done, e.g. allowing environment variable access at the beginning and then revoking it before you start a server: https://deno.land/manual/examples/permissions
It's not as fine-grained as allowing libraries specific permissions, but it gets you part of the way there.
I think the network permissions allow you to specify IP ranges it is allowed to connect to. So you could limit it to only being able to connect to the DB server. It would still be an issue for things that need global internet access, though.
When you're putting database password in the env, most likely you need to permit env var and network access for your database client library. Then at the same time, the library in example can do that malicious thing.
The problem here is, deno request the permission per process, not per library import