Hermes Control Interface
A self-hosted, password-gated web dashboard and operations control plane for the Hermes AI agent stack.
Per-dimension scores and reasoning
README claims security features like CSP, CSRF, rate limiting, RBAC, and path traversal prevention, but provides no implementation code or configuration evidence. The permission model (20 permissions/3 roles) is described only in text, making it impossible to verify least privilege enforcement. Sensitive data handling mentions bcrypt and random strings but lacks details on key management or log redaction. Dependency security lists packages without audit reports or version pinning strategies. External effects (MCP control, file editing, terminal) lack confirmation mechanisms or rollback descriptions. Source attribution points only to a GitHub repository with unverified publisher identity. Overall evidence is thin, warranting a score of 1.
Version inconsistency between README (3.6.1) and package.json (3.6.2) indicates a self-consistency issue. Dependency availability lacks lockfile or resolution strategy, and the postinstall script rebuilding better-sqlite3 may fail across environments. Failure message handling is undocumented, and tests only cover frontend utilities and modals, not error paths. Thus reliability evidence is insufficient, scoring 1.
README describes multiple use scenarios for the Hermes agent stack (chat, file management, MCP control, etc.) but does not clearly define boundaries or limitations. Trigger precision is undefined, with no agent trigger conditions or input validation rules. Environment fit mentions only Node.js 20+ and Hermes CLI, lacking OS, resource, or network configuration details. Adaptability evidence is limited, scoring 1.
Information architecture is partially reflected via README tables and doc links, but the docs themselves are not provided in this review, preventing completeness verification. Install notes offer quick start steps, but production deployment details rely on external docs. Naming stability is questionable due to version inconsistency. Examples and FAQ are present in README but lack depth. Known limitations are not explicitly listed. License is MIT and complete, scoring 2. Versioning changelog is absent, and maintenance responsibility is unclear (publisher unverified). Overall convention score is low.
Output usability shows rich UI features and screenshots in README, but no actual output examples or user feedback. Marginal value lies in providing a unified management interface for Hermes agents, but lacks comparison with alternatives or quantified benefits. Cost-benefit is not discussed regarding resource consumption or deployment costs. Effectiveness evidence is insufficient, scoring 1.
Claims in README (e.g., security features, performance gains) lack traceable code references or test evidence. Cross-source corroboration is limited to a few test files covering narrow functionality, unable to corroborate major claims. Fact-inference separation is blurred by marketing language mixed with factual descriptions. Verifiability score is low, at 1.
- Publisher identity is unverified, making maintenance responsibility and update paths unclear.
- Version inconsistency between README and package.json may affect dependency management and deployment.
- Security features are only documented claims without implementation code or configuration evidence, leaving actual protection unknown.
- Dependencies lack lockfile or audit reports, posing supply chain risks.
- Test coverage is limited to frontend utilities, not validating core backend functionality.
What does this agent do, and when should you use it?
Hermes Control Interface (HCI) is a self-hosted web dashboard for the Hermes AI agent stack, at version 3.6.1 under the MIT license. The backend is a monolithic Express service (server.js, roughly 6K+ lines); the frontend is an 11-page Vanilla JS + Vite SPA that uses WebSocket and xterm.js for a browser terminal and live chat streaming, Chart.js for analytics charts, and better-sqlite3 to read kanban.db. It consolidates agent profiles, gateway lifecycle, file browsing and editing, cron jobs, MCP server control, token analytics, and the Office v3 three-panel swarm monitor behind a single password gate, with CSP, CSRF, rate limiting, WebSocket RBAC, and 20 permissions across three roles (admin, viewer, custom). The deployment boundary is explicit: HCI must run on the same machine as the Hermes Agent and depends on the hermes CLI being on PATH, listening on port 10274 by default. It complements rather than replaces Hermes, acting as a local operations and observability layer.
HCI reads the ~/.hermes state directory (overridable via HERMES_CONTROL_HOME) for config.yaml, logs, and skills, parses kanban.db for the task pipeline, and exposes 30+ REST routes to the browser: GET /api/office/kanban returns board tasks and dependency links, GET /api/office/kanban/:id returns task detail with runs, events, and comments, GET /api/office/kanban/:id/workspace-file reads workspace code and logs, POST /api/office/kanban/:id/action performs quick actions (done, start, reopen), and GET /api/office/agent-states emits the agent health grid. It calls the hermes CLI for agent states, gateway control, profile and skill management, and streams chat through the WebSocket gateway API with tool-call cards (collapsible JSON viewer, stop button, session resume, fork from message). The MCP page is a full control plane — list, start, stop, restart, log tail, config editor — backed by 11 REST routes. Monitor shows gateway logs plus CPU/RAM metrics, Usage covers token trends, cost projections, and budget alerts, and Maintenance handles backup, restore, HCI update, and system doctor.
- A solo developer running several Hermes profiles on one VPS who wants to switch profiles, chat, review sessions, and manage cron from a single browser tab instead of repeated SSH logins.
- A small multi-agent team (community ops, content) that needs allowed_profiles restrictions such as createUser('cx-team','password','custom',['jorah']) so each member only sees and manages their authorized agents.
- An operator who needs to start, stop, and troubleshoot MCP servers, tailing live logs and editing config files from the MCP page without shell access to the host.
- A project lead watching spend who uses the Usage page's daily trends, cost projections, and budget alerts to gauge agent running costs.
- A swarm-pipeline team tracking triage-to-done progress and dependencies across the Office v3 three panels: agent health, the 8-lane kanban board, and the live event feed.
- A mobile-first user who installs the dashboard as a PWA with offline caching to check system health from a homescreen icon.
What are this agent's strengths and limitations?
- Consolidates a browser terminal (xterm.js), file browsing/editing, chat, cron, MCP control, logs, and token analytics into one password-gated 11-page SPA.
- Office v3 uses zero-subprocess agent state retrieval (~100ms versus ~3000ms) by reading config.yaml and kanban.db directly.
- Broad security surface: CSP without unsafe-eval, CSRF on all mutating endpoints, global and chat rate limiting, WebSocket RBAC, plus path-traversal and XSS protection.
- Profile-level access isolation via allowed_profiles and requireProfileAccess middleware lets multi-agent teams grant per-user agent visibility.
- Installable as a PWA with service worker offline caching and auto-update on new versions.
- Tightly bound to Hermes Agent: it must run on the same machine with the hermes CLI on PATH, so no standalone or cross-host deployment is possible.
- server.js is a monolithic file of roughly 6K+ lines, raising the cost of auditing or extending it.
- Credentials are configured as plaintext environment variables in .env; the README documents no key rotation or external secret management.
- No Docker image or containerized deployment path is provided, so productionizing means setting up nginx and systemd yourself.
- No public evidence is given for concurrency limits, tenant isolation beyond permissions, or audit logging, so enterprise compliance needs independent evaluation.
How do you install or deploy this agent?
Prerequisites: Node.js 20+, the Hermes Agent installed on the same machine, and the hermes CLI available on PATH.
git clone https://github.com/xaspx/hermes-control-interface.git
cd hermes-control-interface
cp .env.example .env # set HERMES_CONTROL_PASSWORD and HERMES_CONTROL_SECRET
npm install && npm run build
node server.js # → http://localhost:10274Environment variables: HERMES_CONTROL_PASSWORD (login password, bcrypt-hashed), HERMES_CONTROL_SECRET (session secret, random string), PORT (default 10274), HERMES_CONTROL_HOME (default ~/.hermes), HERMES_PROJECTS_ROOT (default parent of the repo). Production nginx, systemd, and Cloudflare setup lives in docs/INSTALL.md.
How do you use this agent?
After node server.js starts, open http://localhost:10274 and log in with HERMES_CONTROL_PASSWORD. Use the left navigation: Chat for WebSocket-streamed conversations with a profile switcher and tool-call cards; Workspace to browse and edit files with Hermes scoped to a project directory; Agents for profile CRUD and gateway lifecycle; Office for agent health, kanban, and live feed; Monitor for gateway logs and CPU/RAM; Usage for token trends and budget alerts; MCP to start, stop, restart servers and tail logs; Maintenance for backup, restore, and self-update. To update from the command line: git pull upstream main && npm install && npm run build, then systemctl restart <your HCI service name>.