Problem

Hermes Agent's memory system is currently global — all memory entries are unconditionally injected into every session, regardless of the session's chat source, platform, or profile. This works well for single-user setups but creates a significant privacy vulnerability in multi-chat environments.

Scenario:

• A user runs Hermes on multiple Telegram chats — a private DM and a public group
• Sensitive information discussed in the DM (API keys, server credentials, project details) gets saved to memory
• Those memory entries are then injected into the public group session, where anyone can prompt the agent to reveal them

There is no system-level mechanism to scope memory to specific chats, platforms, or profiles.

Current Workarounds (Fragile)

Users resort to manual workarounds:

1. Hard-coding chat ID checks in skill files (SKILL.md)
2. Moving sensitive data out of memory entirely into skills (losing memory's convenience)
3. Using memory only as a pointer: "credentials are in X skill"

These are brittle, require constant discipline, and offer no enforcement.

Proposed Solution

Add an optional scope parameter to the memory tool:

{
  "action": "add",
  "target": "memory",
  "content": "Production DB host: 10.0.1.50",
  "scope": "telegram:123456789"
}

Behavior:

• scope is set → entry is ONLY injected into sessions matching that scope
• scope is unset → entry is injected everywhere (backward compatible — no breaking change)

Supported scope formats:

Injection filtering: When building the system prompt, filter memory entries:

• Entry has scope → check if session source matches → inject or skip
• Entry has no scope → inject always (backward compatible)

Alternatives Considered

1. Per-platform memory stores — Separate databases per platform. Coarse-grained (can't split DM vs group on same platform).
2. Config-based filter rules — Filter memory by tags via config.yaml. More complex to configure.
3. Do nothing — Acceptable for single-user setups, leaves a foot-gun for multi-chat deployments.

Scope / Impact

• Memory tool schema: Add optional scope parameter (string)
• Memory injection: Filter entries by scope during prompt building
• Backward compatibility: No breaking changes — unscoped entries behave exactly as today
• Storage: Add scope column to memory store (nullable)

Priority

Medium-High — privacy issue with real-world impact for users running Hermes across multiple chats or profiles.

Related

• Current memory tool signature: action (add/replace/remove), target (user/memory), content, old_text
• Memory injected into system prompt at session start
• Session context already carries source information (platform + chat ID)