Security & permissions

According to the FAQ, Hermes doesn't collect telemetry, usage data or analytics. API calls go only to the model provider you configure, and your conversations, memory and skills are stored locally in ~/.hermes/.

Keep in mind that whatever you send to a cloud model provider is subject to that provider's policies. If you enable an external memory provider, Hermes masks recognisable secrets before sending data to it.

Not by default. Commands are checked against dangerous patterns, and approvals.mode controls what happens: smart (default) uses a helper model to auto-approve low-risk commands, deny clearly dangerous ones and ask you about the rest; manual always asks; off disables checks.

A hardline blocklist, covering things like filesystem wipes and fork bombs, can't be overridden even in YOLO mode. Cron jobs deny dangerous commands by default.

YOLO mode skips dangerous-command approval prompts for the current session. Turn it on with hermes --yolo, the /yolo toggle, or HERMES_YOLO_MODE=1. The status bar shows a warning while it's active.

The hardline blocklist still applies. The docs recommend YOLO only for trusted commands in disposable environments.

Choose "always" when approving, and Hermes saves the pattern to command_allowlist in ~/.hermes/config.yaml, approving it silently from then on. Entries can be exact commands, shell-style globs like podman *, or rule keys shown in the prompt.

To block commands outright, add your own rules under approvals.deny.

Yes. Change terminal.backend in config.yaml. The default is local, but docker runs commands in a hardened container, ssh runs them on a remote server, and singularity, modal, daytona and vercel_sandbox offer other isolated or cloud environments.

For file edits there is also an optional write sandbox (HERMES_WRITE_SAFE_ROOT) and a list of protected paths that are always blocked.

Yes, with approvals.deny in config.yaml: a list of glob patterns, such as git push --force*, that block matching terminal commands unconditionally. They're checked before --yolo, /yolo or approvals.mode: off, match case-insensitively, see through simple quoting tricks and apply to every terminal backend. Changes take effect without restarting.

Always quote the patterns in YAML. The docs stress this is a command policy, not a sandbox, so use an isolated backend for real containment.

Partly. Context files such as AGENTS.md and .cursorrules are scanned before they enter the system prompt, looking for instructions to ignore earlier instructions, hidden HTML comments, attempts to read secrets, credential exfiltration via curl and invisible Unicode. A flagged project file is not loaded. The docs call these checks heuristics, not semantic intent detection.

Your own SOUL.md in your Hermes home only gets a warning, not a block. Separately, the command checker flags curl or wget uploads of secrets and hidden Unicode in commands.

