Build Independently confirmed 2 publishers 2 min read Published Aug 25, 2026, 7:52 PM PDT

OpenAI's agent can sign in to your dashboards, and your access log will call it a user

ChatGPT Work now authenticates behind login walls through a form that keeps passwords out of the model. The party with a new access-control problem is whoever operates the portal.

The Engineer · Build desk

Send a correction

Illustration accompanying OpenAI's agent can sign in to your dashboards, and your access log will call it a user — Generated illustration

What happened

ChatGPT Work's cloud browser can now stop at a login page, hand the user a separate secure sign-in form, and carry on with the task afterwards.
OpenAI's documentation says those credentials go straight to the remote browser, stay invisible to the model and are not stored by ChatGPT.
OpenAI switched it on Tuesday for Plus, Pro and Business users on web and mobile.
Once signed in, the session can be reused by later Work tasks until it expires or the user clears that site's data in the cloud browser.

Why it matters

Who's exposed exposure A Work task authenticated against your portal arrives as an extra live session from an environment your device inventory has never seen, carrying the right password and the right second factor.
What it limits constraint Cutting off agent access to a dashboard runs through your own session lifetime and site-data clearing, so a generous keep-me-signed-in setting is now an agent access window.
Who has to decide decision Someone has to name which portals staff may authenticate an agent into, and who is allowed to approve the sign-in, before a running task settles it by default.
What it sets up precedent A vendor that does not want agent-driven logins has to reach for bot blocking and step-up authentication, which files this alongside scraper defence rather than identity policy.

Next story · Build · Oct 8

OpenAI's Ultrafast tier leaves teams to measure GPT-6.1 Sol's speedup themselves

Confirmed2 publishers

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 ^[6]. 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 ^[15]. Keeping the password away from the model protects the person who typed it ^[1]. 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 ^[7]^[8]. 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 ^[9]. Those cover actions that change state. Pulling figures out of a dashboard, which the dev.to write-up lists first among the business uses ^[12], 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 ^[17]. The dev.to account leaves the rest with the customer: deciding which accounts suit a browser task, and who can authorize a sign-in ^[13]. 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 ^[10]. Two-factor prompts cannot be bypassed by the agent and land back on the user to complete ^[11]. Bot management and step-up authentication are the levers a portal operator actually holds ^[18]. 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 ^[14]. That last one is a dashboard with a login on it.

What to watch

Whether OpenAI ships an admin-side control naming which domains a Work task may authenticate against, and whether it is enforceable by the site owner rather than the workspace.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence56
Adoption22
Hype gap+14
Incentives68
Confidence58

Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[1]
According to OpenAI's cloud browser documentation, credentials entered during the sign-in flow go directly to the remote cloud browser, are not visible to the ChatGPT model and are not stored by ChatGPT.
Reported SupportedView cited source
[2]
OpenAI expanded ChatGPT Work's cloud browser so a task can pause at a login screen, request the user's input through a secure sign-in form, and continue after authentication across web and mobile tasks.
Reported SupportedView cited source
[3]
OpenAI added authenticated website access to ChatGPT Work on Tuesday, rolling out on web and mobile for Plus, Pro and Business users, according to OpenAI.
Reported SupportedView cited source
[4]
Access is limited to paid ChatGPT plans in supported regions, and availability can vary across workspaces; OpenAI's Work documentation says access is still expanding across eligible accounts.
Reported SupportedView cited source
[5]
According to OpenAI's updated cloud browser documentation, after authentication the session can persist for later ChatGPT Work tasks until it expires or the user clears that site's browser data.
Reported SupportedView cited source
[6]
The cloud browser runs on a remote computer and maintains its own cookies, site permissions and logged-in sessions rather than borrowing credentials, tabs or history from the user's device; a user must sign in separately even when the same account is already open in a local browser.
Reported SupportedView cited source
[7]
Before showing the credential form, OpenAI says an additional review model checks the requested login and destination for signs of phishing or deception.
Reported SupportedView cited source
[8]
Users can inspect the website address, preview the sign-in form and open the live page before entering information, and OpenAI tells users never to paste passwords, security codes or payment details into the chat itself.
Reported SupportedView cited source
[9]
OpenAI has retained approval checkpoints for steps with financial, legal or account consequences, so ChatGPT Work asks before confirming a booking or making a payment, and users can take control of the remote browser.
Reported SupportedView cited source
[10]
OpenAI's documentation makes clear the cloud browser is still subject to each website's policies, and some sites may block cloud-browser or automated access, in which case the user handles the login in their own browser.
Reported SupportedView cited source
[11]
Authentication can involve steps no browser agent can bypass on its own, such as two-factor authentication, which the user is expected to complete.
Reported SupportedView cited source
[12]
The dev.to account lists pulling information from dashboards that require an account login first among the uses supported by the new authenticated browsing model, and notes teams often need information from dashboards, account portals and other signed-in services.
Reported SupportedView cited source
[13]
The dev.to account says a team still needs to decide which accounts are appropriate for a browser task, who can authorize sign-ins, and which actions deserve human review.
Reported SupportedView cited source
[14]
OpenAI's examples for the login feature include finding a DMV appointment, signing in to compare utility plans, saving apartment listings and reconciling invoices inside accounting software, with the original X announcement also citing passport appointments and reimbursement checks.
Reported SupportedView cited source
[15]
Because the cloud browser holds its own cookies and requires a fresh sign-in even when the account is open locally, an authenticated Work task appears at the target site as an additional live session originating from an environment separate from the user's own managed device.
Derived Supported
[16]
Since the authenticated session persists until it expires or the site's browser data is cleared, the length of the window in which an agent can re-enter a portal is set by that site's own session policy rather than by the duration of the task.
Derived Supported
[17]
Neither source describes an admin- or workspace-level allowlist governing which sites a ChatGPT Work task may authenticate against; the controls described are the pre-sign-in review model, the user's address and page preview, approval prompts for consequential actions, and eligibility by plan, region and workspace.
Derived Supported
[18]
The only mechanisms available to a site operator that both sources describe as effective against cloud-browser sessions are blocking automated or cloud-browser traffic and requiring an authentication step the agent cannot complete alone.
Derived Supported

