While admittedly this can be a bit risky, there's a lot less possible blast radius or thing that can go catastrophically wrong if you give the LLM the ssh keys and sudo access on a KVM VM (or equivalent) that's been created as a blank slate exclusively as its playground. I have a template debian 13 KVM VM that can have its ssh host keys and hostname wiped, other unique per-node things, and duplicated with a basic bash script in a couple of minutes to deploy for home lab testing.
I'm fine with giving a "smart" self hosted LLM like qwen 3.8-flash-next Q8 access to it to do things in opencode.
Don't give it the keys to any castle but give it access to one specific containerized thing...
I'm saying a staging/testing environment is a good place to prove your specific configuration of "smart" LLM isn't going to do something wildly wrong, before you even think to trust it in a production environment. And as a place to develop things like playbooks and similar documentation to feed into an LLM's context for ongoing maintenance and operations of something in production.