The report
OpenAI documents two ways an assistant can browse, with different identity boundaries. The ChatGPT desktop application's built-in browser maintains its own browser state. An optional Chrome extension can work in a user's existing Chrome profile, including signed-in sites and open tabs, after the applicable user permission flow. The difference is not cosmetic: an agent may be able to use the authority already associated with an authenticated page without being given credentials in chat.
Two sessions, different exposure assumptions
| Browser path | Documented environment | Security question |
|---|---|---|
| Built-in browser | A separate browsing state inside the desktop application | Which identities and session cookies were explicitly created in this environment, and which writes can the assistant perform? |
| Chrome extension | Existing browser profile, tabs and signed-in context, subject to permissions | Does the user's approval cover only reading a specified tab, or also acting through that site's authenticated session? |
The OpenAI help documentation does not describe a confirmed extension exploit. The risk hypothesis concerns an agent reading attacker-controlled instructions from a lower-trust webpage while operating in a higher-trust authenticated session. That would require a demonstrated cross-boundary action to count as exploitation. The existing Comet authenticated-origin prompt-injection Case documents a related mechanism in another browser assistant, not a vulnerability in this OpenAI extension.
The useful test is concrete: record the approved tab and task, relevant extension permissions, the external text the agent encountered, any attempted navigation or write action, the confirmation granted, and the resulting server-side effect. The published product note provides a map of where such a boundary could exist, not a prevalence estimate or evidence that it has been crossed.