Hermes Agent’s memory layer expands workstation risk beyond CVEs

At a glance

What this is: Repello AI frames Hermes Agent as a persistent workstation agent whose memory, skills, keys and MCP connections create security exposure beyond its small disclosed CVE set.

Why it matters: It matters because AI agent governance now has to cover discovery, memory trust, tool access and runtime controls, not just endpoint detection or patching.

By the numbers:

• Hermes Agent reached 110K GitHub stars in ten weeks.
• Repello AI says Hermes Agent is the fastest-growing open-source AI agent of 2026.

Context

Hermes Agent is a persistent workstation AI agent, not a simple chatbot, so the security problem is the combination of long-lived memory, tool access and local execution. Once an agent can remember across sessions and act through terminals, messaging apps and MCP servers, traditional endpoint assumptions start to fail.

That matters for identity governance because the agent is not only consuming credentials and context, it is also making access-relevant decisions from retrieved memory and delegated tools. The article’s core point is that the control surface moves from the process layer to the prompt and memory layers, where conventional monitoring is weakest.

The starting position is atypical in scale but not in pattern: any persistent agent with broad integration can produce the same governance gap when memory, skills and external tools are left loosely governed.

Key questions

Q: How should security teams govern local AI agents that run on developer endpoints?

A: Treat them as NHIs with identity, access, and lifecycle ownership. Inventory each agent, define which user context it inherits, limit its reachable systems, and require approval for commands that modify code, secrets, or network state. If the agent can execute in the same context as the developer, it needs the same level of governance as other privileged machine identities.

Q: Why do AI agents with long-lived memory create more risk than session-only assistants?

A: Long-lived memory can carry forward reinforced assumptions about trust, preferences, and task priority. That creates a moving security boundary, because the same request may be interpreted differently after state accumulation. Session-only assistants reset more cleanly, while persistent agents can be conditioned across time and then steered into unsafe execution paths.

Q: What breaks when AI skills are deployed without governance gates?

A: The organisation loses control over what the system can do, which data it can touch, and whether its behaviour is acceptable in regulated workflows. That creates a gap between deployment and assurance, so prompt injection, drift, and unsafe outputs can reach customers or decision processes before anyone has a reliable control record.

Q: How can organisations reduce the blast radius of compromised GenAI credentials?

A: Organisations can reduce blast radius by shortening credential lifetime, narrowing scope, isolating sessions, and monitoring behaviour centrally. The goal is to make any compromised token useful for only a small task window, with enough logging to detect misuse before it spreads across the backend stack.

Technical breakdown

Why persistent memory changes the attack surface

Persistent memory turns a session-bound assistant into a stateful system that carries influence forward. In practice, the agent stores prior inputs, retrieved notes and task context in a local database, then rehydrates that data into future prompts. That means an attacker does not need to win the current turn. They only need to poison something the agent will later trust. The real control problem is source provenance for memory entries, because a retrieved item can become an instruction, an authorization hint or a tool trigger long after the original source was seen. See the [[L2|Threat Modelling AI Agents]] guide. Read Threat Modelling AI Agents.

Practical implication: Treat memory as a governed data plane and block untrusted retrieval before privileged tool use.

How skill marketplaces become a supply-chain problem

A skill marketplace is a software distribution channel with execution consequences. If the runtime grants installed skills broad capability, then manifest trust becomes a supply-chain control, not a convenience feature. The common failure mode is trusting install-time checks while leaving runtime behaviour insufficiently constrained. That creates a gap where a malicious or side-loaded skill can operate with more authority than the team intended. For AI agents, the right question is not whether a skill is signed, but whether its publisher, scope and runtime actions are all constrained to the minimum necessary. See the [[L3|OWASP Agentic Applications Top 10]] guide. Read OWASP Agentic Applications Top 10.

Practical implication: Validate skill provenance, scope and runtime permissions before allowing marketplace installation.

Why MCP servers widen the trust boundary

MCP extends an agent’s tool ecosystem to external servers, but every new server expands the trust boundary. If a server can influence prompts, tools or outputs, then compromise of that server can cascade into the agent’s decisions without obvious signal at the endpoint layer. The architectural risk is that the agent may treat remote instructions as ordinary context unless the server identity, capability scope and message provenance are enforced. That is why MCP governance has to include server authentication, capability scoping and prompt-level logging, not just network allowlists. See the [[L12|MCP Security Guide]] for the control pattern. See the MCP Security Guide.

Practical implication: Require server-level trust checks and log every tool interaction at the prompt layer.

Threat narrative

Attacker objective: The attacker wants the agent to act on untrusted context with the authority of a trusted workstation user.

