ChatGPT Work turns one login into a standing session its agent can reuse

The first login looks ordinary, with a person typing a password or autofilling one from a password manager ^[3]. Every login after it happens with nobody in the loop, because the cookie from that first visit sits in the cloud browser profile and the agent replays it ^[4].

A cookie of that kind is a bearer token. The site honours whoever presents it, which is why Morey Haber, chief security advisor at BeyondTrust, told ZDNet he would characterise this as an identity, security and authorization risk rather than a privacy one ^[11]. His mechanism is worth stating plainly: once authentication succeeds, the agent operates inside an authenticated session with whatever privileges and entitlements the user possesses, and a threat actor attacking the session may not need the password at all ^[12].

OpenAI's assurances are all about the credential. The model cannot see the username or password, those are never used in training, the user picks which sites are in scope, and the agent asks for confirmation before consequential actions such as completing a reservation or a payment ^[10]. All of that can hold while the exposure sits elsewhere. Listing the items and prices on a wish list, which is what ZDNet asked for ^[5], is not a reservation or a payment. It is a read, and reads are how data leaves.

The suggested uses tell you which accounts OpenAI has in mind: signing up for utilities at a new apartment, booking a DMV appointment or filling out passport renewal forms, checking X-ray and bloodwork costs through an insurance portal, and finding profiles of people open to work ^[13]. Three of those four run through accounts tied to civic or medical identity ^[14]. A hijacked session there is not a shopping inconvenience.

The failures in the test are instructive too. The same Amazon request was blocked when run from the ChatGPT website and worked only in the Windows app ^[6], and after two successful runs the Windows app was blocked as well, with ChatGPT suggesting Amazon was reacting to recent or repeated activity ^[7]. Neither failure was the stored cookie giving up ^[15]. The control that fired belonged to the counterparty, not to OpenAI and not to the buyer.

So the Monday decision is per site, and two questions sort the list. Can you kill that session yourself within minutes, or does it take someone else's admin console? And does the session reach anything you cannot undo, such as a statutory filing or a medical record?

Sessions that are both revocable by you and reversible in effect are where a standing login is fine. Revocable but irreversible means you let the agent in per task and clear the cookies afterwards, which ZDNet confirmed restores the password prompt ^[9]. Not revocable by you but reversible means read-only work at most, and you accept that the site may cut it off mid-task. Not revocable and not undoable is the quadrant a human still does by hand.

One note on naming. OpenAI shipped this as a skill ^[1]. In access terms it is one more place your users' authenticated sessions live, and the only documented way to see and remove them is a cookie list inside one user's settings screen ^[8].