Use a familiar example
You tell an agent privately that a colleague may leave the company. The colleague is the subject of the statement. That does not make your private words available to them or to the whole team.
Likewise, a business fact can be relevant to a task without being suitable for every participant in the conversation.
Follow the information
Access needs to cover original records, retrieved passages, summaries and conclusions. Removing a name from a sentence may not remove what makes it sensitive. Content with no clear subject is not automatically safe either: an internal credential is about no one in particular and still needs to stay tightly held.
A useful general lesson needs its own justification and audience. “Several people said it” is not enough if they were all repeating one source, or if the source was the agent’s own earlier answer coming back as apparent agreement. However many people confirm a pattern, that should change what an agent believes, never what it is permitted to do.
Two answers that don’t hold up
One tempting fix is an agent that keeps nothing personal: safe, and largely useless, since the reason to give an agent memory is to hold exactly the material you wouldn’t want repeated. The other common fix is a permission label checked on the way out, which depends on every path that reads memory remembering to check it, including automatic retrieval with no visible place a check would run. A permission you have to remember to check is one you’ll eventually forget to check.
Mixing information from two different private relationships doesn’t average into something safe for either one; the only honest audience for a reply built from two people’s separate confidences is nobody. thinqOS routes access through one mandatory boundary rather than scattered per-feature checks, which narrows this failure mode. It does not by itself prove every derived-data path (summaries, cached responses, embeddings) has been independently verified against it.
Your own record shouldn’t expose who reported on you
You should be able to ask what a system holds about you and get a real answer. But if a colleague privately told an agent something about you, and your own request simply returned that raw memory, you’d learn your colleague reported on you, in their own words, at the exact moment the feature was supposed to protect them.
A subject-access answer should confirm that information concerning you exists and give you a path to contest or correct it. It should not hand you another person’s private words as your own record. Where a given feature actually lands on this is worth checking directly.
Changes matter
When a person joins a room, changes roles or loses access, the system must reconsider what can be used and disclosed. A stored summary should not bypass the permission that applied to its evidence.
Test these transitions. A static access demonstration does not prove that revocation or new room membership behaves correctly.
The thinqOS boundary
thinqOS represents separate Minds and scoped context. The full privacy architecture also addresses derived information, operators and changing audiences. Some of those protections remain work in progress.
Do not assume a confidential relationship with an agent’s operator, per-compartment encryption or deletion by destroying a key. Those are stronger claims than the running preview warrants. Review the current policies and test your intended setup.