1. Entry occurs when a user installs a marketplace skill, connects an MCP server, or feeds untrusted content into the agent’s memory pipeline.
2. Credential or context abuse follows when the agent retrieves poisoned memory or uses over-scoped provider keys and tool permissions.
3. Escalation happens when the agent turns that retrieved context into privileged tool calls, external requests or disclosure actions on the workstation.
4. Impact is unauthorized data exposure, unsafe actions or durable compromise of the agent’s trust model rather than a single isolated prompt injection.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Hermes-style persistent agents create memory trust debt: the security problem is not just what the agent can do, but what it later remembers and reuses. Once memory is persistent, every imported note, document fragment or message can become an unreviewed control input in a future privileged action. That shifts governance from session approval to source provenance and retrieval policy. Practitioners should treat memory as an access-control surface, not a convenience cache.

The real enterprise risk is architectural, not CVE-led: a small disclosed vulnerability set does not meaningfully reduce the exposure created by broad tools, long-lived state and user-installed extensions. That is because the biggest failure mode is not exploit code against the binary, but legitimate use of the agent’s intended features in ways the enterprise never governed. Prompt-layer observability becomes the decisive control plane for that reason. Practitioners should measure the trustworthiness of feature use, not just patch counts.

AI agent governance now overlaps with NHI governance: when an agent consumes API keys, calls external services and acts through delegations, it behaves like a non-human identity with tool authority. That means identity lifecycle, scoping and revocation matter just as much as model safety. A mature programme should map the agent’s credentials, tool grants and memory sources as one governed estate. Practitioners should align agent control design with NHI-style ownership and review.

Hermes illustrates the shadow AI problem in a more durable form: unmanaged agents are not only hidden, they can persist state across sessions and inherit access through installed skills and connectors. That persistence makes discovery only the first step. The harder task is classification by data class, tool reach and trust boundary so that runtime policy matches the agent’s actual role. Practitioners should govern persistent agents as production workloads, not as personal productivity tools.

From our research library:

• Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.

What this signals

Persistent memory is becoming the defining control problem for workstation agents: once an agent reuses state across sessions, governance has to shift from prompt filtering to memory provenance and retrieval policy. That change matters because the attack path is no longer the live prompt alone, but any trusted-looking context the agent has cached earlier. Practitioners should design controls that decide what can be retrieved, not just what can be said.

AI agent identity is converging with non-human identity governance: the moment an agent carries API keys, talks to external services and performs actions on behalf of a user, it behaves like a governed machine identity. That makes ownership, scope and revocation operational controls rather than conceptual labels. Security teams should classify agent credentials alongside other non-human identities and manage them with the same lifecycle discipline.

For practitioners

• Discover every workstation agent instance Search endpoints for the Hermes CLI, its package location and the local memory store, then inventory connected skills and MCP servers before allowing further use.
• Classify memory sources by trust level Tag entries from user-authored documents, counterparties, web content and messaging sources differently so retrieval policy can block untrusted memory in privileged contexts.
• Constrain provider credentials to short-lived scope Move provider API keys behind an enterprise gateway or scoped token service, then rotate workstation-held secrets when the host or agent is exposed. See the AI Agent Authorisation Guide.
• Approve only signed skills from known publishers Require publisher verification, maintain an allowlist by data class and deny skill installs that request broad hooks without a defined business need.
• Log every tool call at the prompt layer Record prompts, retrieved memory provenance, tool invocations and server identity so investigation can reconstruct what the agent saw and why it acted. See the AI Agent Observability, Audit and Incident Response Guide.

Key takeaways

• Hermes Agent is risky primarily because its architecture combines persistent memory, broad tool reach and external connectors, not because of a large disclosed CVE count.
• The article’s strongest signal is that standard endpoint tooling misses prompt-layer abuse, memory poisoning and skill supply-chain risk.
• Security teams need discovery, classification and runtime control for persistent agents, with memory provenance and scoped credentials at the centre of governance.

Related NHI Mgmt Group resources: Threat Modelling AI Agents · OWASP Agentic Applications Top 10 · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide

Key terms

• Persistent Agent Memory: Stored state that lets an AI agent retain context, preferences, or task history across sessions. When memory includes secrets, transcripts, or behavioural details, it becomes an identity artefact and must be protected like other high-value access material.
• Prompt-Layer Security: Security controls that inspect, govern and log what an AI agent sees, retrieves and sends before those inputs reach tools or model calls. It matters when process-level monitoring cannot distinguish benign execution from hostile context carried inside prompts or retrieved memory.
• Mcp Trust Boundary: The security boundary created by a Model Context Protocol connection between an AI assistant and an external system. Each connection can supply data, trigger actions, or both, so it must be governed like a delegated access path rather than a simple integration.
• Skill Marketplace: A distribution layer where third-party extensions add capabilities to an AI agent or assistant. The security issue is not just the code itself, but the access it requests, the data it can read, and the way it can steer privileged actions through the host runtime.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for teams that need to govern non-human identities, delegated access and machine-driven decisions across modern estates.