fix(security): scope memory tools to session userId — M2-003/004 #294

2026-03-21T20:19:01Z

jason.woltje commented

2026-03-21 20:19:01 +00:00

Summary

M2-003: Audited packages/memory/src/preferences.ts — all five exported functions (findByUser, findByUserAndKey, findByUserAndCategory, upsert, remove) already correctly filter by userId at the DB WHERE clause level. No gaps found.
M2-004: Fixed agent memory tools — removed userId from all four tool parameter schemas (memory_search, memory_save_preference, memory_save_insight, memory_get_preferences) so the LLM cannot inject an arbitrary user ID. The userId is now bound from the authenticated session at tool-creation time via the new sessionUserId parameter on createMemoryTools().
Updated buildToolsForSandbox() and the doCreateSession() call site in agent.service.ts to thread the session userId through.

Security Impact

Before this fix, all four memory tools accepted userId as an LLM-controlled parameter, meaning the model could access or write to any user's memory data. The fix closes this injection vector — memory operations are now scoped to the session owner, not to whatever userId the model provides.

Test plan

Typecheck: pnpm typecheck — passes
Lint: pnpm lint — passes
Format: pnpm format:check — passes

## Summary - **M2-003**: Audited packages/memory/src/preferences.ts — all five exported functions (findByUser, findByUserAndKey, findByUserAndCategory, upsert, remove) already correctly filter by userId at the DB WHERE clause level. No gaps found. - **M2-004**: Fixed agent memory tools — removed userId from all four tool parameter schemas (memory_search, memory_save_preference, memory_save_insight, memory_get_preferences) so the LLM cannot inject an arbitrary user ID. The userId is now bound from the authenticated session at tool-creation time via the new sessionUserId parameter on createMemoryTools(). - Updated buildToolsForSandbox() and the doCreateSession() call site in agent.service.ts to thread the session userId through. ## Security Impact Before this fix, all four memory tools accepted userId as an LLM-controlled parameter, meaning the model could access or write to any user's memory data. The fix closes this injection vector — memory operations are now scoped to the session owner, not to whatever userId the model provides. ## Test plan - Typecheck: pnpm typecheck — passes - Lint: pnpm lint — passes - Format: pnpm format:check — passes

jason.woltje added 1 commit 2026-03-21 20:19:02 +00:00

fix(security): scope memory tools to session userId — prevent LLM parameter injection

ci/woodpecker/push/ci Pipeline was successful

Details

ci/woodpecker/pr/ci Pipeline was successful

Details

0044481b4c

M2-003: Audited PreferencesRepo — all five functions (findByUser, findByUserAndKey,
findByUserAndCategory, upsert, remove) already enforce userId filtering at the DB
WHERE clause level. No gaps found.

M2-004: Fixed agent memory tools (memory_search, memory_save_preference,
memory_save_insight, memory_get_preferences) — removed userId from all tool
parameter schemas so the LLM cannot inject an arbitrary user ID. The userId is
now bound from the authenticated session at tool-creation time via the new
sessionUserId parameter on createMemoryTools(). buildToolsForSandbox() and the
doCreateSession() call site are updated to thread the session userId through.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

jason.woltje merged commit bb22857fde into main

2026-03-21 20:19:21 +00:00

jason.woltje referenced this issue from a commit

2026-03-21 20:19:22 +00:00

fix(security): scope memory tools to session userId — M2-003/004 (#294)

jason.woltje referenced this issue from a commit

2026-03-21 20:21:53 +00:00

chore(orchestrator): mark M1-001/002/003 and M2-003/004 done

jason.woltje referenced this pull request

2026-03-21 20:21:59 +00:00

chore: mark M1-001/002/003 and M2-003/004 done #295

jason.woltje referenced this issue from a commit