AI Agents on Your Own Server: Check These First

Before you run an AI agent on your own server, check six things: who can send it instructions, which commands it runs without asking, whether its dashboard is reachable from the internet, what it remembers, which add-on skills it installs, and whether every action is logged. Self-hosting moves agent execution onto your infrastructure; it does not make the agent safe.

What is a self-hosted AI agent, and why are businesses installing one?

A chatbot answers questions. An agent does work: it reads files, runs commands on a computer, calls APIs, and sends messages, looping until the task is done. (We covered how that loop works in agentic tool loops.) A self-hosted agent is one you install on your own laptop, office server, or VPS instead of using someone else's web app.

The current wave is led by open-source projects. Nous Research released Hermes Agent in February 2026: it keeps a persistent memory across sessions, writes its own reusable "skills" from experience, and can be reached from the terminal or from chat apps like Telegram, Slack, and Discord. OpenClaw, the other big name, went viral early in 2026 and became a security case study within weeks.

The appeal for a business is obvious. The agent sits next to your files and systems, runs around the clock, and answers on the chat app your staff already use. The problem is the same list read backwards: it sits next to your files, runs unattended, and anyone who can message it can try to steer it.

One thing to settle before anything else. Self-hosting the agent is not the same as self-hosting the model. Unless you point the agent at a model running on your own hardware (Hermes supports local Ollama and vLLM endpoints), every prompt, file excerpt, and memory still travels to a model provider. "Where does our data live?" has two answers, and both belong in the decision.

Who is allowed to give the agent instructions?

Start at the front door. An agent connected to WhatsApp or Telegram is a computer that takes orders from chat messages, so the first control is the list of people whose messages count.

Hermes gets this right by default. Its security model checks per-platform allowlists (named lists of approved user IDs), a global allowlist, and a pairing flow that issues an 8-character code valid for one hour, and it denies everyone else. The setting to watch for is the opposite: a flag like GATEWAY_ALLOW_ALL_USERS=true, usually switched on during a demo and never switched off.

An allowlist only covers who sends commands. It does not cover what the agent reads. An agent that processes customer emails or a shared group chat is reading text written by strangers, and that text can contain instructions. That attack is called prompt injection: hiding commands inside content the agent was only supposed to read. Treat every message, attachment, and web page the agent touches as untrusted input, even when the person who forwarded it is trusted.

What can it run without asking first?

This is the question that decides how bad a mistake gets. An agent with shell access can delete a folder as easily as list it.

Hermes ships three approval modes in approvals.mode. Manual asks you before dangerous shell commands. This is not an approval gate for every file or API write. Smart, the default, lets a second AI model judge risk and auto-approves what it considers low risk. Off, also called YOLO mode, skips the checks entirely. A hardline blocklist (disk wipes, fork bombs, raw device writes) stays on in every mode.

For business use, that default deserves a second look. "Smart" means one model decides whether another model's command is safe. That is fine for a personal assistant tidying a downloads folder. For anything that touches customer data, money, or production systems, use manual approval for write actions and keep YOLO mode off the machine entirely.

The second control is where commands run. Hermes can execute tools on the host directly or inside a Docker container, an isolation boundary whose access depends on its mounts, network configuration, and privileges. Its container profile drops Linux capabilities by default, caps the process count at 256, and limits temporary storage to 512 MB. Run the agent in the box, mount only the folders it needs, and give it its own service account (a dedicated login with only the permissions this job needs) instead of your admin login. That last rule has a name: least privilege.

Is the agent's control panel reachable from the internet?

Many self-hosted agents ship with a web dashboard. If that dashboard answers on a public IP address, anyone who finds it may be able to drive your agent.

