openclaw - 💡(How to fix) Fix [P0 Security] relevant-memories: Cross-user privacy leakage via semantic recall without sender_id isolation

Bug Description

The relevant-memories recall mechanism retrieves memories based on semantic relevance without filtering by sender_id scope. This causes private memories from one user to be injected into another user's conversation context.

Steps to Reproduce

1. User A (sender_id: ou_A) has private memories stored in their session/memory files
2. User B (sender_id: ou_B) starts a conversation with the bot
3. User B's conversation context receives User A's private memories due to high semantic similarity
4. User B can read User A's confidential data, business information, or private self-reflections

Expected Behavior

Memory recall should be scoped to the current user's sender_id. Cross-user memory injection must not occur.

Actual Behavior

The relevant-memories recall mechanism operates at a global semantic level, ignoring the sender_id of the requesting user. Memories from any user with high semantic relevance to the query are injected regardless of user identity.

Impact

• Severity: P0 Security — Privacy violation
• Affected: All multi-user deployments
• Data at risk: Private business data, personal reflections, confidential project information, authentication credentials stored in memory files

Environment

• OpenClaw version: 2026.5.7
• Channel: Feishu (multi-user)
• OS: Linux

Additional Context

The issue was reproduced in a production environment where one user's private memories (including business data from a TPE factory, project management methodology, and personal self-reflections) were injected into another user's conversation session.

Root cause: The recall mechanism in OpenClaw core does not enforce sender_id-based scope isolation at the memory retrieval layer.

Suggested Fix

Implement sender_id scope filtering in the relevant-memories recall mechanism:

1. Add sender_id parameter to the recall function
2. Filter memory files/documents by sender_id before semantic similarity scoring
3. Reject any cross-user memory injection at the retrieval layer

Alternative workaround at the Python/automation layer:

• Implement a privacy isolation guard that validates sender_id before every Feishu message send
• Clear session-corpus entries from the recall index that were indexed before the bug was known
• Add sender_id white-list validation for all outbound messages