How I Secured My Hermes AI Agent: A Practical Guide to Keeping Your Autonomous Agent Safe

I have been playing with Claude, Openclaw, Hermes and AI OS setups for a while now. Because I have a security background I often get asked by friends and colleagues how to best secure and configure these AI configurations. So I thought I’d share some useful info and insights.

That is the gap this article is meant to close. If you run Hermes, OpenClaw, Claude Code, or any open-source AI agent on your personal or work machine, the same question applies: what happens if someone compromises the agent, poisons its memory, or publishes a malicious skill?

Here is what I found when I actually looked, and the practical steps I took to lock it down.

Why Hermes Agent is different from other tools

Hermes Agent (by Nous Research) is not like the AI tools you interact with through a web browser. It is an autonomous agent that runs persistently on your machine. It has:

• A terminal with full shell access
• File read and write capabilities across your filesystem
• Browser automation
• Scheduled cron jobs that run without supervision
• Memory that persists across every session and accumulates knowledge
• Messaging platform access (Telegram, Discord, WhatsApp, Signal, Email)
• Integration with MCP servers that can access external APIs
• A skill marketplace for community extensions

The persistent memory layer is the standout feature, and it is also the largest unbounded attack surface. Every session writes to a SQLite database that FTS5 indexes and retrieves on every future query. If an attacker poisons that memory, every subsequent action the agent takes is compromised at the foundation.

The seven-layer security model

Hermes ships with a defence-in-depth model covering seven layers. Understanding each one is the starting point for any serious security review.

Layer 1: User authorisation

The gateway supports allowlists at the platform level. On WhatsApp, only approved phone numbers can send messages. On Telegram, users must pair via a device-code flow. On Discord and Slack, the bot only responds in configured channels. The principle is straightforward: define explicitly who can talk to the agent.

Check your config: Look at the WHATSAPP_ALLOWED_USERS environment variable and the allowed_users section in ~/.hermes/config.yaml. If these are not set, any user who can find your agent’s contact address can interact with it.

Layer 2: Dangerous command approval

By default, Hermes runs with approvals.mode: smart. An auxiliary LLM classifies every shell command as low risk, uncertain, or dangerous. Low-risk commands (simple Python scripts, file reads) are auto-approved. Dangerous commands (rm -rf, curl to untrusted URLs piped to bash) are blocked. Uncertain cases prompt the user.

There is also a hardline blocklist that not even --yolo mode can bypass: rm -rf /, fork bombs, mkfs on mounted root devices, and dd to raw block devices are always refused.

Practical step: Set approvals.mode: smart in your config.yaml. Never run with --yolo in a production or personal environment. Add custom deny rules using approvals.deny for actions you never want the agent to perform, like git push --force* or *curl*|*sh*.

Layer 3: Container isolation

Hermes supports Docker, Singularity, and Modal as terminal backends. The Docker backend runs shell commands inside a container with hardened security flags: read-only root filesystem, no new privileges, seccomp profiles, and dropped capabilities.

Practical step: If you can run Docker, switch the terminal backend. Set terminal.backend: docker in config.yaml. The container restricts what the agent can do even if its memory is compromised.

Layer 4: MCP credential filtering

MCP subprocesses inherit only explicitly allowed environment variables. A strict allowlist in config.yaml defines which env vars pass through to MCP servers. Everything else is filtered out.

Layer 5: Context file scanning

Hermes scans project files like AGENTS.md, CLAUDE.md, and .cursorrules for prompt injection attempts before loading them into context. This catches the common attack pattern where a repository includes hidden instructions designed to hijack the agent on first load.

Layer 6: Cross-session isolation

Each conversation session is isolated. Cron job storage paths are hardened against path traversal. One session cannot read another session’s data or state.

Layer 7: Input sanitisation

Working directory parameters in terminal tool backends are validated against an allowlist before being passed to the shell. This prevents directory traversal and shell injection through the working directory argument.

The threat classes enterprise teams should care about

The Repello AI threat model for Hermes Agent identifies four enterprise-level risk classes. These matter whether you run Hermes on a personal machine or a corporate workstation.

1. Skill marketplace supply chain

Hermes has a growing skill marketplace. Installing a skill grants it broad tool access within the agent. A malicious skill could exfiltrate data, modify files, or execute arbitrary commands. The trust model is the same one that caused problems on ClawHub: trust at install, sandbox at runtime.

