Security for a Self-Hosted AI Agent

An agent that browses, runs terminal commands, and manages files can spend your money, message your customers, and delete your files while you are asleep. That is not a flaw; it is the same capability that makes it useful, and it acts on your behalf with whatever access you gave it. Hermes Agent and OpenClaw are two of these, and so is any tool that hands a model a terminal and a browser. The rule on our solutions guides is short: dedicated server, scoped credentials, administrative access over SSH (an encrypted login keyed to a file rather than a password).

Its own server, and nothing else on it#

A dedicated VPS is a crisp isolation boundary with nothing else on it: no production database, no customer site, no personal archive, no keys to other machines.

Scope every credential#

• One credential per integration, so any single one can be revoked alone.
• The narrowest scope that works: read-only where reading is enough, one repository rather than the organisation.
• Its own accounts, not yours, so revoking one does not lock you out.
• Nothing that spends money or deletes infrastructure. Where the provider offers no read-only tier, do not issue the credential at all: hold it yourself and run those actions by hand. That includes a cloud portal API token, because whoever holds one can do to your servers whatever your account can, including reinstalling them.

Secrets on disk#

The agent has to read its own keys, so secret here means readable by one unprivileged account and nobody else. Run it as a dedicated user, not root, and check rather than assume. Substitute the unit name your installer created and the config file the vendor documentation names:

systemctl list-units --type=service --state=running  # find the unit
systemctl show -p User --value <unit>               # what the service really runs as
id -nG <agent-user>                                 # unprivileged: not in sudo, wheel, or docker
stat -c '%U %G %a' <agent-config-file>               # want: owned by that user, mode 600

Membership of the docker group is equivalent to root. Memory, transcripts, and logs also quote what the agent was given, and they land in whatever backup covers the server.

The admin interface#

The dashboard or CLI that controls the agent can change what it may do, which makes it the highest-value target on the box. Configure it to accept connections only from the server itself (localhost), then reach it either through an SSH tunnel, a private encrypted path from your machine to that one port, or a tailnet, a small private network only your own devices can join. Keep a Dashboard Private covers both, and use SSH keys rather than passwords.

Know your kill switch#

You hold root, so stopping the agent is your decision, not a support request. Three levers:

1. Stop the process. systemctl disable --now <unit> for the unit the installer created, or docker compose down in its project directory. Disable, not just stop, so a reboot does not restart it. See Run an App as a systemd Service.
2. Cut its network. Deny outgoing traffic in the firewall, or power the server off from the cloud portal; the VNC console works when the box will not answer.
3. Revoke the credentials at the issuer. It is the only lever that still works once a key has left the machine.

Try all three before you need them; a kill switch you have never pulled is a plan, not a switch.

Prompt injection, plainly#

An agent that browses reads text written by strangers: web pages, issue comments, documents, and messages from channels you paired. Some of that text is written to look like an instruction, and an agent that cannot reliably tell content from instruction may act on it. No setting ends this, and we do not sell anything that filters it. The mitigation is the discipline above: the agent should not hold a credential whose misuse you could not survive.

What we do, and what is yours#

This is an unmanaged service: we run the hardware, network, and uptime; you configure the agent and its guardrails. We do not supervise it, and no setting on our side makes an agent safe. You get the structural isolation, and the operational discipline is yours.

If you think it did something you did not intend, treat it as an incident: snapshot first, then work through Recover from a Compromised Server.

Next, for the install itself: Deploy Hermes Agent on a VPS or Deploy OpenClaw on a VPS, with the Hermes Agent and OpenClaw guides for sizing. Where a control depends on the agent's own configuration, the vendor documentation is the authority.