Securing Autonomous AI Agents: Lessons from OpenClaw and Hermes Agent

I watch Youtube videos where developers and builders get excited to use the latest autonomous AI agent. The top two are OpenClaw and Hermes Agent. Even Nvidia got into the mix with NemoClaw but what does that mean for security professionals? How do we prepare or think about implementing security controls for the inevitable corporate push to evaluate and utilize these agents? I hope to answer or at least help get a start in the right direction.

Introduction

The emergence of autonomous artificial intelligence agents represents a significant change in enterprise security architecture. Traditional chatbots primarily generate text. Agentic platforms such as OpenClaw and Hermes Agent can browse websites, read and modify files, execute shell commands, communicate through messaging platforms, call external APIs, install extensions, and maintain state across sessions.

These capabilities transform an AI model from an information-processing component into an active system user or administrator. An agent may possess credentials, network access, persistent memory, access to sensitive files, and authority to initiate consequential transactions. From a security perspective, it should be treated less like a chatbot and more like a highly privileged service account.

OpenClaw and Hermes Agent illustrate both the potential and the danger of this design pattern. Although their implementations and defensive controls differ, both expose a common set of risks involving prompt injection, excessive privilege, insecure tool execution, extension supply chains, persistent state, and exposed management interfaces.

The central security lesson is straightforward: an autonomous agent should never be trusted merely because the underlying language model has been trained to refuse malicious requests. Model behavior is not a substitute for enforceable security boundaries.

Conventional computing systems attempt to separate instructions from data. Agentic AI systems partially consolidate that separation.

An autonomous agent may receive a legitimate instruction such as:

Review the documents in this folder and summarize the findings.

One of those documents could contain text instructing the model to disregard the user, retrieve credentials, upload files, or execute a command. Because the agent has both the user's instructions and the document's contents as natural-language context, it may interpret hostile data as an operational directive. The model must infer which text has authority, but that judgment is probabilistic rather than enforced by a traditional processor privilege boundary.

Prompt injection becomes significantly more dangerous when a model can invoke tools. A successful injection is no longer limited to producing an incorrect response. It can become an execution chain:

The agent reads an email, web page, document, message, or skill file.
Malicious content alters the agent's intended behavior.
The agent invokes a shell, browser, file, messaging, or API tool.
The tool operates using the agent's credentials and network position.
Data is modified, deleted, disclosed, or transmitted.

This is why prompt injection must be treated as an input-handling and authorization problem, not merely a content-moderation problem.

Similarities Between OpenClaw and Hermes Agent

Indirect prompt injection

Both platforms can ingest untrusted content from external sources. OpenClaw can interact through messaging applications, browsers, files, and installed skills. Hermes can process context files, external content, tools, plugins, and persistent skills.

In both cases, malicious instructions may be embedded in content that the user did not intend to authorize. The danger increases when the same agent has access to shell execution, credentials, private files, or external communication tools.

No prompt scanner can provide a complete solution. Pattern matching may identify obvious attacks, but an attacker can encode, fragment, translate, obfuscate, or contextually disguise malicious instructions. Scanning should therefore supplement — not replace — sandboxing, authorization, least privilege, and deterministic policy enforcement.

Excessive filesystem and command access

Both platforms can operate with significant local authority when configured to use host-based execution.

OpenClaw's current security documentation explicitly describes a trusted, single-operator model in which host execution may be allowed without approval prompts. Its documentation also warns that execution approvals are guardrails for operator intent rather than strong hostile-tenant isolation. Strong boundaries require sandboxing and host isolation.

Hermes supports local, Docker, SSH, Daytona, Singularity, and Modal execution backends. Its local and SSH backends can maintain shell state across tool calls, while its Docker backend provides stronger controls such as dropped Linux capabilities, prevention of privilege escalation, and process limits.

The risk is not simply that an agent can execute a dangerous command. Filesystem and command access can also be composed into less obvious attack chains:

Reading .env files, shell histories, SSH configuration, or application credentials
Writing startup scripts or scheduled jobs
Modifying agent instructions or persistent memory
Creating scripts in one tool call and executing them in another
Using an interpreter to bypass path-based controls
Following symbolic links outside an approved workspace
Compressing and exfiltrating sensitive directories
Establishing persistence through plugins, shell profiles, or service definitions

Path allowlists alone are insufficient because interpreters and shell utilities can indirectly access resources outside the apparent command target.

Skill and plugin supply-chain risk

Agent extensions differ from conventional application plugins because they can influence both execution and reasoning.

An extension might include executable code, installation instructions, natural-language directives, tool definitions, dependency references, or examples that the model treats as authoritative. A malicious extension can therefore attack the host through code, manipulate the agent through prompt injection, or combine both approaches.

