axelverne.com / guides / security

The AI agent security checklist: the 90% that matters.

An AI agent's security posture is the security posture of the account running it. The model gets the headlines; the actual attack surface is your terminal's reach — SSH keys, API tokens in your shell, anything listening on the machine. Here's the checklist that covers most of the risk, and four copy-paste prompts that turn your agent into the auditor.

First, the story that explains the stakes

A Hermes user ran the agent's web UI on a VPS, bound to 0.0.0.0, behind a weak password. Someone brute-forced it in about 400 attempts, drained their DeepSeek and OpenRouter credits over a few days, reused the keys on other services, and parked adult content on the box. Total damage: about $70 and a weekend.

It stayed that cheap for one reason only: the agent had a dedicated throwaway email and no access to anything that mattered. That's the whole philosophy of this page in one sentence — assume compromise, limit blast radius, and the worst case is small.

The checklist

• Web UIs on localhost only. Bind to 127.0.0.1. Reach the UI remotely through an SSH tunnel or Tailscale — never a port-forward. On a VPS, 0.0.0.0 is the entire internet, not your LAN.
• Dedicated credentials. The agent gets its own throwaway API keys with spend caps — never your primary keys, never your main email.
• Review the firewall yourself — and check specifically whether Docker is bypassing it. Docker and UFW famously don't do what you'd expect.
• Assume prompt injection is live. A malicious web page can attempt to steer an agent that fetches it. What the agent can reach when compromised is the real question.
• Never let the agent grade its own homework. Asked whether its UI resisted brute force, one agent read its own source and confidently claimed increasing login delays. Four hundred successful guesses say otherwise: require tests, not intentions.

Four copy-paste audit prompts

1. The machine audit

Audit this machine's security posture as it relates to you, the agent:
- What services are listening, on which interfaces? Flag anything bound to
  0.0.0.0 that shouldn't be.
- SSH: password auth, root login, key-only status.
- Firewall rules — and check specifically whether Docker is bypassing them.
- Credentials reachable from my shell environment and from your tools.
- Web UI / gateway exposure and auth strength.
Give me findings ordered by blast radius, with the exact fix command for each.
Ask before applying anything destructive.

2. Get the web UI off the internet

My Hermes Web UI is reachable at <address>. Assume that's wrong. Show me how to:
1. Bind it to 127.0.0.1 only.
2. Reach it remotely over an SSH tunnel or Tailscale instead.
3. Firewall the port to my Tailscale/home IP only.
Give me the commands, in order, with a verification step after each.

3. The blast-radius review

Assume you get prompt-injected by a malicious web page today. Walk through what
you could actually reach: files, credentials, email, money, published surfaces.
Tell me which of those I should take away from you, and how.

4. The anti-self-grading rule

When I ask whether some part of Hermes is secure, do NOT answer by reading the
source and telling me what it intends to do. Test it, or say you can't test it.

Paste this one into your standing instructions so it applies every time. It's the difference between a security audit and a security flattering.