Sources

2 independent publishers whose own reporting we read for this story.

dev.to
1 article · August 25, 2026
ChatGPT Work Adds Secure Website Sign-Ins for Authenticated Browser Automation
runtimewire.com
1 article · August 25, 2026
ChatGPT Work can sign in to websites without seeing your password

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

Builder

Both publishers converge on the same mechanism: the task pauses at a login page, the user types credentials into a secure form that routes them to the remote cloud browser, and the agent resumes inside the authenticated session without seeing the plaintext secret. Runtimewire supplies the fuller implementation picture, including the pre-sign-in review model, address and form preview, approval checkpoints for consequential steps and the fact that the cloud browser carries its own cookies and permissions rather than importing the local browser's state. For builders the practical constraints are the ones neither publisher resolves: sites can block cloud-browser traffic, 2FA still needs a human, and nothing in the documented flow scopes which sites or accounts a task may authenticate against.

Operator

The operational surface is a persistent, agent-driven logged-in session that lives outside the managed device. Dev.to treats this as a workflow-design problem, telling teams to decide which accounts are eligible, who authorizes sign-ins and which actions need review; runtimewire notes that the safeguards shift to post-login behaviour. What neither source provides is the portal-side view: sessions persist until the site expires them or the user clears that site's data, the site sees an extra live session, and the only operator-side controls described are blocking automated traffic or requiring an authentication step the agent cannot finish alone.

Investor

Commercially this is a paid-tier capability expansion rather than a disclosed business event. The feature shipped to Plus, Pro and Business users on web and mobile, availability varies by region and workspace, and runtimewire reads the example tasks as evidence OpenAI is moving Work from research output to task execution. No pricing change, usage figures, customer counts or revenue detail appear in either source, so any read on monetisation is inference, not reported fact.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence56: 0100
Vendor documentation only, consistently reported
Every factual element traces to OpenAI's X announcement and cloud browser/Work documentation, relayed consistently by both publishers with dates, tiers and mechanism detail. Nothing in the cluster is independently tested: the central security assurances (credentials invisible to the model, an additional phishing review model) are vendor assertions, and no third-party audit, red-team result or user report appears.
Adoption22: 0100
Shipped to paid tiers, no usage evidence
There is a real, dated rollout to Plus, Pro and Business users on web and mobile, which is more than an announcement of intent. But availability is still expanding by region and workspace, and no source reports deployment counts, enterprise usage, benchmark results or any observed authenticated-task volume, so adoption is only established as availability.
Hype gap+14: −100 understated0 aligned+100 overstated
Mildly overstated on the security framing
Both publishers hedge appropriately on reach and both flag residual risk, which keeps the gap small. The overstatement is that the reassuring parts of the story - credentials never reaching the model, a review model catching phishing before the form appears - are presented as settled properties on vendor attribution alone, while the control the story implies exists at the account level is absent: no admin or workspace allowlist over which sites a task may authenticate against is described.
Incentives68: 0100
Vendor-announcement driven with a consultancy CTA
The cluster originates from an OpenAI product announcement and OpenAI's own documentation, so the framing and evidence set are supplied by the party that benefits from adoption. The dev.to item additionally closes with an explicit pitch to hire Scalevise for AI automation assessment work, giving that write-up a direct commercial interest in the 'assess your workflows' conclusion it reaches.
Confidence58: 0100
Facts firm, consequences unverified
Confidence in what was shipped and how the flow works is high: two independent write-ups agree closely and both cite the same documentation. Confidence in the downstream security and governance picture is much lower, because the cluster contains no independent testing, no portal-operator perspective, no logging or audit detail and no usage data, and one of the two publishers has a commercial stake in its conclusion.

OpenAI's agent can sign in to your dashboards, and your access log will call it a user

What happened

Why it matters

What to watch

Clarity's read

Claim ledger

Sources

Topics and entities

Topics

Entities

What happened

Why it matters

What to watch

Clarity's read

Claim ledger

Sources

Topics and entities

Topics

Entities

Related stories