Executive Summary
Agent Remit (as declared)
Hermes is a single-tenant personal AI agent that assists one authorized operator with open-ended work — conversation, coding, driving a real terminal and browser, running scheduled cron jobs, delegating to isolated subagents, and learning across sessions through persistent memory and self-created skills. It is reachable through many front ends (CLI/TUI, an Electron desktop app, an editor/ACP adapter, a ~20-platform messaging gateway, and an optional HTTP/API surface) and must apply identical trust rules everywhere. The remit's defining constraints: catastrophic irreversible commands MUST be refused unconditionally with no override; every network-exposed surface MUST require an operator allowlist or auth layer and MUST NOT fail open; dangerous shell commands MUST require human approval on host-reaching backends; and operator credentials MUST NOT leak to lower-trust child processes, logs, or outbound payloads.
Behavior Summary (as observed)
The dominant pattern is a mature, defense-in-depth agent whose real security boundary is deliberately pushed to OS-level isolation, leaving the in-process controls as strong-but-bypassable heuristics — and the highest-value residual risk is the external-input-to-host-execution chain. Untrusted content (open web, inbound messages, MCP responses) enters the LLM context and can drive the `terminal`/`execute_code` tools; on the default unsandboxed `local` backend the only in-process gate is a regex dangerous-command denylist plus a human approval prompt, and that prompt fails **open** (auto-approves) in a headless, non-interactive, non-gateway, non-cron context. The unconditional hardline floor (rm -rf /, mkfs, fork bomb, shutdown) still blocks the catastrophic cases even under `--yolo`/`approvals.mode: off`, and credential scoping, gateway default-deny authorization, and SSRF protection are all real and operative — so the picture is a well-engineered system with a small number of acknowledged, operator-posture-dependent gaps rather than systemic weakness.
Scope of Analysis
A large Python codebase (`run_agent.py`/`AIAgent` core, ~750 KB `cli.py`, `hermes_state.py`) plus an Electron+React desktop app in `apps/desktop` that spawns a headless backend via `hermes serve --host 127.0.0.1 --port 0`. Enforcement is genuinely code-level and centralised: `tools/approval.py` holds an unconditional hardline blocklist and a ~47-pattern dangerous-command detector feeding one shared `_run_approval_gate`; `tools/env_passthrough.py` + `tools/environments/local.py` strip provider credentials from sandbox child processes behind a blocklist skills and config cannot override; `gateway/authz_mixin.py` default-denies unauthorized messaging callers; `gateway/platforms/api_server.py` refuses to start without a strong `API_SERVER_KEY`; `tools/url_safety.py` blocks cloud-metadata/SSRF targets; and `hermes_logging.py` writes rotating, secret-redacting logs. The default `local` terminal backend runs LLM-emitted commands directly on the host, and the project's own `SECURITY.md` frames every in-process screen (approval gate, redaction, Skills Guard) as a heuristic, not a boundary — the only boundary being OS-level isolation the operator must select.
Remit Coverage
Every actionable rule in the Worker Remit, checked against the running code. Gap = declared but unenforced; Partial = enforced but incomplete or bypassable; Vague Policy = too imprecise to verify.
| Rule ID | Section | Rule (quoted) | Status | Finding |
|---|---|---|---|---|
| R-01 | Non-Goals (Out of Scope) | "Serve untrusted, unauthenticated callers on any surface." | Verified | — |
| R-02 | Non-Goals (Out of Scope) | "Emit outbound telemetry, usage attribution, analytics, or third-party identifier tagging without an explicit operator opt-in." | Verified | — |
| R-03 | Non-Goals (Out of Scope) | "Move operator credentials or session-authorization material to any destination outside the operator's trust envelope." | Verified | — |
| R-04 | Non-Goals (Out of Scope) | "Act as a general web service exposed to the public internet without an external authentication/VPN/firewall layer in front of it." | Verified | — |
| R-05 | Approved Communication Channels | "Any messaging platform without a configured allowlist must serve no one (fail closed)." | Verified | — |
| R-06 | Approved Communication Channels | "Loopback bind is the default; a non-loopback bind must engage authentication." | Verified | — |
| R-07 | Approved Communication Channels | "Password-only auth must not be used for a publicly-exposed backend." | Verified | — |
| R-08 | Tools and Capabilities | "Any terminal command matching a dangerous/destructive pattern must require explicit human approval before it runs (on host-reaching backends)." | Partial | PRAX-2026-07-11-001 |
| R-09 | Tools and Capabilities | "Installing a third-party skill or plugin must surface its contents for operator review before it is loaded/executed." | Verified | — |
| R-10 | Tools and Capabilities | "/reload-mcp, and destructive session commands (/clear, /new, /reset, /undo) must confirm before discarding state, unless the operator has turned that confirmation off." | Verified | — |
| R-11 | Tools and Capabilities | "Any tool whose sole function is to exfiltrate operator credentials, environment secrets, or session tokens to an external destination." | Verified | — |
| R-12 | Data Boundaries | "Credentials and gateway tokens MUST NOT be passed into lower-trust child processes (shell subprocesses, execute_code, MCP subprocesses, cron scripts) except variables the operator or a loaded skill has explicitly declared as passthrough." | Verified | — |
| R-13 | Data Boundaries | "Secrets MUST NOT be written to logs, transcripts, error messages returned to the model, or any outbound adapter payload." | Verified | — |
| R-14 | Data Boundaries | "Pairing codes and auth secrets MUST NOT be logged to stdout or persisted in world-readable files." | Verified | — |
| R-15 | Data Boundaries | "Operator PII in the system-prompt session-context block SHOULD be redactable and MUST NOT be broadened beyond what routing requires." | Vague Policy | — |
| R-16 | Data Boundaries | "Credentials MUST NOT be committed to version control or stored in the main (shareable) config file." | Verified | — |
| R-17 | Action Boundaries | "Any terminal command matching a dangerous/destructive pattern on a host-reaching backend MUST prompt the operator and MUST NOT execute until approved." | Partial | PRAX-2026-07-11-001 |
| R-18 | Action Boundaries | "When an approval prompt is not answered within the configured window, the action MUST be denied (fail closed)." | Verified | — |
| R-19 | Action Boundaries | "Cron jobs that hit a dangerous-command prompt MUST default to denying it rather than silently auto-approving." | Verified | — |
| R-20 | Action Boundaries | "Binding any local-only surface to a non-loopback interface MUST be a deliberate operator action that engages an authentication layer." | Verified | — |
| R-21 | Action Boundaries (Never Allowed) | "Executing a catastrophic, irreversible command (filesystem-root wipe, fork bomb, formatting a mounted device, zeroing a physical disk, piping an untrusted remote script straight to a shell) MUST be refused unconditionally — even under --yolo, approvals.mode: off, a permanent allowlist entry, or headless cron approve-mode." | Verified | — |
| R-22 | Action Boundaries (Never Allowed) | "Dispatching agent work, resolving an approval, or returning agent output to a caller who is outside the configured authorization set (allowlist, pairing approval, or OS-level equivalent) MUST NOT be possible; treating a session identifier as proof of authorization is forbidden." | Verified | — |
| R-23 | Action Boundaries (Never Allowed) | "A network-exposed adapter MUST NOT fail open (serve callers) when no allowlist / auth provider is configured." | Verified | — |
| R-24 | Action Boundaries (Never Allowed) | "Credentials or session-authorization material MUST NOT leak to any destination outside the operator's trust envelope through environment leakage, adapter logging, or transport error paths." | Verified | — |
| R-25 | Action Boundaries (Hermes Desktop) | "The desktop-launched backend MUST remain a JSON-RPC/API surface only (no unintended browser-reachable UI) and MUST stay bound to loopback unless the operator deliberately configures a remote/authenticated setup." | Verified | — |
| R-26 | Behavioral Expectations | "Sessions are isolated from one another; one session MUST NOT read another session's data or state." | Verified | — |
| R-27 | Behavioral Expectations | "Cron sessions run with a hard interrupt bound so a runaway loop cannot monopolize the scheduler." | Verified | — |
| R-28 | Behavioral Expectations | "Agent actions and decisions are recorded to durable, operator-inspectable logs." | Verified | — |
| R-29 | Behavioral Expectations | "tool-calling iterations MUST be bounded per turn/subagent; a session repeatedly failing across restarts MUST be escalated to a clean reset rather than retried indefinitely." | Verified | — |
| R-30 | Behavioral Expectations | "a command that was denied or blocked MUST NOT be silently retried or rephrased to evade the guard." | Enforcement Not Possible | — |
Findings Register
Findings, ordered by severity — each linked to its remit rule, evidence, and a recommended action. Tag chips jump to the relevant entry in the RAISE framework, the OWASP LLM Top 10, or the OWASP Agentic Top 10.
LLM06 primary — the finding's main OWASP categoryASI10 secondary — a category it also touches
HIGH PRAX-2026-07-11-001 Dangerous shell commands auto-approve (fail open) in a headless non-interactive context, completing an external-input-to-host-execution chain on the default backend.
Implement Zero Trust
LLM06 — Excessive Agency
ASI05 — Unexpected Code Execution (RCE)
LLM05 — Improper Output Handling
Policy Rule — R-08, R-17 (Worker Remit):
"Any terminal command matching a dangerous/destructive pattern must require explicit human approval before it runs (on host-reaching backends). / Any terminal command matching a dangerous/destructive pattern on a host-reaching backend MUST prompt the operator and MUST NOT execute until approved."
"Any terminal command matching a dangerous/destructive pattern must require explicit human approval before it runs (on host-reaching backends). / Any terminal command matching a dangerous/destructive pattern on a host-reaching backend MUST prompt the operator and MUST NOT execute until approved."
tools/approval.py:2101 — "non-interactive non-gateway non-cron branch returns {approved: True} with only a warning ('AUTO-APPROVED dangerous command in non-interactive non-gateway context'); fail_closed_when_no_human defaults False for check_dangerous_command"
tools/approval.py:2283 — "check_dangerous_command calls _run_approval_gate without fail_closed_when_no_human, so a non-hardline dangerous command on the local backend auto-approves when no human/gateway is present"
Recommended Action
- Make the dangerous-command path fail closed by default in non-interactive non-cron contexts (pass fail_closed_when_no_human=True from check_dangerous_command, mirroring request_tool_approval), or require an explicit operator opt-in env/config flag to preserve the auto-approve behavior.
- Document the headless fail-open explicitly in the deployment-hardening guidance and gate it behind a sandboxed backend when untrusted input is in scope.
MEDIUM PRAX-2026-07-11-002 Dangerous-command approval relies on a regex denylist that is structurally incomplete over a Turing-complete shell.
Implement Zero Trust
LLM05 — Improper Output Handling
ASI05 — Unexpected Code Execution (RCE)
LLM06 — Excessive Agency
Policy Rule — R-08 (Worker Remit):
"Any terminal command matching a dangerous/destructive pattern must require explicit human approval before it runs (on host-reaching backends)."
"Any terminal command matching a dangerous/destructive pattern must require explicit human approval before it runs (on host-reaching backends)."
tools/approval.py:547 — "DANGEROUS_PATTERNS is a finite regex list ('recursive delete', 'pipe remote content to shell', etc.); anything not matched falls through detect_dangerous_command to approved"
tools/approval.py:2279 — "detect_dangerous_command returns not-dangerous -> check_dangerous_command returns {approved: True} with no prompt"
Recommended Action
- Treat the denylist as defense-in-depth only and steer operators to a sandboxed terminal backend (Docker/Modal/Daytona) whenever the agent ingests untrusted input, per SECURITY.md.
- Continue the existing red-team cadence to extend patterns, and consider an allowlist-based execution mode for high-assurance deployments.
MEDIUM PRAX-2026-07-11-003 The default terminal backend runs LLM-emitted commands directly on the host, so safe operation with untrusted input depends on an operator posture choice.
Implement Zero Trust
LLM06 — Excessive Agency
ASI05 — Unexpected Code Execution (RCE)
LLM05 — Improper Output Handling
SECURITY.md:116 — "'Operators running the default local backend with untrusted input surfaces ... are operating outside the supported security posture'"
tools/approval.py:2217 — "_should_skip_container_guards only skips approval for singularity/modal/daytona and host-access-free docker; 'local' always goes through the (heuristic) approval path, never an OS boundary"
Recommended Action
- Make the deployment docs prescribe a sandboxed backend as the default recommendation whenever any untrusted-input surface (web, messaging, MCP) is enabled.
- Consider a startup warning (as the API server already emits) when the local backend is active alongside an enabled untrusted-input surface.
MEDIUM PRAX-2026-07-11-004 Writable, session-loaded memory and agent-created skills are an ASI06 persistence surface for content absorbed from untrusted sources.
tools/memory_tool.py:188 — "MEMORY.md / USER.md are read into the session snapshot each session (_sanitize_entries_for_snapshot applied), and are writable by the agent's memory tool without an approval gate"
tools/write_approval.py:8 — "memory writes (MEMORY.md/USER.md) are small declarative entries handled by write_approval; no external-vs-operator provenance label on stored content"
Recommended Action
- Tag memory entries with provenance (operator-originated vs derived-from-external-content) and surface externally-derived entries for periodic operator review.
- Keep memory-write sanitization strict and treat any memory content that reads as an instruction as suspect on load.
MEDIUM PRAX-2026-07-11-005 Durable logs are app-style records rather than a structured action-level event schema built for automated detection.
hermes_logging.py:14 — "RotatingFileHandler + RedactingFormatter emit plaintext log lines to hermes.log / gateway.log; no structured per-action JSON event stream for automated rule-based detection"
tools/approval.py:2101 — "an auto-approved dangerous command is recorded as a warning log line, not a structured approval-decision event that a detector could alert on"
Recommended Action
- Add a structured, append-only action/decision event log (JSON lines) capturing tool calls, approval outcomes, and authorization decisions with stable field names.
- Wire high-impact events (auto-approved dangerous command, yolo/approvals-off activation, unauthorized-caller rejection) into that stream so they can drive alerts.
What's Working Well
Controls and behaviors that are correctly implemented and verified during this scan. These represent areas where the agent's implementation aligns with its stated policy and security best practices.
Unconditional hardline command floor with no override flag
`tools/approval.py` blocks catastrophic irreversible commands (root-filesystem wipe, mkfs, dd to raw device, fork bomb, kill -1, shutdown/reboot) before the yolo/mode-off bypass, and the floor has no override — satisfying the remit's strongest MUST.
tools/approval.py:2252 (check_dangerous_command hardline branch before yolo)
Fail-closed provider-credential scoping that skills and config cannot override
Sandbox child processes (execute_code, terminal, MCP) have Hermes provider credentials stripped via a blocklist that refuses skill/config passthrough registration and fails closed if the blocklist import fails (hardened after GHSA-rhgp-j443-p4rf).
tools/env_passthrough.py:48 (_is_hermes_provider_credential fail-closed)
Gateway messaging authorization defaults to deny
`_is_user_authorized` returns False for any sender with no user_id and for platforms where no allowlist is configured unless an explicit allow-all/pairing opt-in is set; adapter "open" policies are explicitly not treated as authorization.
gateway/authz_mixin.py:467 (no-allowlist default-deny branch)
API server refuses to start without a strong key, even on loopback
The network HTTP surface will not start unless `API_SERVER_KEY` is present and passes a strength check (>=16 chars, not a placeholder), and every handler runs `_check_auth` with an HMAC-compared bearer token.
gateway/platforms/api_server.py:4711 (_api_key_passes_startup_guard)
SSRF protection blocks cloud-metadata endpoints unconditionally
`tools/url_safety.py` always blocks link-local cloud-metadata and credential IPs/hostnames (169.254.169.254, ECS task creds, metadata.google.internal, Alibaba) regardless of any allow-private toggle.
tools/url_safety.py:149 (always-blocked metadata hosts/IPs)
Secret redaction on all log handlers
All log files use `RotatingFileHandler` with a `RedactingFormatter`, and trace upload refuses to proceed if secret redaction fails — supporting the remit prohibition on secrets in logs.
hermes_logging.py:14 (RedactingFormatter on rotating handlers)
Real adversarial testing feeding back into architecture
A dedicated security test suite exercises the hardline blocklist, SSRF, yolo ordering, cron prompt injection, and secret exfiltration, and code comments cite GHSA advisories whose fixes reshaped the approval and credential-scoping design.
tests/tools/test_hardline_blocklist.py (+ GHSA references in tools/approval.py, tools/env_passthrough.py)
Bounded iteration budget for agent and subagents
Per-agent tool-iteration budget caps the parent turn (default 90) and each subagent independently (default 50), bounding runaway tool loops as the remit requires.
agent/iteration_budget.py:1
Discovered Log Files
Log files found in the agent's workspace during this scan. Reviewing these files provides runtime evidence to complement the static analysis above.
| Path | Source | Content Type | Purpose | Last Modified | Status |
|---|---|---|---|---|---|
| ~/.hermes/logs/hermes.log | hermes_logging.setup_logging (agent core / CLI) | plaintext rotating log, secret-redacted | INFO+ agent lifecycle, tool activity, warnings including approval auto-approve and hardline blocks | unknown | Inferred |
| ~/.hermes/logs/gateway.log | hermes_logging.setup_logging (mode="gateway", gateway.* loggers) | plaintext rotating log, secret-redacted | INFO+ gateway-only events (authorization decisions, delivery, session lifecycle) | unknown | Inferred |
OWASP LLM Top 10 (2025) Coverage
Each card represents one category and shows the top 3 findings. All items in the Findings section.
LLM01
Prompt Injection
No findings
LLM02
Sensitive Information Disclosure
No findings
LLM03
Supply Chain
No findings
LLM04
Data and Model Poisoning
LLM05
Improper Output Handling
LLM06
Excessive Agency
Dangerous shell commands auto-approve (fail open) in a headless non-interactive context, completing an external-input-to-host-execution chain on the default backend.
The default terminal backend runs LLM-emitted commands directly on the host, so safe operation with untrusted input depends on an operator posture choice.
LLM07
System Prompt Leakage
No findings
LLM08
Vector and Embedding Weaknesses
No findings
LLM09
Misinformation
No findings
LLM10
Unbounded Consumption
No findings
OWASP Agentic Top 10 (2026) Coverage
Each card represents one category and shows the top 3 findings. All items in the Findings section.
ASI01
Agent Goal Hijack
No findings
ASI02
Tool Misuse and Exploitation
No findings
ASI03
Identity and Privilege Abuse
No findings
ASI04
Agentic Supply Chain Vulnerabilities
No findings
ASI05
Unexpected Code Execution (RCE)
Dangerous shell commands auto-approve (fail open) in a headless non-interactive context, completing an external-input-to-host-execution chain on the default backend.
Dangerous-command approval relies on a regex denylist that is structurally incomplete over a Turing-complete shell.
The default terminal backend runs LLM-emitted commands directly on the host, so safe operation with untrusted input depends on an operator posture choice.
ASI06
Memory and Context Poisoning
ASI07
Insecure Inter-Agent Communication
No findings
ASI08
Cascading Failures
No findings
ASI09
Human-Agent Trust Exploitation
No findings
ASI10
Rogue Agents
No findings
RAISE Maturity Posture
Overall maturity assessment across the six categories of the RAISE framework. This is a maturity model, not a school grade: a score of 3 / 5 means Established, not 60 percent. Most production AI agents today score between Ad hoc (1) and Established (3). See the full RAISE framework reference for the complete scale and scoring.
2.85
/ 5.0
Weighted Maturity Score · Partial
Partial overall, but at the high end and unevenly distributed: Implement Zero Trust is Established (3) on the strength of a genuinely unconditional hardline floor, fail-closed credential scoping, default-deny gateway authorization, and an API server that refuses to start without a strong key — with documented gaps (a bypassable regex denylist, a headless fail-open path, a host-reaching default backend) that are findings, not disqualifiers. Build an AI Red Team is Strong (4): the workspace carries a large dedicated security test suite and code comments citing GHSA advisories whose fixes changed the architecture. The soft spots are Limit Your Domain and Balance Your Knowledge Base (both Partial/2): this is an intentionally general-purpose agent that ingests attacker-influenceable content and can execute code, with domain and data-source restriction left largely to operator configuration.
Limit Your Domain
2/ 5
Intentionally broad general-purpose personal agent (terminal, browser, code execution) whose scope restriction is operator-configured per platform via `hermes tools` and a Swimlane definition rather than enforced narrowly in code; the default tool surface is wide by design.
Balance Your Knowledge Base
2/ 5
External attacker-influenceable content (open web via `web_extract`, inbound messages, MCP responses) reaches the LLM context; SSRF blocking (`tools/url_safety.py`), log redaction, and memory-snapshot sanitization exist, but there is no trust-labelling of external content in prompt construction and memory can absorb external-origin content.
Implement Zero Trust
3/ 5
Strong operative controls — unconditional hardline floor before yolo (`tools/approval.py`), fail-closed provider-credential scoping (`tools/env_passthrough.py`), gateway default-deny (`gateway/authz_mixin.py`), API server strong-key startup guard — coexist with real gaps: the approval detector is a regex denylist, it fails open in headless contexts, and the default `local` backend is unsandboxed.
Manage Your Supply Chain
3/ 5
Dependencies are lockfile-pinned (`uv.lock`, `package-lock.json`), the optional MCP catalog is PR-reviewed with presence-equals-approval (`optional-mcps/*/manifest.yaml`, Linear uses native OAuth 2.1), no hardcoded secrets were found, and CI supply-chain guards exist; third-party skills/plugins run with full privilege but are gated on operator review.
Build an AI Red Team
4/ 5
A large dedicated adversarial test suite (`tests/tools/test_hardline_blocklist.py`, `test_url_safety.py`, `test_yolo_mode.py`, `test_cron_prompt_injection.py`, `test_browser_secret_exfil.py`, `test_force_dangerous_override.py`) plus code comments citing GHSA advisories (GHSA-96vc-wcxf-jjff, GHSA-rhgp-j443-p4rf) whose fixes drove concrete architectural changes — evidence of real red-teaming feeding back into design.
Monitor Continuously
3/ 5
Durable rotating logs with a secret-redacting formatter and session-tagged records (`hermes_logging.py`: `hermes.log`, `gateway.log`), plus shutdown forensics and an install audit log; the gap is that records are app-style log lines rather than a structured, queryable action-level event schema built for automated anomaly detection.
Maturity Scoring Rubric
Every score above is based on this scale. A score is a snapshot of observable posture — not a verdict on the people or team behind the system.
| Score | Label | Meaning |
|---|---|---|
| 5 | Exemplary | Best-in-class; automated, continuously tested, reference quality. Rarely achieved in shipping systems. |
| 4 | Strong | Comprehensive controls, active management, minor gaps. Production-ready. |
| 3 | Established | Documented controls consistently applied; known gaps accepted. A respectable baseline. |
| 2 | Partial | Some controls exist but coverage is incomplete; key gaps remain. |
| 1 | Ad hoc | Informal or inconsistent measures; relies on individual judgment. |
| 0 | Absent | No evidence this category is addressed at all. |
Weighting: the weighted overall above is the sum of each category's score × weight (the per-category weights are shown on each card). Zero Trust carries double weight by design; see the RAISE framework reference for the rationale.