OpenClaw's ClawHub ecosystem has experienced malicious skill distribution, including extensions intended to steal credentials, browser data, cryptocurrency information, SSH material, and other sensitive content. Reporting in early 2026 described hundreds of suspicious or malicious submissions, demonstrating how rapidly a popular agent marketplace can become a software-supply-chain target.

Security discussions within the OpenClaw project have also identified the need for permission manifests, signing, runtime restrictions, integrity verification, and stronger review processes for skills.

Hermes similarly supports plugins and persistent skills. This creates a risk that compromised content will survive beyond the original session. A successful prompt injection that modifies memory or creates a reusable skill is not merely an isolated event; it may become persistence.

Organizations should therefore treat agent skills as executable software artifacts, even when they appear to consist primarily of Markdown or natural-language instructions.

Management-interface and API exposure

Both platforms become substantially more dangerous when their management surfaces are reachable from untrusted networks.

OpenClaw experienced CVE-2026–25253, a high-severity vulnerability affecting versions through 2026.1.28. The Control UI accepted a gatewayUrl from a query string and automatically connected to it, transmitting the stored gateway token. An attacker who obtained that token could connect to the gateway, alter sandbox or tool policies, and invoke privileged actions. Version 2026.1.29 contained the patch.

Hermes experienced CVE-2026–53869, a DNS-rebinding vulnerability affecting versions before 0.16.0. WebSocket endpoints could bypass Host and Origin validation because normal HTTP middleware did not protect the WebSocket upgrade path. The weakness could allow a remote attacker to interact with terminal or event endpoints through a victim's browser.

Hermes was also affected through version 0.12.0 by CVE-2026–11461, involving authorization bypass in session resolution by title. An authenticated or low-privileged attacker could potentially access a session that should have belonged to another user.

These vulnerabilities demonstrate that "local-first" does not mean "network-safe." Browser behavior, DNS rebinding, WebSockets, reverse proxies, tunneling services, container port publication, and gateway configuration can expose a supposedly local service.

How Security Professionals Should Evaluate Autonomous Agents

Organizations should evaluate agent deployments through the same disciplines used for privileged workloads, third-party software, and non-human identities.

The review should begin with a risk assessment that identifies:

What information the agent can read
What systems it can modify
Which credentials it possesses
Which network destinations it can reach
Which sources can provide untrusted input
Which tools can create persistence
Whether one agent can delegate to another
Which actions require human authorization
How compromise would be detected and contained

The assessment must include compound attack paths. A file-read permission may appear low risk until it is combined with network egress. Browser access may appear harmless until the browser can retrieve internal resources. A limited shell may become dangerous when it includes Python, PowerShell, Bash, package managers, or cloud command-line tools.

Recommended Security Controls

1. Isolate execution

Do not run experimental agents directly on employee workstations, domain-joined systems, administrative jump hosts, or production servers.

Use a container, hardened virtual machine, isolated cloud account, or dedicated physical system. Isolation should include:

A non-root runtime account
Read-only base filesystems where practical
Dropped Linux capabilities
No privilege escalation
Process and resource limits
No host Docker socket
No unrestricted host mounts
No access to personal home directories
Restricted device access
Automatic destruction and rebuilding of execution environments

Containers alone should not be assumed to provide a sufficient boundary for hostile code. Higher-risk deployments may require micro-VMs, dedicated VMs, or physically separate systems.

2. Apply least privilege to agent identities

Every agent should have its own identity. It should not inherit the interactive user's credentials, browser session, SSH agent, cloud profile, or operating-system token.

Credentials should be:

Short lived
Scoped to the required action
Bound to the workload when possible
Rotated automatically
Revocable without affecting a human account
Prohibited from privilege delegation
Stored outside files the agent can freely read

An agent that needs to read support tickets does not necessarily need permission to close them. An agent that drafts an email does not necessarily need permission to send it.

3. Enforce action-level authorization

Authorization should be evaluated when a tool is invoked — not merely when the initial prompt is submitted.

Policies should consider:

The requested operation
The target resource
The sensitivity of the data
The external destination
The requesting user
The agent identity
The source of the triggering content
The current session
The cumulative sequence of prior actions

High-impact actions should require human approval. Examples include deleting files, modifying security controls, sending external messages, installing software, transferring funds, changing access permissions, exporting data, creating persistent tasks, and accessing production systems.

4. Restrict network access

Default-deny egress should be the preferred policy.

Agents should not have unrestricted access to:

Cloud metadata services
Loopback services
Private address ranges
Management networks
Kubernetes control planes
Internal DNS zones
Credential endpoints
Unapproved SaaS services
Arbitrary file-upload sites
Newly registered or uncategorized domains

