feat(memory): bind operator plugin to agent sessions #739

Merged
jason.woltje merged 2 commits from fix/tess-m4-operator-memory-consumer into main 2026-07-13 13:44:21 +00:00
Owner

Summary

  • instantiate the configured operator-memory plugin at gateway bootstrap
  • bind retrieval and capture tools to server-derived tenant, owner, and session scope
  • retain legacy memory behavior when the operator plugin is not configured
  • redact captured operator-memory content before persistence

Verification

  • TURBO_FORCE=true pnpm typecheck
  • TURBO_FORCE=true pnpm lint
  • TURBO_FORCE=true pnpm format:check
  • TURBO_FORCE=true pnpm test
  • Codex code review and security review

Part of TESS-M4-W / #710.

## Summary - instantiate the configured operator-memory plugin at gateway bootstrap - bind retrieval and capture tools to server-derived tenant, owner, and session scope - retain legacy memory behavior when the operator plugin is not configured - redact captured operator-memory content before persistence ## Verification - `TURBO_FORCE=true pnpm typecheck` - `TURBO_FORCE=true pnpm lint` - `TURBO_FORCE=true pnpm format:check` - `TURBO_FORCE=true pnpm test` - Codex code review and security review Part of TESS-M4-W / #710.
jason.woltje added 1 commit 2026-07-13 13:23:11 +00:00
feat(memory): bind operator plugin to agent sessions
All checks were successful
ci/woodpecker/pr/ci Pipeline was successful
31a5973808
Author
Owner

REQUEST CHANGES reviewer-of-record [W-jarvis:reviewer] head 31a5973808

Verified at exact head 31a59738089f0784428833fc5a0192c6c7c43261; CI reports green for PR pipeline 1764, and apps/gateway/src/commands/command-authorization.service.ts is byte-identical to origin/main (hash a9f829e7ecec721c6c585fe0da56fb5d6a6441e9). The Optional import is present in agent.service.ts, so that is not a defect.

Blockers:

  • The required server-derived scope proof is not covered by the new tests. memory-tools.test.ts calls createMemoryTools(...) directly with a pre-built { plugin, scope }, so it bypasses the production AgentService.createSession -> buildToolsForSandbox -> createMemoryTools path where { tenantId, ownerId, sessionId } is supposed to be derived. This would still pass if the production call site stopped deriving the right scope.
  • The consumer tests do not assert cross-tenant / cross-owner isolation or denial. There is no divergent authenticated owner/tenant case proving a foreign actor cannot reuse a session and reach another tenant/owner's operator-memory scope before the plugin is called. Existing package-level plugin tests prove scoped key construction, but not that the gateway/AgentService consumer binds and enforces the server-derived scope.

Positive findings: the production code does wire OPERATOR_MEMORY_PLUGIN into AgentService and routes memory_search / memory_save_insight through the plugin when configured; adapter/namespace come from MOSAIC_OPERATOR_MEMORY_INSTANCE_ID and MOSAIC_OPERATOR_MEMORY_NAMESPACE; no live creds or hardcoded Tess identity were found.

Marker: ROR-739-REQUEST-CHANGES-31a59738

REQUEST CHANGES reviewer-of-record [W-jarvis:reviewer] head 31a59738089f0784428833fc5a0192c6c7c43261 Verified at exact head `31a59738089f0784428833fc5a0192c6c7c43261`; CI reports green for PR pipeline `1764`, and `apps/gateway/src/commands/command-authorization.service.ts` is byte-identical to `origin/main` (hash `a9f829e7ecec721c6c585fe0da56fb5d6a6441e9`). The `Optional` import is present in `agent.service.ts`, so that is not a defect. Blockers: - The required server-derived scope proof is not covered by the new tests. `memory-tools.test.ts` calls `createMemoryTools(...)` directly with a pre-built `{ plugin, scope }`, so it bypasses the production `AgentService.createSession -> buildToolsForSandbox -> createMemoryTools` path where `{ tenantId, ownerId, sessionId }` is supposed to be derived. This would still pass if the production call site stopped deriving the right scope. - The consumer tests do not assert cross-tenant / cross-owner isolation or denial. There is no divergent authenticated owner/tenant case proving a foreign actor cannot reuse a session and reach another tenant/owner's operator-memory scope before the plugin is called. Existing package-level plugin tests prove scoped key construction, but not that the gateway/AgentService consumer binds and enforces the server-derived scope. Positive findings: the production code does wire `OPERATOR_MEMORY_PLUGIN` into `AgentService` and routes `memory_search` / `memory_save_insight` through the plugin when configured; adapter/namespace come from `MOSAIC_OPERATOR_MEMORY_INSTANCE_ID` and `MOSAIC_OPERATOR_MEMORY_NAMESPACE`; no live creds or hardcoded Tess identity were found. Marker: ROR-739-REQUEST-CHANGES-31a59738
jason.woltje added 1 commit 2026-07-13 13:35:43 +00:00
test(memory): cover server-derived operator scope
All checks were successful
ci/woodpecker/pr/ci Pipeline was successful
c26b3b7752
Author
Owner

VERIFIED APPROVE reviewer-of-record [W-jarvis:reviewer] head c26b3b7752

Findings: CI pipeline 1765 is green at the exact head, and apps/gateway/src/commands/command-authorization.service.ts remains byte-identical to origin/main (hash a9f829e7ecec721c6c585fe0da56fb5d6a6441e9). The Optional import is present; no live creds or hardcoded Tess identity were found.

The prior blockers are closed: agent-service-ownership.test.ts now exercises the production createSession -> buildToolsForSandbox path and asserts the derived { tenantId, ownerId, sessionId } scope, while the foreign-scope reuse test rejects before tool construction and before any plugin search/capture call. Production wiring is reachable: MemoryModule configures createOperatorMemoryPlugin only from MOSAIC_OPERATOR_MEMORY_INSTANCE_ID / MOSAIC_OPERATOR_MEMORY_NAMESPACE, AgentService injects it, derives scope from session owner/tenant/session id, and memory_search / memory_save_insight route through the plugin when configured.

Marker: ROR-739-APPROVE-c26b3b77

VERIFIED APPROVE reviewer-of-record [W-jarvis:reviewer] head c26b3b775279575276c6ebe8955a9146bfc61413 Findings: CI pipeline `1765` is green at the exact head, and `apps/gateway/src/commands/command-authorization.service.ts` remains byte-identical to `origin/main` (hash `a9f829e7ecec721c6c585fe0da56fb5d6a6441e9`). The `Optional` import is present; no live creds or hardcoded Tess identity were found. The prior blockers are closed: `agent-service-ownership.test.ts` now exercises the production `createSession -> buildToolsForSandbox` path and asserts the derived `{ tenantId, ownerId, sessionId }` scope, while the foreign-scope reuse test rejects before tool construction and before any plugin `search`/`capture` call. Production wiring is reachable: `MemoryModule` configures `createOperatorMemoryPlugin` only from `MOSAIC_OPERATOR_MEMORY_INSTANCE_ID` / `MOSAIC_OPERATOR_MEMORY_NAMESPACE`, `AgentService` injects it, derives scope from session owner/tenant/session id, and `memory_search` / `memory_save_insight` route through the plugin when configured. Marker: ROR-739-APPROVE-c26b3b77
jason.woltje merged commit 3378b857eb into main 2026-07-13 13:44:21 +00:00
jason.woltje deleted branch fix/tess-m4-operator-memory-consumer 2026-07-13 13:44:21 +00:00
Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#739