OpenClaw showed the scale of the problem. SecurityScorecard's STRIKE team counted more than 135,000 internet-facing OpenClaw deployments, as Bitdefender reported on 12 February 2026. Binding depends on version and installation. Current OpenClaw documentation defaults host installations to loopback; container setups can bind more broadly. Check the actual bind address and authentication instead of assuming every installation exposes port 18789. In SecurityScorecard's own sample of 40,000+ exposed instances, 35.4% were flagged as vulnerable to remote code execution, which means an outsider could run their own commands on the host.

The fix is boring. Bind the dashboard to 127.0.0.1 (localhost only), put remote access behind a VPN, and scan your own public IPs once after setup to confirm nothing answers. If the agent's port shows up in a scan, assume someone else has already found it.

What does it remember, and where is that stored?

Persistent memory is the feature people install these agents for. It is also a new data store that nobody put on the asset register.

Hermes keeps two small memory files under ~/.hermes/memories/: MEMORY.md for the agent's own notes, capped at 2,200 characters, and USER.md for its profile of you, capped at 1,375 characters, according to its memory documentation. The bigger store is ~/.hermes/state.db, a SQLite database holding past conversations across the terminal and every connected chat platform, with full-text search over all of them.

Read that again with a compliance hat on. If staff paste customer names, phone numbers, or invoices into the agent, that database now holds personal data under Indonesia's PDP Law, with the same duties as your CRM: access control, retention, breach handling. We covered how the UU PDP penalties shifted in 2026. Put the agent's data folder on an encrypted disk, include it in backups, and decide how long sessions are kept.

Memory can also be wrong. A fact the agent saved by mistake, or one planted through an injected message, gets loaded into every future session. Hermes offers memory.write_approval: true so new memories wait for a human to approve them. Turn it on, and review the memory files the way you would review a new employee's notes about your clients.

Where do its skills come from?

A skill is a packaged set of instructions, sometimes with scripts, that teaches the agent a new task. Installing a third-party skill is installing code that runs with the agent's permissions.

OpenClaw's public skill marketplace, ClawHub, learned this the hard way. Koi Security found about 341 malicious skills there on 1 February 2026, most of them from one campaign later named ClawHavoc. By 6 February, Antiy CERT counted at least 1,184 malicious skills uploaded over time. The trick was low-tech: a convincing SKILL.md with a fake "Prerequisites" section telling the user, or the agent, to download and run a payload that stole API keys and crypto wallets.

The problem did not end with that campaign. Unit 42 reported on 23 June 2026 that it found new malicious skills between February and May, including one padded with 22 MB of junk to slip under scanner size limits. Its point holds for every agent platform: skills can inherit the agent's file-system and shell permissions unless the platform or deployment adds an isolation boundary.

Treat skills like software dependencies. Keep an internal list of approved skills, read a skill's files before installing it, pin the version, and never let the agent install skills on its own from a public hub. Skills the agent writes for itself, which is Hermes's headline feature, need the same review before they touch production systems.

Can you reconstruct what the agent did last Tuesday?

When something goes wrong, the first question is what happened. An agent that cannot answer that is an employee who keeps no notes and never gets audited.

A session database is not an audit trail. The agent can edit or delete it, and it records conversations, not decisions. What you want is a log of every tool call (command, arguments, who approved it, result) written somewhere the agent cannot change, such as a separate log server or append-only storage.

Hermes already handles part of the credential problem. It passes API keys to plugin processes only when explicitly declared, scrubs common token formats from error output, and guards sensitive paths in its file-writing tools. These guards do not contain a shell running as the same OS user; project .env files are not universally write-blocked. Those are good defaults. They do not replace scoped credentials: give the agent its own API tokens with read-only access wherever read-only is enough, so a bad day costs a revoked token instead of a database.

The pre-install checklist

Run through this before the agent touches anything that matters:

Agents fail in ways that look like ordinary IT failures: an open port, an unreviewed package, a login with too much power. The fixes are ordinary too. What is new is how fast an unattended agent can turn one of those gaps into damage, which is also why most agent pilots stall at the point where someone has to sign off on the risk. Settle these ten checks first, and that conversation gets much shorter.