Spring AI conversation memory: partition by verified tenant and caller

Build the key from trusted context

A browser-provided conversation ID is only a selector. Resolve it under the authenticated tenant and user before loading any messages. When the same opaque ID is presented by another user, return no history or deny the request. A memory advisor adds context; it is not a permission system. Retrieval filtering must also apply to documents attached to a conversation.

Bound the retained material

Set retention, maximum messages and deletion behavior. A summary can still contain personal or tenant data, so it needs the same ownership checks as raw messages. Do not mix tool outputs from different tenants in a shared key. The source kit does not have a ChatMemoryRepository or provider; this is an implementation contract awaiting integration tests.

Boundary sketch

record MemoryKey(String tenantId, String userId, String conversationId) {}
MemoryKey key = new MemoryKey(caller.tenantId(), caller.userId(),
    validatedConversationId);
List<StoredMessage> history = memoryRepository.findByOwner(key);

Cost and verification

Longer history increases storage, retrieval latency and model tokens. Summarization adds another model call and must still preserve deletion and ownership rules. This sketch is not executed by the current Spring source kit; verify it against the chosen dependencies and deployment.

Common Mistakes

• Do not use a conversation ID alone as the partition key.
• Do not assume summaries are free of sensitive data.
• Do not keep tool output after the source user's access is revoked without a policy.

Read next

Spring AI retrieval: apply the tenant filter before prompt assembly, Spring AI ChatClient request budgets: bound latency, tokens and work per caller, Spring AI tools: authorize each requested action after model selection, Spring method authorization: reject a cross-tenant read.