Allow "routing only" mode on channel open (or on wallet creation, for whole node)

[GordianLN]

Currently, on the node hardening aspect, both remote signing and the ability to set, on channel creation, an address for coop close, cover a significant part of node hardening against malicious attacks; this leaves out the possibility, for an attacker who has direct access to the node, to just use the existing local balance of already opened channels, to send payments to themselves until said channels are completely drained.
For a "routing-only" node, an operation mode that will literally only allow routing (that is, no other payments than those starting from, and ending to, an owned channel's local balance, otherwise known as circular rebalances) would further strengthen the security against direct attacks.
On the other hand, this would also prevent loop out and submarine swaps, or similar arrangements, but a sufficiently motivated operator would still appreciate the security improvements, and could setup a private channel with a separate wallet, from where to allow for such swaps if needed.
Also, this would leave out another possible attack vector, where the malicious actor could implement a "fee theft" attack, forcing rebalances to go through their own node, collecting artificially high fees.
This could be covered implementing an additional feature to "routing only" mode.

[BhaagBoseDK]

this will break many features/tools of current routing nodes

• keysend with messages
• loop out
• sending funds to your second node
• sending spend money to wallets

how do these weigh against the risk

[GordianLN]

This is a good observation.
Let's discuss

* keysend with messages

• can send them from separate lightning wallet, which you can fund from onchain wallet; more costly than pushing funds on a private channel, which would be free; this would be a safety cost, or
• have a hardcoded (on node or channel creation) limit of N keysends per day to each node, each one of maximum M sats, and up to a maximum of X nodes per day?

* loop out

For those who do use loop out, this would be a limit indeed, so either:

• security cost for someone who doesn't plan to use loop out, ever, or
• again, hardcoded (on node or channel creation) limit of N loopouts per day, each of M sats

* sending funds to your second node

This belongs to more advanced use-case scenarios, but still:

• security cost, still a feature most node operators won't need anyway, or could circumvent by sending funds to second node onchain
• hardcoded (on node or channel creation) list of additional node(s) to which payments will be allowed

* sending spend money to wallets

Pretty much like above replies; still niche usecase as, if it is your own wallet with private channel to your node, you can send onchain, or just allow that one channel to that one one node to send funds to; if you act like an Uncle Jim, then you might reconsider using this feature at all?

how do these weigh against the risk

Personal evaluation which is necessarily bound to differ in outcome with different operators; I believe this feature would still meet the favour of many operators, and given the possibilities above to make it adaptable to personal use cases, even more operators could adopt it.