Hermes Agent Security: What Can Your MCP Tools Reach?

Following the path from untrusted content to agent permissions, credentials, and external actions.

Hermes Agent is useful because it can do more than answer questions. It can run tools, connect to MCP servers, schedule work, and continue tasks across sessions.

That connectivity changes the security question. It is no longer enough to ask whether a prompt is safe or whether a file contains a suspicious string. We need to ask what an untrusted piece of content can reach, through which agent context, with which permissions, and with what side effect at the end.

The path is the important unit:

Untrusted PR or README → agent context → tool permission → credential → external action

This is the focus of this post. I’ll use Hermes Agent and Ship Safe 10.0.0 as a concrete example, not because Hermes is uniquely unsafe, but because it makes the modern agent boundary easy to see.

Controls inside an agent are not an independent security review

Hermes includes meaningful safety controls. Command execution can require approval for dangerous operations. MCP integrations can filter credentials. Sandboxing and session controls can reduce the blast radius. Cron also has lifecycle checks around scheduled work.

But runtime controls and independent review answer different questions. Hermes can enforce a policy while it runs. A security review can inspect whether repository content, configuration, persistence, or an update path quietly bypasses that policy before the agent ever acts.

Why ordinary scanning is not enough

A scanner can find a suspicious pattern. That is useful, but it is not the same as proving a vulnerability.

A prompt-shaped string in a pull request is evidence worth investigating. It does not, by itself, prove that an agent can reach a credential or execute a consequential tool call.

A useful security verdict should show the evidence chain and say what remains unknown. A noisy tool trains developers to ignore warnings. An overconfident tool can turn an unproven hypothesis into a blocking decision.

Five surfaces to review

1. Repository content
   Pull requests, issues, comments, README files, generated docs, and test fixtures can all become agent context. Treat them as data, not instructions.

2. Agent instructions and configuration
   System prompts, project instructions, tool allowlists, hooks, and defaults shape what the model is willing to do. They deserve code review and change control.

3. MCP tools and descriptions
   The tool name and description influence how an agent understands a capability. A read-looking tool that can write, install, upload, or execute is a boundary problem.

4. Credentials and runtime access
   Environment variables, config files, filesystem mounts, network egress, and cloud tokens determine the reachable blast radius.

5. Persistence and scheduled work
   A create path may be carefully guarded while an update, retry, import, or restore path saves a changed payload without applying the same guard. Scheduled jobs then act on whatever was persisted.

What Ship Safe 10.0.0 adds

Ship Safe adds an investigation layer for this kind of review. The scanner reports detections and citations. The investigation layer derives a verdict from the evidence.

Confirmed, likely, unresolved, and refuted are separate outcomes. A finding whose citations do not resolve decides nothing.

Version 10.0.0 adds Hermes Agent coverage for:

• terminal backend posture
• ACP and TUI gateway boundaries
• cron lifecycle and retained authority
• credential paths to reachable external effects
• MCP initialization and modern discovery

The evidence is also carried into JSON and SARIF for local review and CI.

The goal is deliberately narrower than “AI found a vulnerability.” The goal is to answer:

What path is visible in the code, where does it cross a permission boundary, and what can we actually prove?

The demo: a harmless cron fixture

The demonstration uses a pinned Hermes source trace and deliberately small local fixtures. It does not run a production command, use credentials, contact an external service, or attempt to exploit a live Hermes installation.

In the vulnerable fixture:

1. create_job checks the lifecycle before saving a schedule.
2. update_job merges a new prompt or script with the stored job and saves it after only a non-empty check.
3. Later, run_job reads the persisted record and dispatches to the agent or script runner.

The missing symmetry is the finding. A changed payload can take a different path through persistence than the original creation payload, and the scheduler eventually reaches the effective value from storage.

Run the investigation locally:

npx ship-safe@10.0.0 investigate . --all

The result is intentionally not a dramatic exploit claim. Ship Safe reports one unresolved high-severity finding, HERMES_CRON_UPDATE_LIFECYCLE_GUARD_BYPASS, because the fixture proves the structural gap but does not establish every runtime consequence.

That restraint is the point.

How the fix closes the path

The safe counterpart re-checks the effective prompt and script after merging the update and before save_jobs. The guard runs on the value that will actually be persisted, not only on the value supplied during creation.

Ship Safe also checks for retained run-scoped authority. If a scheduled action can still reach a capability after an exception or retry without cleanup in a function-level finally block, the path remains open for investigation.

These checks do not replace Hermes controls. They complement them by reviewing the lifecycle around the agent: source content, configuration, persistence, scheduling, and the boundary between a capability and its side effect.

A practical pre-merge checklist

• Treat repository content and pull requests as untrusted input.
• Default MCP tools to the smallest useful permission, preferably read-only.
• Pin and review MCP servers, tool definitions, hooks, and agent instructions.
• Keep credentials short-lived, scoped, and outside the agent’s default filesystem view.
• Require explicit approval for destructive or external side effects.
• Re-run the investigation after changes and keep unresolved findings visible for human review.

What this release does not claim

Ship Safe is not a replacement for Hermes Agent, and this release does not claim that every finding is exploitable. It does not certify a deployment or make external or custom schedulers disappear from the threat model.

It makes the evidence path easier to inspect and makes uncertainty explicit.

That distinction matters for security engineers. Automated benchmarks can tell us whether a rule fired consistently. They cannot, by themselves, prove that an application confirmation is true. The final step is still a person reading the cited code and checking the reachable side effect.

Hermes gives developers a capable agent. That capability is also a supply-chain boundary: code, instructions, tools, credentials, and scheduled work all meet there.

The safest workflow is layered:

• Hermes enforces runtime controls.
• Deterministic analysis surfaces repeatable evidence.
• An investigation layer traces the path.
• A human decides whether the evidence supports the verdict.

Ship Safe on GitHub · Ship Safe 10.0.0 release · shipsafe.sh