[RFC] What security expectations does/should the RPC server have from credentialed RPC clients? #32274

It is not obvious to me from reading https://github.com/bitcoin/bitcoin/blob/1f6ab1215bbb1f8a5f1743c3c413b95ad08090df/doc/JSON-RPC-interface.md#security what the security expectations are for a machine serving the RPC interface about what a credentialed RPC client can do on the machine outside of affecting the node it has credentials for.

It seems to me that users should expect that RPC clients with credentials will have all the same privileges as the bitcoind process does on the machine, since, for example users can specify arbitrary wallet paths on the machine means that users should expect that RPC clients with credentials will have all the same privileges as the bitcoind process does on the machine (https://github.com/bitcoin/bitcoin/pull/32273). It doesn't seem far fetched to me to imagine that someone at some point naively ran multiple unsandboxed nodes on the same machine, provided credentials to users, and did not realize that those users could load each other's wallets.

If that's correct, then the actionable form of the question is: Is this something that should be more clearly stated to users in any way, or is the situation I'm describing contrived and unrealistic, where a user trusts an RPC client with a node, but not with the whole machine and doesn't in any way sandbox/container the node.

What if docs at doc/JSON-RPC-interface.md include an explicit warning stating that:

"RPC credentials grant full administrative control of the node and any resources the bitcoind process can access. Clients with valid credentials should be considered as trusted as the local user running bitcoind. If untrusted clients must be allowed to access RPC, strong isolation mechanisms (e.g., containers, separate machines, restricted filesystem permissions) must be employed externally to prevent lateral privilege escalation or data leakage."

This would clarify expectations for operators and hopefully avoid subtle security pitfalls caused by misunderstanding the security boundary (or lack thereof).