Working on an insurance browser copilot has raised a product question that is easy to miss: what exactly has the copilot read?
A browser permission can allow an extension to operate on an email page. That permission says little about the case in front of the user. Did the copilot capture the open thread or the visible inbox rows? Did it read an attachment, record only the filename, or ignore the file? Did the content stay in the browser, or did it travel to a server for analysis?
My current view is that an insurance browser copilot needs a visible read boundary. Before a user asks for analysis or a draft, the interface should make the selected source and the movement of its data clear. This is a product hypothesis from prototype work. It does not establish how every insurance team will want to configure access.
Browser permissions are too coarse for the insurance task
Browser permissions describe technical reach. Insurance work happens at the level of a risk, policy, claim, or servicing request.
An extension may have access to an active email tab while the user thinks in terms of the one message they have opened. The page may contain older messages in the thread, participant details, attachment names, and material from another case elsewhere in the inbox view. A permission prompt cannot explain which of those items will become working context for the next answer.
The interface has to translate technical access into an operational statement. It could say that the current open thread is selected, show the detected subject and message count, list attachment names, and state whether file contents are included. If only visible page text is available, that limitation should remain visible. If a connected mailbox account can fetch the complete thread, the user should see that this is a wider source.
This boundary also helps with accuracy. An answer based on visible text may differ from an answer based on the full thread and its files. The user needs to know which source produced the result before relying on it.
Capture should begin with a deliberate action
A prototype can capture page context when a panel opens, when the user presses a capture button, or when they submit a question. Those events do not feel the same to a user.
I think the first useful design is an explicit capture step. The panel can preview the chosen context and wait for confirmation before sending it for analysis. If the page changes, the preview should become stale until the user captures again. This avoids an ambiguous state where the interface shows one email while the model still holds context from another.
Automatic preparation may still be useful. The extension can detect that a thread is open and assemble a local preview. The important point is that transmission should follow a visible user action. A small status such as “captured locally” or “sent for analysis” gives the user a meaningful distinction that a spinner cannot provide.
Email text and attachments need separate boundaries
An email thread and its attachments often carry different sensitivity and different evidential value. Detecting that a file exists is different from reading its contents.
A browser copilot should show attachment states separately. “Detected” can mean that the page exposed a filename. “Selected” can mean that the user chose the file for this task. “Uploaded” can mean that the file bytes reached the analysis service. “Fetched” can mean that a connected mailbox integration retrieved it through an API.
This distinction matters in insurance because a short email can refer to a schedule, proposal form, medical record, survey, invoice, or claim document that contains the actual detail. If the copilot has only the email, its answer should say so. If it has the file, the output should identify that file as a source. The earlier note on preserving the source channel covers the result. The read boundary covers the step before that result exists.
File limits also belong in the interface. If a prototype accepts only a fixed number of files or rejects a large attachment, the user should see which files were excluded. Silent omission can produce a neat answer from incomplete evidence.
Local settings and case content are different data
A browser extension may store configuration such as a service address or preferred endpoint. It may also send case content to a remote service. These are separate data classes and should be explained separately.
The settings screen can say what stays in browser storage. The working panel can say what case material will leave the page. If the service retains captured context for later retrieval, the interface should show that state and provide a way to remove it. If retention is temporary, the stated duration should be specific.
This is where a read boundary becomes an operating control. A user should be able to answer five questions without reading source code: what was selected, what was sent, where it was sent, what remains stored, and how to remove or replace it.
The boundary should remain visible after the answer
The source indicator should travel with the answer. A response could show that it used the visible thread, two selected files, and no connected mailbox data. Another response could show that it used a fetched full thread. This record helps a reviewer understand why two answers differ and whether the right material was available.
The same principle limits automation. A copilot that drafts a reply from captured context should still leave the user to review and send it. A system that proposes an internal update should follow a controlled write back boundary. The read record then becomes part of the evidence for the proposed action.
A pilot should test whether users understand the boundary
The first pilot should test comprehension alongside answer quality. After using the copilot, can a person say which email text it read? Can they tell whether an attachment was uploaded? Do they know whether the content remains stored? Can they change the selected context before the next question?
Those checks are more useful than a general statement that the extension has limited permissions. Limited technical permission can still expose more case material than a user expects. A visible read boundary gives the user a case-specific account of access and gives the product team a concrete standard for improving control.
For me, the near-term design goal is modest. The source preview should accurately state what the user selected. The send event should remain explicit, with the resulting source record attached to the answer. That would make a browser copilot easier to inspect before insurance teams ask it to do more.