Securing Hermes on a VPS: My Three-Layer Audit

A Hermes agent running on a VPS can read files, call APIs, execute commands, and complete jobs while you sleep. That autonomy is useful. It also expands the impact of a mistake, a stolen account, or malicious content.

I reviewed my installation as a system that needs continuous evidence, not as an app you deploy once and forget. The audit covers three layers: the VPS, Hermes configuration, and risky usage patterns. At every layer, I want visible proof and a recovery path.

1. The VPS: reduce the exposed surface

The first question is not “does my agent answer?” It is “what can the Internet reach?” A working interface can hide unnecessary open ports, broad SSH access, or a public administration console.

The baseline review has five steps:

inventory the ports that are actually open;
identify the process behind each port;
close anything that does not need public access;
update the operating system and containers;
prepare a backup or snapshot before any change.

Check	Expected evidence	Recovery path
Exposed ports	socket list and an external probe	previous firewall rule
Admin access	allowed key login and rejected password login when keys are required	recovery console
Services	container status and logs	previous image or configuration
Backup	visible, dated snapshot	restore tested in an isolated environment

A saved firewall rule is not proof. Test the result from outside the server. A backup shown in a dashboard is not proof either: you need to know where it is and how to restore it.

2. Hermes: restrict permissions without breaking the job

Removing every tool from Hermes would give you another chatbot. The useful setup keeps authorized work running while the architecture blocks everything else.

I review:

who can send requests to the agent;
which tools are available in each context;
which directories can be read or changed;
where secrets are stored;
which actions require approval;
which automations keep running without a person present.

The verification must cover both outcomes. A legitimate task should still succeed after hardening. A prohibited task should fail clearly. Testing only the block can make a broken system look secure.

A repeatable maintenance sequence

Observe the current state
→ diagnose the configuration
→ create a backup
→ apply one bounded change
→ verify health
→ test an authorized action
→ test a prohibited action
→ keep the change or restore

This sequence replaces blind changes with observable operations.

3. Risky usage: scheduled jobs, secrets, and external content

Scheduled jobs need their own review because they run when you cannot see the prompt, context, or action. For each job, I check its purpose, tools, file scope, network access, and alert behavior when it fails.

External content creates a different risk. A web page, email, or document can contain instructions meant to redirect the agent. Asking the model to be careful is not a sufficient boundary. A useful test puts a controlled malicious instruction inside untrusted data, then verifies that permissions prevent access to a fake secret or block a forbidden request.

This test measures the technical boundaries. It does not prove that every attack is impossible. Use a fake canary, an isolated account, and no production secrets.

The six rules I keep

Expose only the services you need.
Give each task the minimum useful permissions.
Keep secrets outside the active context.
Require approval for sensitive changes.
Prove that authorized work succeeds and prohibited work fails.
Prepare the rollback before the update.

The video shows the complete audit, commands, visible evidence, and the limits of each demonstration: watch the video.