The Message You Never Shared

A private-access AI assistant can produce an accurate summary of a conversation you never shared because it may be connected to your messages, email, calendar, or device data. The unsettling result is clear. The unanswered question is which permission, retained connection, or manipulated instruction gave it that access.

Current reporting on Instinct describes an assistant designed to connect across personal data sources, including email, messaging, calendars, and device data. Testers raised concerns about retention, authorization, and prompt injection. Those are separate issues, and treating them as one vague privacy concern makes the real risk harder to assess.

The summary is evidence of access, not an explanation

An assistant that can correctly recount a private exchange has crossed an important threshold: it had the relevant data available when it answered. That observation does not establish how the data became available, whether the access was intended, or whether it should have persisted.

A broad connection may have been granted during setup. An old authorization may still be active. The system may have indexed content beyond what a person expected from the permission screen. A prompt injection risk raises another possibility: untrusted content could influence what the assistant retrieves or how it uses connected information.

Each path calls for a different response. Revoking a permission will not fix a system that retains data longer than users expect. A clear retention policy will not prevent a malicious message from steering an assistant toward sensitive material. The first task is to identify the mechanism before declaring the incident explained.

That distinction matters for teams evaluating tools like Instinct. “It had access” and “it was authorized to use that information in this context” are different claims. A product can technically operate as designed while still creating an access boundary that users did not understand.

Retention turns a temporary connection into a durable exposure

Retention is often the quietest part of the privacy discussion. People may agree to connect a calendar to help schedule a meeting this week. They may not expect the same information, or derived summaries of it, to remain available after the immediate task is over.

The available reporting says testers flagged troubling retention concerns. That leaves several practical questions for a buyer or security reviewer: What data is stored? For how long? Can a user delete it? Does deleting a connection remove previously collected material? Are summaries, embeddings, logs, or other derived records covered by the same deletion controls?

Those questions deserve plain answers in product documentation and in the interface where access is granted. “We protect your data” does not tell someone whether a private conversation remains accessible after they disconnect an account.

Retention also shapes the blast radius of a mistake. A short-lived, narrowly scoped connection can still cause harm, but its potential exposure is bounded. A long-lived store of emails, messages, calendar entries, and device data creates more material for an authorization failure or a successful prompt injection to act upon.

This is why permission reviews should include time as well as scope. Ask when access starts, when it ends, and what remains after it ends.

Authorization needs to be visible at the moment of use

Users usually see permissions when they connect an account, then rarely revisit them. AI assistants make that model less comfortable because a single request can draw on several data sources at once.

A useful assistant should make its data path legible. If it summarizes a conversation, a user should be able to tell which conversation it used, which connected source supplied it, and why that source was in scope. If the answer combines email, messages, and calendar data, that combination should be visible before sensitive information appears in the response.

The reporting around Instinct points to authorization risk, which should push this question beyond a one-time consent screen. Authorization is a continuing decision. A person may allow an assistant to search their calendar for a scheduling request while rejecting access to private messages during a general research task.

That calls for controls with real boundaries: per-source permissions, limited scopes, expiry options, clear disconnect behavior, and an activity record people can inspect. Security teams should also test these controls with the same ambiguous requests that employees will make in practice.

The problem resembles the governance gap explored in Six Plugins, Zero Provenance: once several external connections can influence an AI response, knowing that a tool exists is not enough. Teams need to know what it can reach and how that reach is constrained.

Prompt injection changes what “connected” means

Prompt injection becomes more serious when an assistant can act on or retrieve from private sources. A hostile instruction hidden in an email, document, message, or webpage can attempt to redirect the assistant’s behavior. The risk is not limited to a strange answer. It can affect what information the assistant looks for, exposes, or acts on.

The available reporting identifies prompt injection as a concern for Instinct. Buyers should treat that as a design and testing requirement, rather than a checkbox. Ask whether untrusted content is separated from system instructions, whether the assistant confirms sensitive actions, and whether it can be induced to retrieve information outside the user’s request.

A small test can reveal a great deal. Connect a non-sensitive test account, place an instruction-like sentence in a message or document, then observe whether the assistant repeats it, follows it, or attempts to broaden its search. Record what happened. Repeat after changing permissions. The result will be more useful than a generic assurance that the product uses safeguards.

AI assistants can make private information more useful. They also compress the distance between a forgotten permission and an exposed summary. Before connecting another source, review the active grants, set the shortest practical retention period, and test the boundary with data you can afford to expose.