Use an authenticated egress proxy, domain allowlists, DNS monitoring, TLS inspection where legally and operationally appropriate, and destination-aware data-loss prevention.

5. Govern skills and plugins

Create an enterprise-controlled registry of approved extensions. Do not permit agents or users to install arbitrary community skills directly into operational environments.

Each extension should undergo:

Source review
Dependency scanning
Malware analysis
Secret scanning
License review
Publisher verification
Integrity validation
Permission analysis
Behavioral testing in isolation
Version pinning
Formal approval

Extensions should declare required filesystem paths, network destinations, APIs, secrets, and commands. Undeclared access should be denied by runtime policy.

6. Secure management interfaces

Agent APIs, dashboards, gateways, and WebSocket endpoints should not be exposed directly to the internet.

Place them behind:

Strong authentication
Phishing-resistant multifactor authentication
Reverse proxies
Firewall rules
Private network access
Mutual TLS where appropriate
Origin and Host validation
Session expiration
Rate limiting
Secure WebSocket configuration
Centralized access logging

Binding a service to 0.0.0.0 should require an explicit security review. Local services should remain on loopback unless remote access is operationally necessary.

7. Protect memory and persistent state

Agent memory should be considered both sensitive data and executable influence.

Organizations should prevent untrusted content from silently altering system instructions, durable memory, skills, policies, or configuration. Memory changes should be attributable, reviewable, versioned, and reversible.

Security teams should also define retention periods and deletion procedures. Persistent conversational state may contain credentials, proprietary information, personal data, operational details, and malicious instructions.

8. Implement identity-attributed observability

Logging should capture more than prompts and responses. It should record:

User identity
Agent identity
Model and version
Session and delegation identifiers
Tool name
Structured tool parameters
Files accessed
Commands executed
Network destinations
Credential identities used
Approval decisions
Policy decisions
Data transferred
Extension installation or modification
Persistent-memory changes
Resulting system state

Security operations teams should monitor for unusual tool sequences, privilege expansion, repeated policy denials, new destinations, excessive data access, encoded commands, persistence attempts, and unexpected session resumption.

9. Maintain vulnerability and configuration management

Agent frameworks are changing rapidly. Organizations should inventory installed versions, monitor vendor advisories, establish patch deadlines, and test updates before deployment.

Configuration should be managed as code. Security teams should continuously detect:

Disabled approval modes
Host execution backends
Public listener addresses
Unrestricted filesystem mounts
Broad network access
Unpinned extensions
Long-lived credentials
Missing authentication
Disabled scanning
Debug or insecure flags

An upgrade should never be assumed to preserve an organization's security posture. Defaults, configuration keys, approval semantics, and backend behavior can change between releases.

Governance and Policy Requirements

An enterprise policy for autonomous agents should establish at least three deployment categories.

Prohibited environments should include classified systems, regulated production data, domain controllers, security-management systems, privileged administration workstations, and environments in which reliable isolation cannot be demonstrated.

Experimental environments should use synthetic or sanitized data, dedicated identities, isolated networks, approved models, restricted tools, and no access to production credentials.

Operational environments should require documented threat modeling, system ownership, security authorization, extension governance, least-privilege identities, external policy enforcement, monitoring, incident-response procedures, and periodic reassessment.

The policy should also identify who is accountable when an agent acts. Responsibility cannot be assigned to the model. A human system owner must remain accountable for the agent's permissions, configuration, approved use cases, and resulting actions.

Conclusion

OpenClaw and Hermes Agent demonstrate the central challenge of autonomous AI: the same features that make an agent useful — tool access, persistence, broad context, extensibility, and autonomy — also create its greatest risks.

OpenClaw provides a flexible, local-first agent environment but commonly operates within a trusted-operator model that requires deliberate hardening and strong external isolation. Hermes provides a more visible collection of security controls, including sandbox backends, approval modes, authorization mechanisms, and command scanning. Those controls are valuable, but they can still be weakened by configuration, permissive execution modes, vulnerable interfaces, or excessive access.

Neither platform should be secured primarily through model alignment, prompt wording, or user caution. Security must be imposed by deterministic controls outside the model:

Isolate the execution environment.
Treat the agent as a non-human privileged identity.
Deny access by default.
Separate untrusted content from executable authority.
Require independent approval for consequential actions.
Restrict credentials and network egress.
Govern extensions as software supply-chain components.
Monitor every tool invocation and state change.
Plan for compromise.

Autonomous agents should not be trusted to decide the limits of their own authority. Those limits must be defined and enforced by the surrounding architecture.

Contents