Start with the cookie jar. OpenAI's cloud browser keeps its own cookies and site permissions, and a user has to sign in inside it even when the same account is already open in the browser on their own machine [5]. An authenticated Work task therefore reaches a portal as its own session, from an environment that no corporate asset register covers, holding a credential the account owner supplied on purpose [1]. Keeping the password away from the model protects the person who typed it [2]. It does nothing for the company running the login page.
That is the part worth planning around. A control that assumes a session belongs to a known device will see a new device. A control that counts concurrent sessions will count one more. Neither will register anything wrong, because by their own definitions nothing is.
The screening OpenAI describes runs in the same direction as the credential isolation. A review model inspects the requested login and destination for signs of phishing or deception, and the user can check the address and open the live page before typing [6][7]. That protects the user from a hostile site. OpenAI also holds approval checkpoints before bookings, payments and other steps that are hard to reverse, and a user can take over the remote browser mid-task [8]. Those cover actions that change state. Pulling figures out of a dashboard, which the dev.to write-up lists first among the business uses [9], changes nothing and gets no prompt.
Neither write-up describes a workspace-level list of sites a Work task is permitted to authenticate against. What is described is the review model, the user preview, the approval prompts, and eligibility by plan, region and workspace [3]. The dev.to account leaves the rest with the customer: deciding which accounts suit a browser task, and who can authorize a sign-in [10]. For now that authority belongs to whoever started the task.
For the vendor on the receiving end, the enforceable surface is the one already built. Websites can block cloud-browser access, and OpenAI's documentation says the cloud browser remains subject to each site's policies [11]. Two-factor prompts cannot be bypassed by the agent and land back on the user to complete [12]. Bot management and step-up authentication are the levers a portal operator actually holds [4]. It is worth reading OpenAI's shipped examples for direction: mostly errands such as finding a DMV appointment or comparing utility plans, plus reconciling invoices inside accounting software [13]. That last one is a dashboard with a login on it.
