Protection of Sensitive Files

6.4. Protection of Sensitive Files — Protecting Sensitive Files and Secrets

Checks before overwriting

Before write_file or patch touches the disk, Hermes checks the destination path against a denylist and an optional sandbox. A blocked write returns an error immediately to the agent — there is no approval prompt and no way to override from the chat interface.

Environment variable filtering for MCP servers

By default, an MCP server receives only the environment variables explicitly declared in its own configuration; every other variable (API keys, tokens, passwords) is filtered out completely:

mcp_servers:
  github:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "ghp_..."   # only this variable is passed through

Redacting secrets in output

hermes config set security.redact_secrets true

When enabled, API keys/tokens are masked before they enter the conversation context. This setting is snapshotted at startup (a restart is required for it to take effect) — deliberately, so that a compromised model mid-session cannot turn this feature off on its own.

Notes

When connecting an Obsidian Vault, remember that OBSIDIAN_VAULT_PATH identifies the Vault but does not create a filesystem sandbox. See Obsidian for the Docker mount and permission boundary.

• Keep secrets in the right place: secrets always live in ~/.hermes/.env with 0600 permissions, never in wide pass-through lists (env_passthrough, docker_forward_env).
• Turn on redact_secrets early if the agent frequently interacts with output containing tokens (CI/CD logs, API responses) — this feature is off by default.
• For secrets that need frequent rotation, consider pulling them directly from an external secret manager (Hermes supports Bitwarden Secrets Manager) instead of storing them statically in .env.