Security: HERMES_REDACT_SECRETS off-by-default exposes API keys in user-visible Telegram/Discord chat output

[frogwraps]

Summary

In a vanilla Hermes deployment, \ is OFF by default. As a result, when an end user converses with the agent through the gateway (Telegram, Discord), Hermes routinely echoes back live API key values as part of its visible chat responses (and writes them verbatim into ). For non-technical users this is invisible until something is breached.

Reproduction (real-world deployment)

Production Hermes Agent v0.11.0 on a Hostinger KVM2 VPS (Ubuntu 24.04), \ not set in .

Scanning conversation history for the exact values of credentials present in \ (read each \ from .env, grep -F for the value across session files):

• 24 distinct env-defined credentials were found leaked
• 345 files in \ and \ contained at least one credential value
• Top hit-counts for genuinely sensitive keys:
  • OPENROUTER_API_KEY: 412 occurrences
  • GHL_AUTH_TOKEN: 80
  • BRAVE_API_KEY: 68
  • DATAFORSEO_PASSWORD: 66
  • VAPI_AUTH_TOKEN: 50
  • AI_GATEWAY_API_KEY: 24
  • GITHUB_PAT_HERMES: 20
  • HOSTINGER_API_TOKEN: 19
  • N8N_API_KEY: 17
  • PAPERCLIP_API_KEY: 2

The session JSONs are debug dumps (related to #8518) but the same content is also visible in the user-facing chat — meaning end users read their own keys back to themselves over Telegram/Discord, and the keys persist in any cloud chat backups (Telegram cloud, Discord servers).

Impact

• User-visible leak vector: end users who never look at JSON dumps still see keys in their chat history.
• Cloud transit: Telegram/Discord servers now hold copies of these keys.
• No warning at gateway startup that redaction is off; user doesn't know to opt in until they audit.

Existing partial coverage

The redaction infrastructure is already excellent — \ has thoughtful patterns for OpenAI keys, GitHub PATs, Slack tokens, AWS keys, JWTs, Telegram bot tokens, DB connection strings, etc. \ already imports . The only thing missing is making it on by default.

Suggested fix (priority order)

1. Change default to ON. \ (default 'true' instead of '').
2. Loud opt-out warning. If user explicitly sets , gateway logs a prominent warning at startup ().
3. Startup audit. On gateway start, scan \ mtime <30 days for cred prefix patterns; if hits found and redaction is OFF, log a one-time warning recommending opt-out users review.
4. Documentation. README quickstart should explicitly call out the env var (currently it's only in code comments).

Related

• [Security] API key exposed in request debug dumps via incomplete masking #8518 — API key exposed in request debug dumps via incomplete masking
• Security: Redaction system fails to obscure passwords in lowercase/dotted config keys (e.g., spring.datasource.password) #16413 — Redaction system fails on lowercase/dotted config keys
• bug(redact): ENV/JSON regex patterns cause false positives on source code files #15934 — Regex false positives on source code files
• Feature: Secure Secrets Management Tool — API Key Ingestion, Scoped Access, Redaction, and Skill Requirements #410 — Feature: Secure secrets management

Workaround (for users hitting this now)

Filed via gh CLI from a real affected user's VPS after a 24-cred / 345-file remediation.

[liuhao1024]

This is addressed by two existing PRs:

• fix(agent): redact credentials in session capture logs #19855 — redacts credentials in session capture logs (type/security, P1)
• fix(security): enable secret redaction by default #18596 — enables secret redaction by default (changes the default from off to on)

Both target the same root cause: HERMES_REDACT_SECRETS defaulting to off. #18596 is the more direct fix for the "off-by-default" aspect described here.

[alt-glitch]

Likely duplicate of #17691 — same root cause: HERMES_REDACT_SECRETS off-by-default exposing API keys in gateway chat output. Fix PR already open at #18596.

[alt-glitch]

Likely duplicate of #17691

[teknium1]

Duplicate of #17691 — same title, same summary, same author. Consolidating discussion on the earlier issue. Thanks!