Yes. At startup Hermes can pull keys from Bitwarden Secrets Manager, 1Password (op:// references through the op CLI) or any CLI vault via a command helper. Only the secret manager's bootstrap token stays in .env, and everything else can rotate centrally. Configure sources under secrets in config.yaml.

By default a value already in your .env or shell wins unless the source sets override_existing: true, which Bitwarden does by default.

Yes, if checkpoints are on. They're opt-in: start with hermes chat --checkpoints or set checkpoints.enabled: true. Hermes then snapshots your files into a shadow git store under ~/.hermes/checkpoints/ before file writes, patches and destructive commands such as rm or mv, without touching your project's own .git.

In a session, /rollback lists checkpoints and /rollback with a number restores one while keeping your hand-edits; add --all for a full restore, or use /rollback diff to preview. hermes checkpoints shows storage use.

Check where it comes from. Skills: built-in and official/... skills are fully trusted, a few well-known registries are "trusted", and everything else is community. Every hub install runs a security scan; a dangerous verdict is blocked even with --force. Preview first with hermes skills inspect <id>, and re-scan later with hermes skills audit.

Plugins: catalog entries are human-reviewed, pinned to an exact commit and scanned at admission, and tagged Official, Verified or Community. Raw git URLs are flagged as unreviewed. The docs are blunt that catalog listing isn't a code audit, and plugins (especially Desktop plugins) aren't sandboxed, so read the code and the disclosure for anything with broad access.

hermes security audit checks your environment, plugin requirements and pinned MCP servers against known vulnerabilities. If in doubt, try new things in a separate profile with a sandboxed terminal backend.

On the default local terminal backend, the agent can do what your user account can: run commands, read and write files. Profiles don't sandbox it. Guardrails are on by default: dangerous commands need approval, a hardline blocklist can't be overridden, writes to credential files such as ~/.ssh and .env are blocked, and secrets are redacted from output. Computer use (clicking and typing in apps) also goes through approvals.

To tighten it: set approvals.mode: manual to confirm every command, add approvals.deny rules, restrict file writes with HERMES_WRITE_SAFE_ROOT, and move command execution off your machine with terminal.backend: docker or ssh. In Desktop, Settings > Workspace can limit which folders it scans for repositories.

Tools run on whichever backend Desktop is connected to. Connect it to a remote gateway and the commands, files and computer use happen on that machine, not yours.

Give each person their own profile (hermes profile create <name>). A profile has its own memory, sessions, skills, keys and cron jobs, and each gets its own messaging bot, since a bot token can only belong to one profile.

If several people share one bot, lock it down with allowlists or DM pairing (hermes pairing approve <platform> <code>). Most platforms keep a separate session per user, but they share the profile's memory and tools, so don't share a bot that has access to your private accounts.

Profiles separate data, not machines: on the default local backend every profile can still reach your files. For real isolation between people, use a sandboxed terminal backend (Docker or SSH) or separate hosts.

Hermes itself sends no telemetry; your conversations, memory and skills stay on your machine, and requests go only to the provider you choose. Once you send a request through Nous Portal, the Nous Research privacy policy applies.

That policy (last updated September 28, 2026) says Nous collects prompts and outputs as workflow data and shares them with the third-party model providers that serve each model, under those providers' terms. It offers an opt-in Privacy Mode under which Nous says it won't store your inference payloads or use them for training, with exceptions for operational metadata and security or legal needs, and it applies only from when you turn it on. No retention period is stated for inference content.

Separately, Hermes warns before you pick discounted data-training model tiers (names ending in -contributor), where the vendor may train on your prompts.

Through its built-in vault (Passwords & Logins). The first time the agent hits a sign-in page with no saved login, it asks you in a masked prompt; the password is encrypted on your machine, bound to that site, and filled into the page without the model ever seeing it. 1Password and Bitwarden CLIs are picked up automatically if installed and signed in.

Cards and addresses work the same way (Settings > Passwords & Logins, or hermes vault add), and every card fill asks you first. Unattended runs such as cron and webhooks can't confirm, so they can't spend. Two-factor codes are generated from a saved authenticator key or typed by you into a prompt.

The vault protects against filling the wrong site, not against a compromised one: once a password is in a page, that site has it. On a hosted gateway, you can also take over the Bot Screen and type sensitive steps yourself.

A plan is guidance, not an enforced contract. /plan writes an implementation plan to .hermes/plans/ without executing anything, and the agent will usually follow it, but nothing technically stops a model from straying.

What is enforced are the controls around actions: dangerous commands need approval, approvals.mode: manual makes it ask for every command, approvals.deny blocks patterns outright, and checkpoints (hermes chat --checkpoints) let you /rollback file changes.

To keep it on track, ask it to check back with you before anything outside the plan; it has a clarify tool for questions. In Desktop's Git review pane, the Last turn view shows exactly what changed.

Treat any app as unofficial unless the official docs or the NousResearch GitHub link to it. The official distributions are the installer scripts and Hermes Desktop from hermes-agent.nousresearch.com, the Microsoft Store and MSIX packages, the nousresearch/hermes-agent Docker image, the Termux package and the NousResearch/hermes-agent repository.

Community projects can be useful; the plugin catalog even lists community mobile adapters. But they're built by their authors, not Nous, and a client that connects to your agent can see your conversations and possibly your tools.

Before connecting one, check who publishes it, read what access it needs, and prefer apps that connect through Hermes' own authenticated gateway rather than asking for your API keys.

Prefer official, scoped connections. The MCP catalog includes vendor-hosted servers (Atlassian for Jira and Confluence, plus Linear, Notion and others) that sign in with OAuth (hermes mcp install <name>), and each MCP server can expose only chosen tools with tools.include or tools.exclude. Use a service account or read-only token where the system offers one.

On a work machine, follow the docs' hardening guide: manual approvals, your own deny rules, a write sandbox, and running commands in Docker or over SSH. Keep secrets in a manager such as 1Password or Bitwarden rather than .env.

Systems without an MCP server or plugin can still be reached through scripts or APIs, but then access is whatever that credential allows, so keep it narrow and check your company's policy first.

With hosted connectors you can connect two or more accounts of one app, each with a short name such as home and work. There is no default: when several named accounts exist, the agent must say which one, and a call that leaves it out fails with the list of valid names. Results report the account they ran under.

Name, rename and remove accounts in Desktop's Connectors page, /connectors in the TUI, hermes connectors in a shell, or on Nous Portal. The agent may name a new account but never removes one.

Skills that use their own credentials, such as Google Workspace or Himalaya, use whatever account you set up for them.