Memory Containers Are a Scope Boundary, Not a Login System

A memory container groups records for retrieval. It does not establish that a caller is allowed to read those records. The application must resolve identity and authorize the requested scope before calling the memory service.
This distinction matters when user, project, and workspace context coexist. A guessed identifier should never be enough to move a request into another person's memory.
Derive the scope from trusted identity
Resolve tenant and user identity from the authenticated request. Look up project membership in the application's access system. Construct the allowed memory scope on the server rather than accepting a raw container name from the client.
Keep identifiers unambiguous. If multiple fields are combined into one string, delimiters inside an identifier must not create collisions. The TypeScript memory contract describes the broader adapter boundary.
Treat shared context as a separate permission
A user can have personal context and access to shared project context. Query those scopes only after checking each permission. Do not turn a personal record into a workspace record simply because the model decides it is useful to the team.
When access changes, review caches and generated summaries as well as retrieval filters. A cache keyed only by the question can return another user's answer even if the underlying memory lookup was correctly scoped.
Apply the boundary to every operation
Reads, writes, corrections, exports, and deletion all need authorization. A user who cannot read a record should not be able to remove it by submitting its ID. Background connector jobs also need a defined scope and permission model.
Provider API keys should remain on trusted infrastructure. A scoped application endpoint can expose the needed operation without handing the browser broad credentials.
Build negative tests into the first integration
Use two users with identical source titles and similar questions. Change the client-supplied identifiers, replay a request after access revocation, and try a deletion under the wrong scope. Inspect returned evidence, not only the final answer.
The multi-tenant architecture guide covers isolation beyond containers, including workload interference. To test the boundary with a managed layer, start a Supermemory pilot with fictional users and keep authentication and authorization in your application.