Whose secrets does a family AI assistant remember?
Imagine putting party plans and a gift receipt into a shared assistant. Useful shared information and private memories may need different boundaries.
Choose the cake together
Imagine an AI assistant used by a family. Tell it who is coming to a birthday this weekend, choose a cake and prepare a shopping list. Not having to repeat the same details would be convenient.
Someone has already bought the gift. They upload the receipt and ask about the return deadline. That conversation lives in their private space.
Then the person whose birthday it is asks the family assistant, ‘What have we prepared for this weekend?’
The cake and guest count are fine to share. The contents of the gift box were meant to wait.
Even in one household using one assistant, some information belongs together and some is meant to stay apart.
Sharing the service
Octop’s README introduces a self-hosted assistant for households and small teams. It describes multiple users, per-user experts and workspaces, and optional knowledge-base sharing. That arrangement suggests a service people use together while keeping individual work separate.
For the imaginary family assistant, I would define the material to share before counting the people who can log in. A family schedule might be common material. Personal conversations and the gift receipt might stay private.
Separate accounts do not finish that decision. OWASP distinguishes authentication, which verifies identity, from authorization for particular resources and actions. A signed-in user is not automatically entitled to every resource.
In this example, membership of the household would not be enough to search the receipt. Who owns it and who it was shared with should help determine the search scope.
I would hesitate to feed the gift details into an answer and merely ask the model not to mention them. I would start by keeping that material out of the resources retrieved for this person’s question.
Running the service at home does not make the decision either. A file being on my server and a family account being allowed to read it are separate things to establish.
The model’s location deserves another look. Octop documents configurable model providers. If this imagined assistant connects to an external model API, material used to answer can travel to that API even while the service runs in the house.
So ‘we run it at home’ would leave me with questions about who processes the material and where.
The receipt goes away. What about the memory?
Add another hypothetical step. After reading the receipt, the assistant saves a short memory: ‘The birthday gift is a telescope.’ The source file and that memory are now different resources.
If the receipt is private, should its derived memory inherit the same sharing scope? Restrict the original while showing its summary to the entire family, and the surprise still escapes.
If sharing is revoked later in this example, I would want to examine whether old summaries or search results are reused. Removing the file from a list does not describe every place an answer draws from.
OWASP recommends checking permissions on every request. For this family assistant, I would apply that principle to what the person asking can access now, rather than relying only on the setting at upload time.
I still want sharing to be convenient. Organize the family schedule once and let everyone see it. Asking for that does not also ask to put personal conversations on a public noticeboard.
If I were designing this assistant, the ‘share with family’ action would explain the scope of sharing both the material and memories derived from it. Remembering well needs a record of whose memory it is.
When the birthday person asks what is ready, the assistant can talk about the cake.
It does not need to show off its knowledge of the gift.
There is a reason to keep that detail until the box opens.