The scariest AI agent is not the one that writes a strange paragraph. It is the one that can read private data, process untrusted instructions, and send information somewhere else.
That combination is the real security problem. Prompt injection gets most of the attention, but prompt injection alone is not the whole incident path. The high-risk pattern is the overlap of three capabilities:
- The agent can access private or sensitive data.
- The agent consumes untrusted content.
- The agent can use tools that mutate state, communicate externally, or move data across a boundary.
Simon Willison popularized this as the lethal trifecta for AI agents: private data, untrusted content, and external communication. The phrase is useful because it shifts the conversation away from “can the model be tricked?” and toward “what damage can the system do if the model is tricked?”
For self-hosted assistants such as OpenClaw and research-oriented agent runtimes such as Hermes, that distinction matters. These systems are not merely chat windows. They sit near files, browser sessions, chat channels, shell commands, plugins, skills, long-term memory, and API credentials. Secure AI agents are built by reducing the overlap between those powers.
🧭 Agents Are Not Prompt Wrappers
A prompt wrapper produces text. An agent produces side effects.
That is the security line. Once an LLM can choose tools, the output is no longer just a response on a screen. It can become a browser action, a shell command, a commit, a message, a webhook call, a database update, a ticket, a calendar invitation, a memory write, or a purchase.
OpenClaw is a clear example because its own documentation positions it as a self-hosted gateway that connects chat apps and channel surfaces to AI coding agents. The Gateway becomes the routing center for sessions, channels, WebChat, mobile nodes, and assistant interactions across platforms such as Slack, Telegram, WhatsApp, Discord, and others.
Hermes is a different kind of example. Its architecture is built around a reusable agent core with a large tool registry, terminal backends, profiles, memory providers, skills, messaging gateways, and automation surfaces. Its docs describe terminal tools that can run across local, Docker, SSH, Daytona, Modal, and Singularity backends, and profile isolation where each profile gets its own HERMES_HOME, config, memory, sessions, and gateway process.
Those capabilities are the reason agents are useful. They are also why security has to move from prompt policy into system design.
🧭 The Lethal Trifecta
The trifecta separates ordinary model weirdness from operational risk.
An agent that reads untrusted content but cannot see secrets and cannot send data anywhere may produce bad output, but the blast radius is limited. An agent that can see private data but never ingests attacker-controlled text is still sensitive, but indirect prompt injection has less leverage. An agent that can send messages but cannot read secrets or untrusted instructions has a different automation risk profile.
The dangerous zone appears when all three overlap.
Imagine an agent with access to a private calendar, authenticated browser session, local files, Slack, and web search. It opens a page that contains hidden instructions telling it to copy private calendar details into an external form. If the agent treats that page as instruction instead of data, and if the tool policy allows outbound communication, the exfiltration path already exists.
The model does not have to become malicious. It only has to follow the wrong source of authority.
🧭 Prompt Injection Is a Control-Plane Attack
Indirect prompt injection works because agents blend instructions and data.
A malicious email, issue comment, PDF, web page, chat message, spreadsheet cell, image, or tool output can contain text that attempts to override the agent’s original task. In a normal document workflow, that text is data. In an agent loop, the same text may land near the model while it is deciding what to do next.
This is why prompt injection is not the same thing as jailbreaking. Jailbreaking is usually about getting a model to say something it should not say. Prompt injection against an agent is about hijacking the control plane that decides which tools are called, what arguments are passed, and which outputs are trusted.
The defense starts with source separation. System instructions, developer instructions, user requests, retrieved documents, tool outputs, long-term memory, and third-party skills should not be treated as peers. Untrusted content should be parsed, quoted, summarized, and constrained as data. It should not be allowed to silently write memory, install skills, approve actions, expand the tool allowlist, or choose outbound destinations.
OWASP’s LLM security work maps this concern across several categories, including prompt injection, sensitive information disclosure, insecure plugin design, and excessive agency. For agents, these are often not separate problems. They reinforce each other.
🧭 Private Data Turns Mistakes Into Incidents
Agents are often placed near exactly the data attackers want: API keys, browser cookies, private repositories, invoices, internal documents, customer records, calendars, chat history, credentials, and source code.
That is why the question is not “does the agent have access?” The better question is “does the agent have the minimum authority needed for this task?”
A browser agent that only needs a test account should not use the operator’s real browser profile. A repo agent should not see the entire home directory. A calendar assistant should not inherit broad email-sending permissions. A research agent should not have production API keys in its environment. A support assistant should not share memory across unrelated users.
OpenClaw’s security documentation is especially relevant here because the Gateway is powerful by design. Its guidance warns that non-loopback binds expand attack surface, that broad port exposure is risky, and that Docker-published ports need firewall policy in Docker’s forwarding chains, not only host INPUT rules. That is practical security advice for a system that bridges chat surfaces and agent authority.
Hermes approaches the same class of risk through profile isolation, backend selection, and a hub model for skills. The docs show each profile getting separate state, and the skills system runs hub-installed skills through security scanning that checks for data exfiltration, prompt injection, destructive commands, supply-chain signals, and related threats.
These are architecture controls. They are more meaningful than asking the model to be careful.
🧭 Tools Create the Exfiltration Path
The third side of the trifecta is tool authority.
A tool can send an email, post to Slack, make an HTTP request, open a browser, write a file, commit code, call a payment API, create a ticket, rotate infrastructure, or execute a shell command. Tool use is where model output becomes action.
That means tool policy should be explicit before the agent starts:
- Which tools are available for this task?
- Which arguments are allowed?
- Which file paths can be read or written?
- Which domains can receive outbound traffic?
- Which identities and credentials are available?
- Which actions require approval?
- Which tool outputs can become memory?
- Which logs prove what happened afterward?
If the answer is “the agent can use everything because the prompt says not to misuse it,” the system is not hardened.
A safer pattern is a task-scoped tool bundle. The agent that summarizes invoices can read a specific inbox label, read a specific storage prefix, and write a draft report. It cannot send arbitrary email, browse arbitrary domains, read unrelated folders, or install new tools. The agent that updates a repo can read and write the repo workspace, run tests, and open a draft pull request. It cannot access personal documents, production secrets, or live deployment credentials.
The prompt still matters, but the tool boundary carries the risk.
🧭 Sandboxing Is Necessary, Not Sufficient
Sandboxing is a core control because it limits what the action plane can touch when the model chooses badly.
For coding agents, that usually means commands run inside a container, remote workspace, or other isolated execution environment. For browser agents, it means a dedicated browser profile, a limited account, and a controlled network path. For self-hosted assistants, it means the gateway, channel plugins, nodes, secrets, and workspace mounts are treated as separate trust boundaries.
But a sandbox only helps if it is configured with least privilege.
A container with the host Docker socket mounted is not a strong boundary. A workspace with the whole home directory mounted is too broad. A browser sandbox using a real personal profile can leak cookies, sessions, saved passwords, and private history. A temporary token with organization-wide scope is still dangerous. A gateway bound to the wrong interface can expose more than the operator intended.
Use sandboxes, but constrain mounts, networks, secrets, identities, and outbound channels. Then test the boundary with hostile content, not just happy-path tasks.
🧭 Memory Poisoning Persists the Attack
Long-term memory turns a one-time injection into durable risk.
If an untrusted document can convince the agent to store a new preference, rule, shortcut, credential note, or skill, the attack may survive the current session. The next task can start from poisoned state. This matters for OpenClaw-style inspectable memory, Hermes profile memory, Honcho-backed user modeling, Letta-style memory blocks, and any assistant that writes summaries or learned procedures for later use.
Hermes’s Honcho docs describe memory that can model user preferences, goals, communication style, and patterns over time. That is powerful. It also means memory writes deserve the same security treatment as code changes or configuration changes.
Memory should have provenance. Sensitive memories should be reviewable and deletable. Inferred facts should be labeled as inferred. Untrusted source material should not automatically become durable instruction. Skills should be reviewed as executable supply-chain artifacts, not treated as harmless notes.
For many teams, the easiest policy is simple: untrusted content can be summarized into task-local notes, but it cannot create persistent memory without approval.
🧭 Skills and Plugins Are a Supply Chain
OpenClaw and Hermes both make extensibility central. That is one reason they are interesting. It is also why skill and plugin governance belongs in the security model.
An agent skill is not just a helpful Markdown file. It can contain procedures, scripts, dependencies, environment assumptions, tool expectations, and sometimes installation steps. A channel plugin can expose a new ingress path. A browser or shell tool can expand what the model can touch. A memory provider can change what persists.
Treat those artifacts like software dependencies:
- Pin versions when stability matters.
- Inspect install scripts and required binaries.
- Review requested environment variables.
- Prefer trusted sources for high-authority tasks.
- Separate community skills from internal production skills.
- Re-scan installed skills after updates.
- Keep a record of which agent used which skill during a run.
Hermes’s skills hub documentation makes this direction explicit with inspect, install, audit, trust levels, provenance tracking, and security scanning for hub-installed skills. That is the right instinct. Agent capabilities should be discoverable, but they should not be casually trusted.
🧭 A Practical Hardening Checklist
Start by narrowing the task. An agent that can do one thing with one input source and one tool set is easier to secure than an always-on assistant with every integration enabled.
Use separate identities. Give the agent task-specific accounts and credentials. Avoid sharing a user’s full browser profile, shell environment, chat account, or API keychain.
Isolate the action plane. Run commands, browser actions, and code execution in a container, remote workspace, or equivalent sandbox with narrow mounts and controlled networking.
Restrict outbound communication. Exfiltration needs a destination. Domain allowlists, approval gates, egress policy, and network logging reduce the impact of prompt injection.
Add approvals around irreversible actions. Sending external messages, deleting files, changing permissions, spending money, deploying code, installing skills, and writing durable memory should not be silent default actions.
Log and replay tool use. If something goes wrong, the team needs to know what the agent read, what it retrieved, which instructions it treated as authoritative, which tools it called, and what data left the boundary.
Test with hostile inputs. Put prompt-injected text in emails, web pages, PDFs, issue comments, spreadsheets, chat messages, image descriptions, and tool outputs. The test is not whether the model says it resisted. The test is whether the architecture blocks unsafe tool calls.
Create a kill switch. Operators need a fast way to stop a runaway agent, revoke its tokens, freeze its gateway, disable its channel, and preserve logs for review.
Rotate credentials after incidents. If an agent may have exposed a token, browser session, webhook secret, or API key, treat it like any other credential exposure.
🧭 How This Changes OpenClaw vs Hermes Evaluation
The OpenClaw versus Hermes question is not only “which agent feels better?” It is “which trust boundary matches the job?”
OpenClaw is compelling when you want a self-hosted assistant reachable from everyday channels. That means the Gateway, pairing flow, channel plugins, node permissions, remote access mode, and firewall rules become first-class security decisions. The convenience is real, but the ingress surface is broad.
Hermes is compelling when you want a developer-oriented agent runtime with profiles, skills, memory providers, messaging integrations, and multiple execution backends. That means profile isolation, backend choice, skill provenance, memory governance, and tool registry policy become first-class security decisions. The flexibility is real, but the capability surface is large.
Neither architecture should be evaluated as a chatbot. Evaluate both as distributed systems with model-mediated control flow.
🧭 The Bottom Line
Secure AI agents are built by reducing overlap between private data, untrusted content, and powerful tools.
Prompts still matter. Model choice still matters. Stronger models may resist more attacks. But the durable controls are architectural: least privilege, sandboxing, scoped credentials, tool allowlists, memory review, outbound restrictions, audit logs, skill scanning, version pinning, and human approval points.
If an agent can see secrets, read attacker-controlled content, and send messages or network requests, assume prompt injection will eventually find that path. Design the system so the path is blocked before the model has to be perfect.
🧭 Sources and Further Reading
- Simon Willison: The lethal trifecta for AI agents – the framing for private data, untrusted content, and external communication.
- OpenClaw documentation – self-hosted gateway, channels, sessions, memory, and agent-native positioning.
- OpenClaw gateway security docs – gateway exposure, binding, Docker port publishing, and hardening guidance.
- Hermes Agent architecture – tool registry, terminal backends, profiles, gateway, and memory subsystems.
- Hermes Agent skills system – skill installation, provenance, scanning, audits, and trust levels.
- Hermes Honcho memory docs – persistent memory, user modeling, and memory-provider behavior.
- OWASP Top 10 for Large Language Model Applications – prompt injection, sensitive information disclosure, plugin design, excessive agency, and related LLM app risks.
Recommended Books & Tools
If you are securing AI agents, focus on application security, isolation, identity, and production operations before buying more automation.
Books for Secure Agent Builders
- Designing Data-Intensive Applications – Useful for reasoning about state, logs, boundaries, and recovery.
- Security Engineering – A deep foundation for threat modeling, trust boundaries, and real-world security design.
- Site Reliability Engineering – Helpful for observability, incident response, operational controls, and safe production rollouts.
Practical Security Tools
- YubiKey 5C NFC – Hardware-backed authentication is a practical baseline when agent workflows touch developer and cloud accounts.
- Samsung T7 Shield Portable SSD – Useful for encrypted sandbox snapshots, offline backups, and controlled experiment workspaces.
Secure agent design starts with least privilege, isolated execution, scoped credentials, and auditable tool use.