Should secrets go into Hermes Agent memory?
No. Secrets, API keys, tokens, and private credentials should stay in deliberate secret storage, not agent memory.
Persistent context
Hermes Agent memory
Hermes Agent memory is useful because it can carry context across sessions, but it should be managed like an operational data store. Old context can go stale, private details can become too reachable, and not every note belongs in agent memory.
Agent Guide is an independent editorial resource. It is not affiliated with, endorsed by, or sponsored by Nous Research, Hermes Agent, or Hermes/Hermes brand owners. Product names and marks belong to their respective owners.
Intent
hermes-agent-memory
Sources
6
Schema
2
Links
4
Direct answer
Use Hermes Agent memory for stable preferences, workflow rules, recurring context, and project facts that should survive a single session. Do not use memory as a dumping ground for secrets, unreviewed customer data, or fast-changing facts that need verification.
The safest pattern is memory hygiene: decide what belongs in long-term memory, what belongs in a project note, what should expire, and what should never be stored.
Best for
- Recurring workflows with stable preferences or review rules.
- Project context that should not be re-explained every session.
- Operators comparing built-in memory with external memory providers.
- Obsidian or Markdown workflows where durable notes can complement agent memory.
Avoid if
- You cannot audit or delete sensitive context later.
- The workflow handles regulated, legal, medical, or customer-confidential data without policy review.
- Facts change frequently and should be rechecked from source each run.
- You expect memory to replace source-of-truth documentation.
What this page covers
- Hermes memory intent, persistent context, memory providers, stale context risk, privacy, and Obsidian relationship.
- How to decide between memory, project notes, and external docs.
What this page does not cover
- A benchmark of every memory provider.
- A guarantee that memory is private, encrypted, or compliant in every deployment.
- A separate Obsidian workflow, which has its own canonical page.
Quick steps
- Write a memory policy before adding sensitive workflows.
- Separate stable preferences from time-sensitive facts.
- Keep secrets, credentials, and customer-sensitive records out of memory.
- Review memory before connecting messaging, cron, or shared team workflows.
- Use Obsidian or project notes when humans need a readable source of truth.
Known breakpoints
| Breakpoint | Why it happens | Safer response |
|---|---|---|
| Agent repeats stale facts | Old memory outlived the source truth | Move time-sensitive facts into checked sources or project notes. |
| Sensitive data persists | Secrets or private details were stored in memory | Remove memory entries and rotate secrets if exposed. |
| Conflicting context | Multiple profiles or projects share assumptions | Use profiles and explicit project boundaries. |
| Memory bloat | Everything is stored instead of curated | Create keep/delete rules and review periodically. |
Security notes
- Memory should be treated as sensitive persistent state.
- Do not store provider keys, private prompts, tokens, or credentials in memory.
- Use separate profiles for personal, work, client, and public workflows.
- Review what memory can influence before scheduling unattended workflows.
Changelog
- 2026-06-02: Added as canonical memory and persistent-context page.
Agent Guide judgment
Memory is where agent convenience becomes long-term operational risk. Persistent context can help Hermes improve repeated work, but stale instructions, private notes, and old mistakes can also keep influencing future sessions.
Use memory only after you have a review habit. Treat memory entries like project documentation: dated, scoped, removable, and not a place for secrets.
Memory hygiene smoke test
| Check | Healthy result | Risk signal |
|---|---|---|
| Scope | Memory is tied to a project, profile, or workflow. | One broad memory bucket mixes personal, client, and production context. |
| Review | Old context can be inspected and removed. | The operator cannot explain why Hermes behaves a certain way. |
| Secrets | Memory contains no API keys, tokens, or private credentials. | Secrets appear in notes, summaries, or generated files. |
| Staleness | Important entries include dates or source context. | Old assumptions are reused without verification. |
Memory provider decision
Official docs describe multiple external memory providers and say only one external provider is active at a time alongside built-in memory. The operator decision is therefore not 'turn on memory' but 'which memory belongs to which profile, workflow, and privacy boundary.'
| Decision | Safer default | Avoid |
|---|---|---|
| Provider choice | Use the simplest provider that supports the workflow. | Switching providers before reviewing what context is retained. |
| Profile scope | Separate personal, team, and client contexts. | One memory layer for every identity. |
| Disable path | Know memory status and disable/off workflow before experiments. | Persistent memory nobody can inspect or turn off. |
| Content | Store stable preferences and project facts. | API keys, private credentials, or unreviewed meeting notes. |
Obsidian versus memory
Community Obsidian discussions surface a useful distinction: Obsidian is not a magic memory upgrade. It is valuable when a human wants reviewable Markdown notes, project logs, source ledgers, and curated context outside the transient chat.
Use built-in or external memory for stable preferences and workflow context. Use Obsidian-style notes for material a person should read, edit, archive, or cite.
| Need | Use memory when | Use Obsidian/Markdown when |
|---|---|---|
| Repeated preference | Hermes should remember a stable operating rule. | The rule needs a reviewed note with owner/date/source. |
| Research output | A short preference or fact is enough. | The output needs citations, sections, and future editing. |
| Project history | The agent needs lightweight continuity. | Humans need an auditable project log. |
| Private data | Only if scoped and removable. | Only in a bounded folder, never as a secret store. |
Official sources reviewed
| Source | Used for | Last checked | Confidence |
|---|---|---|---|
| Hermes Agent documentation | Hermes Agent feature scope, documentation structure, and official source navigation. | 2026-06-05 | high |
| Hermes Agent memory providers docs | Memory-provider options, persistent-memory framing, and privacy caveats. | 2026-06-05 | high |
| Hermes Agent profiles docs | Profile isolation, multi-profile operation, and future team-routing context. | 2026-06-05 | high |
| Hermes Agent security guide | Approval modes, gateway authorization, Docker terminal backend hardening, and credential cautions. | 2026-06-05 | high |
| Reddit Hermes Agent Obsidian workflow discussion | Community friction signal around Obsidian versus built-in memory and note-curation value; not used as product truth. | 2026-06-05 | low |
| Reddit r/hermesagent community start thread | Community demand signals for Docker vs local vs VPS, memory/context, OpenRouter, and install anxiety; not used as product truth. | 2026-06-05 | low |
Known caveats: Memory-provider behavior can change. Verify official memory docs before choosing a production provider.
FAQ
Is Obsidian the same as Hermes memory?
No. Obsidian can be a human-readable knowledge base or workflow artifact store; Hermes memory is persistent agent context.
Operator checklist
Get the Agent Guide launch checklist
Receive the smoke-test order for install path, sandbox boundary, provider setup, source review, and production checks.