Using AI on real servers without losing sleep

I use Claude Code over SSH every day. It reads code, proposes changes, runs commands, edits configuration, and helps me move much faster through server work than I could alone. It's one of the most useful tools I've added in years.

It's also a tool that can run commands on a live machine. That deserves the same respect you'd give a new admin with a root shell on day one: helpful, capable, and not yet someone you let work unsupervised on production.

These are the habits I rely on. None of them are specific to one AI tool. Most of them are just good server practice, applied a little more strictly because the thing typing the commands doesn't carry the consequences.

Least privilege, even for your assistant

The easiest mistake is running the AI session as root because it's convenient. Sometimes you need elevated access. Most of the time you don't.

• Work as the least-privileged user that can do the task. Editing a site's templates doesn't need root.
• Use the tool's permission controls. Modern AI coding tools let you require approval before commands run or files are written, and allowlist safe read-only commands. Keep write and destructive actions on "ask."
• Don't pre-approve broad patterns like "any shell command." Approve narrow, specific ones you'd run yourself without thinking.
• Be most careful with commands that are hard to undo: deleting files, dropping tables, rewriting firewall rules, changing SSH or mail configuration, restarting services other people depend on.

A firewall or SSH change that locks you out is a bad afternoon whether a person or a model typed it. Keep a second session open when changing access rules, and confirm you can still get in before closing the first one.

Staging first, and backups before anything

If a change can be tried somewhere other than production, try it there first. A staging copy of a site, a test database, a spare VPS. The AI is fast, which makes it tempting to skip this. The speed is exactly why you shouldn't: a fast mistake on production is still a mistake on production.

Before any meaningful change on a real server:

1. Back up what you're about to touch. Copy the config file. Dump the database table. Snapshot the VM if your provider supports it.
2. Know how to restore it. A backup you've never restored is a hope, not a plan.
3. Keep changes small so that a rollback is one step, not an archaeology project.
4. Prefer reversible changes. Add a new config file and switch to it rather than editing the old one in place. Disable before you delete.

I ask the AI to include the backup step in its own plan. It's good at remembering when you tell it to, and it's a useful check on whether its plan is sensible at all.

Review the diff, not the explanation

AI tools are very good at explaining what they did. The explanation is not the change. The diff is.

Read what actually changed in the files before accepting it. Look for:

• Changes outside the scope you asked for, like "while I was here, I also cleaned up…"
• Removed lines you didn't expect to lose, especially error handling, validation or security checks
• Hard-coded values that should come from configuration
• New dependencies or packages you didn't ask for
• Permissions changes on files or directories

If a diff is too big to review properly, the change is too big. Ask for it in smaller pieces.

Keep secrets out of prompts

Anything you paste into a prompt, or that the tool reads from a file, may leave your machine and become part of a conversation log somewhere. Treat it that way.

• Never paste passwords, API keys or private keys into a prompt. Not even "just this once to debug."
• Keep secrets in a vault or in files with tight permissions that the AI session doesn't need to read. Reference them by path or environment variable, not by value.
• Watch for tools reading config files that contain credentials. If a task requires looking at a file with secrets in it, consider redacting a copy first.
• Rotate anything that was exposed. If a secret ended up in a prompt or a log, assume it's compromised and replace it. That's cheaper than finding out later.
• Scrub personal data too. Customer records, lead details and email addresses don't belong in a debugging prompt. Use sample or anonymized data.

Treat model output as untrusted input

The model is confident by default. It will sometimes produce a command for a flag that doesn't exist, a config directive from a different version of the software, or a fix that addresses the symptom and not the cause.

So treat its output the way you'd treat code from a stranger on a forum: probably helpful, possibly wrong, always checked.

• Check commands against the actual documentation or the tool's own help output for your version.
• Be suspicious of anything that disables a security feature to "fix" an error.
• If it proposes a cause, ask how to confirm that cause before acting on it. Inspect the system before trusting the symptom, and before trusting the diagnosis.

Verify with real checks

"It should work now" isn't verification. After a change, check the thing that actually matters:

Change	Real check
Web server config	Syntax test, reload, then load the actual pages and check response codes
SSL	Check the served certificate and expiry from outside the server
DNS	Query the record from a public resolver, not just the local one
Mail (SPF, DKIM, DMARC)	Send a real message and inspect the authentication results in the headers
Application code	Run it, exercise the changed path, read the error log
Scheduled jobs	Confirm the next run actually happens and produces output

Ask the AI to run these checks with you, and read the results yourself. It's good at running verification. It's not always good at noticing when a result is subtly wrong.

The same rules, applied every time

The pattern is the same one I use for scheduled agents, which I wrote about in Scheduled AI agents with a human in the loop: the AI does the preparation and the legwork, and a human approves anything that changes a real system. The broader idea is in AI as an operating layer, not a chatbot.

None of this slows you down much once it's habit. Back up, stage, review the diff, keep secrets out, verify for real. The AI makes the work faster. These habits make sure faster doesn't also mean riskier, and that's what lets you close the laptop at night without wondering what you just broke.