Don't trust the config: 6 tests that prove your self-hosted AI agent server is locked down

OwnAgent — Thu, 22 Oct 2026 10:03:15 +0000

Disclosure: I wrote this with AI assistance and checked every command and number against my own test runs.

A personal AI agent on a VPS (OpenClaw, Hermes) tends to get "secured" by reading config files. The config says one thing; the machine does another. Here are six tests I run that check behavior, not settings. Each takes a few minutes. Replace AGENT_UNIT, YOUR_IP and USER with yours.

1. Scan from outside, not `ufw status`

From another machine, not the server itself and not localhost:

nmap -Pn -p- -sS YOUR_IP
nmap -Pn -sU --top-ports 100 YOUR_IP

Expected: only 22/tcp open. Run it after the agent is started, since the agent's own ports are open by then. If you see the agent gateway port or a dashboard, fix that before anything else. On the server, also check that the agent listens on loopback only:

sudo ss -tulnp

Everything except sshd should be on loopback: 127.0.0.1 or ::1 for the agent (OpenClaw's gateway is on 18789). Two harmless system entries show up on any Ubuntu: the DNS resolver on 127.0.0.53/127.0.0.54 and the DHCP client on udp/68. Open the panel through a tunnel: ssh -N -L PORT:127.0.0.1:PORT USER@YOUR_IP.

2. Read the effective SSH config

grep /etc/ssh/sshd_config misses drop-ins (cloud images often ship one in sshd_config.d/ that re-enables password login). Ask the daemon:

sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

Expected: no, no, no. Then test it from outside:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no USER@YOUR_IP

You should get Permission denied without a password prompt.

3. Make fail2ban actually ban someone

systemctl is-active fail2ban proves a process exists. From a second host, fail a few SSH logins on purpose, then on the server:

sudo fail2ban-client status sshd

The attacker IP should appear under banned. On my test VMs the ban came after 7 and 127 seconds, depending on timing of retries. Unban yourself afterwards: sudo fail2ban-client set sshd unbanip IP.

4. Kill the agent and time the recovery

Agents usually run as a user service, so ask the user's systemd, not the system one (the system one will happily print MainPID=0):

sudo systemctl --user -M USER@ show AGENT_UNIT -p MainPID -p Restart
sudo kill -9 <PID>

The unit should restart on its own (Restart=always or on-failure), and the agent should answer in Telegram without you touching it. A user service also needs lingering, or it won't survive a reboot:

loginctl show-user USER -p Linger

I measured 6–7 s for the process and 22–42 s until the first Telegram reply.

5. Test the alert by stopping the service

An alert that was never triggered is a hope. Stop the agent and see whether a message reaches your phone within a couple of minutes. Two traps: the alert must go through your own bot, not the bot of whoever set it up; and no alert can fire if the whole VPS dies, so keep an external uptime ping too. Proof of delivery in a script: the Bot API sendMessage response has "ok": true and a message_id.

6. Check the spending limit on the key, not in the agent

Neither OpenClaw nor Hermes has a built-in hard spend cap. The cap that holds is on the API key. With OpenRouter:

curl -s https://openrouter.ai/api/v1/key -H "Authorization: Bearer $KEY"

Look at limit (not null) and limit_reset (monthly, if you want a monthly ceiling). Don't paste the key into logs or shell history; read it from a root-only file.

Bonus: rehearse the rollback

Take a snapshot of the agent state before each update (OpenClaw: openclaw backup create --verify; Hermes: hermes backup), pin the version, turn off self-update, and once, on a quiet evening, install a deliberately bad version and make sure you can return. My rollback runs took 1–3.5 minutes including checks.

What these tests don't prove

A scan from a neighbor machine on the same network is weaker than one from the internet. Use a throwaway VPS as the scanner.
Hermes lets the agent write skill files itself, so a "skill allowlist" detects extras but cannot fully prevent them. I'd rather say that than pretend.
A passing check today doesn't cover the next update.

Questions or checks I missed? I'd like to add them.

About the author: I set up and harden personal AI agents on VPSes.

DEV Community: OwnAgent