The stories in "who let AI run amok" threads have the same shape. The model wasn't malicious; it was confident. It cleaned up a directory that turned out to be the one with the data, or "fixed" a config by replacing it, or ran a migration against production because that was the connection string it found.
You can't make the model never be wrong. You can decide how much damage being wrong can do. That's blast radius, and it's set long before the first prompt.
Least privilege, per machine
- A dedicated non-root user on each server, owned by the agent and nothing else.
- Sudo only for named commands it actually needs (
systemctl restart myapp, notALL). - Database access with a role that can read, and write only where you mean it to.
- No production credentials in files that user can read. If it can find a connection string, assume it will use it.
No new doors
Don't open a port so an AI can reach your server. Reach it over Tailscale/WireGuard, or use a tool where the server dials out. Every new listener is something the internet can find, whether or not the AI ever uses it.
A read-only phase
A week where it can look and explain but not change anything. You learn how often it misreads your setup, cheaply.
Undo before do
Snapshots of VMs and datasets before any change. Backups it can't reach: different user, different host, or append-only. Test a restore once; an untested backup is a hope.
Changes go through something you can read
For anything repeatable, the AI writes a script or playbook, you review it, you commit it, you run it. Chat is for investigating and one-offs. "What will this change, and how do I undo it?" before every one-off.
Know what happened
Keep a record of what was run, on which machine, and how it ended. Shell history under a dedicated user is a start. You want to answer "what did it do at 2am" without guessing.
A way to stop it
You need to be able to cancel a running job and cut a machine off in seconds, from your phone if you're not at a desk.
Where my tool sits, and the trade-off
I build Local Commander, so I'm biased. It covers several of these: an agent per computer that dials out (no open port), per-machine access (the whole user account or selected folders), blocked commands, a record of every request with how it ended, cancel and revoke from anywhere. If a computer drops mid-job, the job isn't re-run on a guess; it waits for you.
The honest trade-off for self-hosters: the relay is hosted. Commands and their results pass through our service on the way to your AI app. If "nothing leaves my network" is your rule, that rules it out, and an SSH-based MCP server you run yourself, with the guardrails above, is the better fit. The open-source edition is local and needs no account, but it covers one computer, for desktop AI clients.
The short version
- Own user, minimal sudo.
- No new ports.
- Read-only first.
- Snapshot, and backups out of reach.
- Scripts you review for repeatable changes.
- A record of what ran.
- A stop button.
None of these depend on the AI tool you pick. They're what keeps a confident mistake small.