Defence: Only install skills you have read the source of. Use hermes skills inspect ID before installing. Maintain a personal allowlist of trusted publishers. Audit installed skills regularly with hermes skills list and remove anything you no longer need.

2. Memory injection through retrieved context

Hermes reads from its SQLite memory store on every session start. If an attacker can inject a crafted memory entry, they can influence the agent’s behaviour on every subsequent query. This is persistent, cross-session, and very hard to detect.

Defence: Enable security.redact_secrets to prevent credentials from being stored in memory. Review memory content periodically using fact_store and session_search. If you run a sensitive workload, consider running it in an isolated profile with its own memory store.

3. Multi-provider credential surfaces

Hermes supports 20+ LLM providers, each requiring API keys stored in .env. The credential pooling system rotates keys across providers, which is useful for reliability but increases the number of stored credentials an attacker could target.

Defence: Use OAuth-based providers (Nous Portal, GitHub Copilot) where possible instead of static API keys. Set rate limits on every API key you add. Use the credential pool rotation to spread risk. Never store production credentials on a machine running an uncontained agent.

4. MCP server trust boundary

MCP servers run as subprocesses with their own environment and network access. A compromised MCP server can access whatever its environment provides.

Defence: Review every MCP server configuration. Use the credential filtering to limit what each server can access. Run untrusted MCP servers in separate containers where practical.

Practical steps to secure your Hermes Agent today

Here is the checklist I worked through on my own setup. Each step takes minutes and has immediate security benefit.

1. Enable secret redaction. Run hermes config set security.redact_secrets true. This prevents API keys and tokens from appearing in tool output that enters the conversation context and logs. A restart is required because this flag is snapshotted at import time.
2. Set approval mode to smart. hermes config set approvals.mode smart. This is the default, but verify it has not been changed. Add custom deny rules for actions you never want automated.
3. Review environment variables. Run hermes config env-path to find your .env file. Every key stored there is available to the agent. Remove any keys for services you no longer use. Use the principle of least privilege for every token.
4. Audit installed skills. hermes skills list shows what is installed. Remove anything you did not explicitly install or no longer use with hermes skills uninstall.
5. Review MCP server configurations. hermes mcp list shows connected servers. Verify each one is still needed and configured with minimal permissions.
6. Check gateway user allowlists. Verify WhatsApp allowed users, Telegram pairing, and Discord channel restrictions are in place.
7. Back up your config and .env. Store encrypted copies in a separate location. This is essential for recovery if something goes wrong.
8. Run hermes doctor. The built-in health check validates your config, dependencies, and environment. Run it regularly.
9. Update regularly. hermes update pulls the latest version with security fixes. The project receives frequent updates and the team has been responsive to security issues.
10. Consider container isolation. If Docker is available, switch the terminal backend. It adds a meaningful boundary between the agent and your host filesystem.

Keeping up to date and secure ongoing

Security is not a one-time configuration. It is a practice. Here is how to maintain it:

• Subscribe to the GitHub repository. Watch the NousResearch/hermes-agent repo for releases. The changelog notes security fixes explicitly.
• Check CVEs. The project has one disclosed CVE to date (CVE-2026-7396, a path traversal in the WeChat adapter). The project tracks promptware concerns under issue #496. Review these periodically.
• Run monthly audits. Schedule a recurring reminder to review installed skills, connected MCP servers, enabled toolsets, and the .env file.
• Use profiles for separation. Hermes supports multiple isolated profiles with separate configs, skills, and memory stores. Use a restricted profile for high-risk tasks and a full-access profile for trusted workflows.
• Monitor logs. Gateway logs live in ~/.hermes/logs/. Scan them periodically for unexpected activity patterns.
• Red team periodically. Test what a compromised agent could do in your environment. Run through scenarios: what if a skill is malicious, what if memory is poisoned, what if an MCP server is compromised?

The bottom line

Hermes Agent is powerful because it is autonomous, persistent, and deeply integrated into your environment. Those same properties make it a meaningful security boundary if left unexamined.

The good news is that the project ships with real security controls. The approval system, secret redaction, container isolation, and credential filtering are not bolted on afterthoughts. They are part of the architecture. The question is whether you have configured them.

If you run Hermes on a machine that has access to anything you care about, work through the checklist above. It takes thirty minutes and it will give you a much clearer picture of what your agent can actually do, and what it cannot.

The security model has seven layers. Most users only know about two. Start with the layers you have access to: approval modes, secret redaction, user allowlists. Then work up to container isolation and MCP credential filtering.

Hermes Agent official documentation