How Hermes Agent security works<\/h2>
Hermes Agent security uses multiple independent security layers that control who can access the agent, what actions it can perform, what resources it can reach, and how external content is processed.<\/p>
Access controls restrict agent usage to approved users, platforms, and conversations. Messaging platforms and gateways can enforce allowlists, pairing workflows, and user authorization policies before requests reach the agent.<\/p>
When Hermes Agent<\/a> performs potentially dangerous actions, command approval workflows can require human confirmation before execution. <\/p> For a small set of highly destructive operations, Hermes applies hardline protections that block execution regardless of approval settings.<\/p> You can isolate command execution through containerized and sandboxed terminal backends. <\/p> Running tools inside Docker containers or other isolated environments limits access to the host system and reduces the impact of malicious, compromised, or unintended actions.<\/p> Hermes also protects sensitive credentials through environment filtering, credential redaction, secrets management integrations, and restricted credential forwarding. <\/p> External integrations such as MCP servers receive only a limited set of environment variables unless additional access is explicitly configured.<\/p> To reduce prompt injection risks, Hermes scans supported context files and external content for potentially unsafe instructions before incorporating them into agent workflows. <\/p> Website blocklists and SSRF protections help prevent access to private networks, cloud metadata endpoints, localhost services, and other sensitive resources.<\/p> Additional protections include session isolation between conversations, input sanitization, supply-chain safeguards for optional dependencies, and configurable network restrictions.<\/p> Together, these layers reduce the likelihood that a compromised prompt, exposed credential, unsafe integration, or configuration mistake can lead to a broader security incident.<\/p> Configure Hermes Agent security by setting explicit authorization controls, approval policies, execution boundaries, credential protections, and network access restrictions.<\/p> Once you set up the Hemes Agent<\/a>, start with user allowlists and DM pairing so only approved users can interact with the agent. <\/p> Then configure dangerous-command approval policies, choose an isolated terminal backend such as Docker, restrict credential forwarding, and review protections for external content and network access.<\/p> The strongest Hermes Agent security deployments combine settings in Hermes Agent restricts access through user allowlists and pairing controls. Before making the agent available through Telegram, Discord, gateways, or other integrations, define exactly which users are allowed to interact with it.<\/p> Access-control settings are configured through For Telegram deployments, add approved usernames to Discord deployments use Avoid enabling unrestricted access through settings such as If you use direct-message pairing, review and approve pairing requests before granting access to the agent. <\/p> Hermes provides commands such as Hermes access controls work best when combined with network-level protections. Restrict access to trusted networks, VPNs, reverse proxies, or private infrastructure whenever possible, especially when exposing gateway endpoints to multiple users.<\/p> Review allowlists and paired users regularly. Removing inactive users, unused integrations, and outdated access rules reduces the attack surface and helps prevent unauthorized access.<\/p> Hermes Agent includes a built-in approval system that pauses dangerous commands until a user reviews and approves them. This protection helps prevent accidental system changes, unsafe command execution, and actions triggered by malicious prompts.<\/p> Configure approval behavior through the In production environments, use Avoid enabling YOLO mode on production systems. Running Hermes with Hermes still enforces a hardline blocklist for catastrophic operations, such as root filesystem wipes, fork bombs, and direct disk-destroying commands.<\/p> Review-based approval protects against risky but potentially legitimate commands. A separate hardline blocklist prevents catastrophic operations from running at all, regardless of approval settings.<\/p> Review approval requests carefully before approving. Unexpected commands, requests that exceed the original task scope, or actions targeting sensitive systems deserve additional scrutiny before execution.<\/p> Hermes Agent can run terminal commands via isolated backends rather than executing them directly on the host system. For production gateway deployments, use a backend such as \n Warning!<\/strong> When using containerized or cloud sandbox backends, Hermes treats the isolation environment as the primary security boundary and does not apply dangerous-command approval checks inside the sandbox. <\/p>\n <\/p> Set the terminal backend in Hermes applies hardened Docker settings when using the Docker terminal backend, including dropped Linux capabilities, privilege-escalation protection, process limits, and restricted temporary filesystems. <\/p> Resource limits such as Keep Choose persistence deliberately. With With For stronger network separation, run command execution on a separate server through the Hermes Agent stores API keys, tokens, and other secrets in Hermes also supports external secret management through Bitwarden Secrets Manager, allowing credentials to be stored outside the local filesystem and retrieved at startup.<\/p> Restrict access to the On Linux and macOS systems, limit file access with:<\/p> This ensures that only the file owner can read or modify stored credentials.<\/p> Review environment variable passthrough settings carefully when using isolated execution backends. Hermes only forwards variables listed in Keep these lists as short as possible and include only credentials a task explicitly requires.<\/p> Hermes also filters environment variables before exposing them to terminal sessions, code execution environments, and MCP servers. <\/p> Credentials are not automatically passed to child processes, containers, or external services unless explicitly allowed through passthrough settings or configuration.<\/p> Credential files require the same level of protection. If you use credential passthrough through When using MCP servers, explicitly define which environment variables each server requires. Review stored credentials regularly and remove unused API keys, tokens, and credential files.<\/p> Hermes Agent includes multiple protections against prompt injection attacks, including context-file scanning, input sanitization, and optional Tirith security scanning. <\/p> These controls help identify malicious instructions hidden in context files, documents, web content, and other external sources before they influence agent behavior.<\/p> Context files loaded into Hermes are automatically scanned for prompt injection patterns, helping detect instructions that attempt to override system behavior, bypass safeguards, access credentials, or coerce the agent into performing unauthorized actions.<\/p> Enable Tirith, an optional security scanning tool integrated with Hermes Agent, in Hermes supports several Tirith-related settings, including When enabled, Hermes allows the command to proceed despite the scanning failure. When disabled, Hermes blocks execution until the scan succeeds or the issue is resolved.<\/p> Review this setting carefully before deploying Hermes in environments that execute commands or interact with production systems.<\/p> Prompt injection protections work best when combined with command approvals and isolated execution environments. Even if malicious instructions reach the model, approval workflows and sandboxed execution reduce the likelihood that they will result in harmful actions.<\/p> Review blocked commands, approval requests, and security-related warnings regularly to identify unusual activity and attempted policy bypasses.<\/p> Hermes Agent includes controls that limit which websites, URLs, and external resources the agent can access and help prevent interactions with unsafe or sensitive network locations.<\/p> These protections reduce the risk of prompt injection attacks, malicious websites, and server-side request forgery (SSRF).<\/p> Configure website restrictions in Add domains that the agent should never access, such as internal administrative portals, sensitive company systems, or websites that are not required for agent tasks.<\/p> Hermes blocks access to private networks, loopback addresses, link-local addresses, cloud metadata services, and other non-public destinations by default. <\/p> This protection helps prevent SSRF attacks that attempt to use the agent to access internal services that are not publicly reachable. <\/p> Avoid disabling this safeguard unless a specific use case requires it. The setting Review web-access tools, browser integrations, and external services regularly to ensure the agent only has access to resources required for its workload.<\/p> The number and type of required integrations vary significantly across Hermes Agent use cases<\/a>, so access policies should reflect the tasks the agent is expected to perform.<\/p> Limiting external access reduces the number of locations from which malicious instructions, sensitive data, or unexpected content can enter the system.<\/p> By default, Hermes stores logs in Review logs regularly for signs of security issues or operational problems, such as:<\/p> Investigating these events early can help identify misconfigurations and potential security issues before they escalate into larger problems.<\/p> For production deployments, consider forwarding Hermes logs to your organization’s centralized logging platform. <\/p> Centralized log collection makes it easier to search historical events, correlate activity across systems, and retain records for longer periods.<\/p> Logging is most effective when combined with the other security controls covered in this guide. <\/p> Review security advisory warnings and run Hermes Agent security practices protect against risks commonly associated with self-hosted AI agents and automated command execution, including:<\/p> Hermes Agent and OpenClaw use different security models and focus on different operational requirements. The most secure option depends on how the platform is deployed, configured, and managed.<\/p> Hermes focuses on protecting self-hosted agent execution through user authorization, command approvals, execution isolation, credential filtering, prompt injection defenses, and restrictions on external resources. <\/p> OpenClaw places greater emphasis on deployment auditing, gateway security reviews, configuration validation, and secret management workflows.<\/p> Hermes Agent vs. OpenClaw security differences:<\/p> Security area<\/strong><\/p><\/td> Hermes Agent<\/strong><\/p><\/td> OpenClaw<\/strong><\/p><\/td><\/tr> User access controls<\/span><\/p><\/td> User allowlists and pairing controls<\/span><\/p><\/td> Gateway-level security controls and deployment auditing<\/span><\/p><\/td><\/tr> Command execution<\/span><\/p><\/td> Built-in approval workflows and dangerous-command protections<\/span><\/p><\/td> Configurable execution policies with security audit checks<\/span><\/p><\/td><\/tr> Execution isolation<\/span><\/p><\/td> Docker, Modal, Daytona, Singularity, and SSH backends<\/span><\/p><\/td> Docker, SSH, and sandboxed execution backends<\/span><\/p><\/td><\/tr> Credential protection<\/span><\/p><\/td> MCP credential filtering and controlled environment-variable passthrough<\/span><\/p><\/td> SecretRef-based secret management and credential audits<\/span><\/p><\/td><\/tr> Prompt injection protection<\/span><\/p><\/td> Tirith scanning, context-file scanning, and input sanitization<\/span><\/p><\/td> Focuses primarily on deployment and execution security controls<\/span><\/p><\/td><\/tr> Security auditing<\/span><\/p><\/td> Runtime logs and monitoring<\/span><\/p><\/td> Built-in security audit commands and configuration reviews<\/span><\/p><\/td><\/tr> Network protections<\/span><\/p><\/td> Website blocklists and SSRF protections<\/span><\/p><\/td> Gateway hardening and security validation checks<\/span><\/p><\/td><\/tr><\/tbody><\/table><\/figure> Hermes Agent is a better fit for individual operators and small teams that want a self-hosted agent capable of writing code, executing commands, interacting with APIs, and automating workflows while maintaining tight control over execution, credentials, and external access.<\/p> OpenClaw is a better option for shared deployments where multiple users access the same environment and administrators need built-in security audits, configuration reviews, gateway hardening checks, and centralized oversight of agent activity.<\/p> The most secure Hermes Agent deployment combines isolated infrastructure, restricted network access, regular updates, and strong access controls.<\/p> There are three common ways to run Hermes Agent:<\/p>How to configure Hermes Agent security<\/h2>
~\/.hermes\/config.yaml<\/code> and ~\/.hermes\/.env<\/code> (or the equivalent files in a profile directory) with infrastructure controls such as firewalls, VPNs, private networks, container isolation, and restricted host permissions.<\/p>Restrict who can access the Agent<\/h3>
~\/.hermes\/.env<\/code> and, where applicable, ~\/.hermes\/config.yaml<\/code>.<\/p>TELEGRAM_ALLOWED_USERS<\/code> in ~\/.hermes\/.env<\/code>. <\/p>DISCORD_ALLOWED_USERS<\/code>, while gateway deployments use GATEWAY_ALLOWED_USERS<\/code>. Any user not included in these allowlists is denied access.<\/p>GATEWAY_ALLOW_ALL_USERS=true<\/code>. While this may be useful for testing, production deployments should always restrict access to explicitly approved users.<\/p>hermes pairing approve<\/code> and hermes pairing revoke<\/code> to manage authorized users and remove access when it is no longer needed.<\/p>Require approval for dangerous commands<\/h3>
approvals<\/code> section in ~\/.hermes\/config.yaml<\/code>. Hermes supports manual<\/code>, smart<\/code>, and off<\/code> approval modes.<\/p>approvals.mode: manual<\/code> or approvals.mode: smart<\/code> so that dangerous commands cannot be executed without review or risk assessment.<\/p>hermes --yolo<\/code>, using the \/yolo<\/code> command, or setting HERMES_YOLO_MODE=1<\/code> disables approval checks and allows commands to execute without confirmation.<\/p>Run commands in an isolated environment<\/h3>
docker<\/code>, singularity<\/code>, modal<\/code>, or daytona<\/code> to separate agent-executed commands from the machine running Hermes.<\/p>~\/.hermes\/config.yaml<\/code>. For Docker isolation, configure:<\/p>terminal:\nbackend: docker\ndocker_image: \"nikolaik\/python-nodejs:python3.11-nodejs20\"\ndocker_forward_env: []\ncontainer_cpu: 1\ncontainer_memory: 5120\ncontainer_disk: 51200\ncontainer_persistent: true<\/pre>
container_cpu<\/code>, container_memory<\/code>, and container_disk<\/code> help prevent runaway commands from consuming the host.<\/p>docker_forward_env<\/code> empty unless a task explicitly needs a specific environment variable. Any variable added to this list is injected into the container and can be read by code running there.<\/p>container_persistent: true<\/code>, Hermes preserves the container filesystem across sessions. <\/p>container_persistent: false<\/code>, the workspace is temporary and removed during cleanup. Use persistent mode when tasks need continuity, and ephemeral mode when isolation is more important than saved state.<\/p>ssh<\/code> terminal backend. Store SSH connection values in ~\/.hermes\/.env<\/code> instead of sharing them through exported configuration.<\/p>Protect API keys and other credentials<\/h3>
~\/.hermes\/.env<\/code> by default. <\/p>~\/.hermes\/.env<\/code> file and avoid committing it to source control, sharing it between users, or exposing it through backups and logs.<\/p>chmod 600 ~\/.hermes\/.env<\/pre>
docker_forward_env<\/code> or other backend-specific passthrough settings. <\/p>terminal.credential_files<\/code>, expose only the files required for the workload.<\/p>Block prompt injection attacks<\/h3>
~\/.hermes\/config.yaml<\/code> to inspect commands and requests for potentially unsafe behavior. <\/p>security.tirith_enabled<\/code> and security.tirith_fail_open<\/code>. The tirith_fail_open<\/code> setting controls what happens when Tirith cannot complete a security scan. <\/p>Restrict access to external content<\/h3>
~\/.hermes\/config.yaml<\/code> using security.website_blocklist<\/code>. <\/p>security.allow_private_urls<\/code> overrides this protection and should be enabled only after reviewing the security implications.<\/p>Enable logging and monitoring<\/h3>
~\/.hermes\/logs\/<\/code>. Ensure this directory is accessible to administrators and included in your operational monitoring processes.<\/p>\n
hermes doctor<\/code> periodically to identify known security issues, vulnerable dependencies, and configuration problems that may require attention.<\/p>Common Hermes Agent security threats<\/h2>
\n
Is Hermes Agent more secure than OpenClaw?<\/h2>
What is the most secure way to deploy Hermes Agent?<\/h2>
![\"\"](\"https:\/\/www.hostinger.com\/tutorials\/wp-content\/uploads\/sites\/2\/2023\/02\/VPS-hosting-banner-1024x300.png\")
<\/a><\/figure>