Your colleague needs to know that you are unavailable on Tuesday afternoon. Your calendar knows why.
You have connected the calendar to an assistant so it can help arrange your week. The entry includes the name of a clinic. When the assistant proposes moving a meeting, it has enough information to give a reason. The task does not require that reason to travel any farther.
“I cannot make Tuesday afternoon” would do.
This is a small example of a large problem. Information that is useful in one part of a task can be unnecessary in another. Access makes the information available to the assistant. Judgment is needed to decide where it belongs. A person can reasonably want a service to know more while wanting it to say less.
The commercial appeal of a personal assistant often rests on continuity. It can remember a preference, connect a new request with an old one, and spare you the work of explaining yourself again. That can make the service feel wonderfully attentive. But if everything it knows is treated as available for every purpose, helpful continuity becomes an invitation to cross boundaries the person never meant to remove.
The task needs an account of permission that follows the information as it moves. Reading a fact should not silently authorize every further use of it.
The reason the information was given
Privacy scholar Helen Nissenbaum offers a useful way to think about this problem. Her idea of contextual integrity asks whether information flows appropriately within a setting. What may be known, who may receive it and how it may travel all matter. An existing custom is not automatically a justified one; the norms themselves can be examined.[1]
This helps explain why secrecy alone is too small a frame. The clinic already knows the appointment. You know it. Perhaps someone close to you knows it. That does not make it public information or create a reason to include it in a work email.
Similarly, a restaurant may need to know about a dietary restriction. A delivery driver needs an address. A friend organizing a visit needs your arrival time. These people can receive the information needed for their roles without acquiring a general claim to the rest of your life.
The assistant sits across several of these settings. It might read the calendar, search for transport and draft a message in the course of one request. Its usefulness comes partly from making connections. The boundary problem comes from deciding which connections should remain inside the task.
Think about a person helping organize a family dinner. They may need to remember that one guest cannot eat a certain food. That information can guide the menu without being included in a group message explaining the guest’s medical history. The act of helping should preserve the reason the information was supplied.
A service that understands only whether data is accessible will miss this distinction. The relevant question is also whether this use, for this purpose, with this recipient, is appropriate.
That is a demanding standard for software. It is demanding for people too. We should not pretend that human assistants never overshare or misunderstand. The point is to decide what the service ought to preserve, then build ways to detect and limit mistakes.
A general permission to read a calendar cannot carry every future decision about disclosure. Nor is it sensible to interrupt the user for approval each time the assistant checks a date. The design needs to separate ordinary use within the task from a meaningful change in where the information goes.
The Tuesday email makes that change easy to see. Other cases will be less obvious. A travel booking may require a name, contact details and payment. A price comparison may require none of them. If the assistant supplies personal information while merely gathering options, it may move the disclosure earlier than the task requires.
Timing is part of permission. A fact that must eventually be shared does not have to be shared with every party considered along the way.
What connecting an account does not settle
A permission screen often presents a technical boundary. It may allow a service to read records, make changes or both. These categories matter, but they can be much broader than the ordinary purpose in the user’s mind. You want help spotting schedule conflicts. The available connection may expose a larger collection of calendar information. You want to organize receipts. The account contains years of unrelated correspondence. The usefulness of the task does not make every accessible item relevant.
There can be several layers here. The account service defines what a connection can access. The assistant’s provider may impose narrower rules. The user gives a task with its own limits. A safe and useful action has to fit the relevant boundaries together. It should not inherit the broadest permission available at any one layer simply because that layer permits it. For the reader, this leads to a practical distinction. Ask both what the connection technically permits and what the assistant is authorized to do for you. If the first is broad and the second is narrow, the provider should be able to explain how the narrow scope is maintained.
A promise in a conversation can help establish intent. It cannot, by itself, demonstrate that a boundary will hold in every situation. Where possible, the service should offer controls that reduce unnecessary access or restrict particular actions. The value of these controls lies in their effect, not in how detailed the settings page looks.
“Read-only” deserves care too. It usually describes the ability to alter records in the connected service. Reading can still reveal private information to the assisting system. The absence of a write permission does not mean that no information has moved or that nothing consequential can happen with what was read.
Imagine asking a helper to summarize a confidential document. The original file remains untouched. Yet the summary may contain its most sensitive facts. If the helper later sends that summary to someone else, the privacy consequence does not depend on whether the source file was edited.
This is why permissions should follow the information, not merely the screen on which it began.
A user should be able to request a narrow outcome in ordinary language: use the calendar to find a free hour; do not disclose the names or reasons attached to other events. A provider can then make the request concrete through its controls and review process. The user should not have to name the internal mechanism. They need to be able to express the boundary and understand whether the service can honor it.
Sometimes it cannot. A tool may offer access that is too broad for the person’s comfort. A task may require information they do not wish to provide. An honest assistant should explain the tradeoff and leave the decision open. The right answer can be to do less, use another route or stop.
The convenience of a connection is a benefit. It is not a reason to disguise its scope.
A fact has more than one future
Suppose an assistant learns that you prefer an aisle seat.
Using that fact to suggest a seat on the next trip is easy to understand. Keeping it available for future trips is a separate choice about continuity. Using material from the conversation to improve a model concerns another purpose. Passing a detail to an airline while booking creates an outside recipient.
These uses can occur in the same overall service while raising different questions. A person may welcome one and object to another. The settings should help them make that distinction.
The word memory can blur it. In ordinary conversation, remembering sounds like one activity. In a digital service, information can remain available in different forms and places: the original exchange, a retained preference, a document produced from it, or a record held by another business. Removing one does not tell us what happened to the others. The same is true of the word training. It concerns how a model is developed or improved. It should not be used as a catch-all for every way a service uses information during a task. A company can use data to provide the requested assistance while having separate rules about whether it may also be used for model improvement.
Meta’s September 2026 technical account of Muse discusses model-training use and an opt-out. That is a different policy question from the company’s commitment, discussed earlier, not to share Muse conversations and VM data with its advertising systems.[2] A reader who cares about both needs to inspect both. One reassuring sentence cannot answer every question about data.
We should also be precise about what a provider’s description establishes. It tells us the rule or design the company says it follows. Testing whether a control works as intended is a further task. If a company says information is removed or access is restricted, the relevant evidence depends on exactly what the claim covers.
For most users, the immediate need is an understandable map of the choices. They should be able to tell which uses are necessary for the task, which are optional, and what a setting changes. A control with an attractive name but an unclear effect shifts the work of interpretation back onto the person. Consent cannot be made meaningful merely by adding more switches.
There is a temptation to solve the whole problem by keeping every piece of information inside a single place. That may reduce some kinds of exposure. But an assistant asked to book a trip, send a message or complete an order must communicate with the outside world. The task itself requires selected facts to cross a boundary.
The objective should be to make those crossings appropriate and visible. The airline gets what it needs for the booking. The colleague gets the revised meeting time. Neither needs a tour through all the information that helped the assistant reach its decision.
What happens when you disconnect
The word disconnect sounds decisive. It suggests that a relationship has ended. For future access, it may do exactly what the person expects. But ending a connection is not the same operation as removing information already obtained through it. A service may have learned a preference, generated a summary or sent a message before the connection ended.
OpenAI’s public September 2026 explanation of dots makes this distinction explicit. It says disconnecting an app stops new sharing through that connection, while information already learned remains in the dot’s context. It separately describes the ability to reset that context.[3]
This is useful clarity. It also shows why readers should resist treating several controls as synonyms. A change to future access answers a different question from a change to retained context. Neither action, by itself, establishes that an outside recipient has erased an email or that every other possible use of information has been reversed.
The boundary may reach farther than the assistant’s provider. If a hotel has accepted a booking, it has a reservation record. If you have sent a colleague a message, the message is in the colleague’s system. Ending your assistant’s access does not turn time backward. That is not an argument against using an assistant. It is a reason to understand disclosure before it occurs.
A practical account of deletion should identify what is being removed, where it is being removed, and what remains. The user should not need to guess whether “forget this” refers to future personalization, a particular stored item or something else. If the service cannot remove a record held by another party, it should say so.
Nor should it imply that retaining every record is always wrong. A purchase receipt may be important if there is a dispute. An action history can help establish what was authorized. The question is how to preserve useful evidence without retaining unrelated personal details indefinitely.
There are real tensions here. A minimal record can protect privacy while making it harder to investigate a failure. A detailed record can help explain the failure while exposing more of the person’s life. The right design depends on what needs to be proved, who needs access and how long the record remains useful.
For an ordinary purchase, the order, total, seller and authorization may matter more than the entire conversation that preceded it. For a disputed disclosure, the recipient and exact information sent may be essential. A provider should think through these cases before promising either total amnesia or perfect recall.
The individual user cannot design this record system from scratch. They can ask whether one exists and what choices it offers. The provider has the responsibility to make the answer intelligible.
Other people inside your information
A personal account is rarely made only of personal facts. An inbox contains messages from other people. A calendar contains their plans. A photograph can include them. A draft may describe a colleague’s work, a friend’s difficulty or a family member’s needs. When you connect an account, you may make these details available to a service the other people did not choose.
That does not mean no one can ever use assistance with shared information. Ordinary life requires people to communicate and coordinate. It does mean that calling the data yours can conceal the interests of others. Suppose a friend sends you a private note while you are arranging a group trip. The assistant can use the parts needed to coordinate the trip without repeating the whole note to the group. It should not treat access to the message as a request to circulate it.
The distinction is familiar in human relationships. You can be trusted with information without being asked to announce it. Software that helps across relationships needs a way to preserve that distinction as it moves between tasks.
A request such as “Keep everyone informed” is especially revealing. Who counts as everyone? Informed about which parts? A helper may need to ask one precise question before acting. That moment of friction can protect the relationship the task was meant to support.
This is one of the places where a very capable assistant may need to be less expansive. More context can improve its understanding, while less disclosure improves its conduct. Good help uses the additional understanding to choose the appropriate boundary.
The burden should not fall only on the person who happened to connect the account. Providers can design defaults that limit unnecessary sharing, make recipients clear and flag sensitive changes in scope. They can give users a way to correct mistakes without making them feel that only an expert could have avoided the problem.
A service that crosses many parts of a life should be unusually good at telling them apart.
The useful boundary
It is possible to want privacy and still want help. The person who declines a broad connection may accept a narrow upload. Someone who wants the assistant to remember travel preferences may decline another use of the conversation. A person can authorize a booking while keeping the reason for the trip private. These are ordinary choices, not contradictions.
The service should make them practical. Before connecting an account for a task, it is worth asking what information the assistant actually needs. Before authorizing an outside action, ask which recipient needs which facts. When ending access, check what the control stops and what it leaves behind. These questions become easier when the provider has already done the work of making the boundaries clear.
We should expect that work. A personal assistant cannot reasonably offer to manage the connections in a person’s life while leaving the person to discover every information boundary by accident.
The aim is not to keep the assistant ignorant. Ignorance can produce its own failures. The aim is to give it enough context to help, with limits that survive the movement from one part of the task to another.
Tuesday afternoon remains unavailable. The meeting moves. Your colleague receives a brief, useful message and never learns why the old time did not work.
The assistant has used what it knows well enough to leave something unsaid.
Sources
[1] Helen Nissenbaum, “Privacy as Contextual Integrity,” Washington Law Review 79, 119–157 (2004), especially Part III, pp. 137–146. The distinction between appropriate information and appropriate distribution informs the discussion. Nissenbaum also subjects established norms to evaluation rather than treating current practice as automatically justified.
[2] Meta, “How We Built Safety Into Muse,” September 8, 2026, “Our Policy Around Data.” This is a provider description of data policy; no independent training or deletion test was conducted for this book.
[3] OpenAI, “How we build safety, security, and privacy into dots,” September 29, 2026, “Control your information and follow the work.” The described app-disconnection and context-reset controls are distinct. No inference of universal erasure or reversal of third-party disclosures is intended.