ChatGPT Can Now Log In to Websites Without Seeing Your Password

ChatGPT Work can now continue tasks inside supported websites after you sign in, without exposing the username or password to the model. This is not passwordless authentication. You still enter your credentials and any two-factor code, but you enter them in a secure sign-in form that sends them directly to ChatGPT's remote browser.

The distinction matters. Hiding a password from the model removes one obvious leak path. It does not make the resulting authenticated browser session harmless. Once signed in, ChatGPT can read pages, fill forms and act with the permissions of that account. For a business, the real decision is therefore not simply “does the AI see the password?” It is “what can this session reach, change and disclose?”

What changed in ChatGPT's cloud browser?

As of 28 August 2026, OpenAI's cloud browser guide says ChatGPT Work can operate supported public and signed-in websites. It is available on paid ChatGPT plans in supported regions, excluding Free and Go, subject to rollout and workspace permissions.

The cloud browser is a separate computer in OpenAI's cloud. It does not inherit the tabs, saved passwords, extensions, browsing history or existing sessions from your laptop. It can keep working after you close your computer, then pause when it needs a sign-in, more information or confirmation.

You do not manually select a browser for every task. ChatGPT can choose a connected app, plugin or cloud browser based on the request. OpenAI recommends using a connected app or plugin when it supports the job. That is sensible: a structured integration is usually more predictable than clicking through an interface designed for people.

How the secure sign-in flow works

1. ChatGPT reaches a supported login page and pauses. It does not ask you to paste credentials into the conversation.
2. A separate review model checks the destination. OpenAI says it inspects the website address and sign-in form for signs of phishing or deception.
3. You review the domain and form. You can inspect the live website before continuing.
4. You enter the username, password and any 2FA code. Those values go directly to the remote browser. OpenAI says the model cannot see them and ChatGPT does not store those sign-in credentials.
5. ChatGPT resumes inside the authenticated session. The website's cookies can keep that session signed in for later tasks until they expire or you clear the site's browser data.
6. Consequential actions still require review. ChatGPT is designed to ask before actions that create a financial, legal, account or other real-world commitment.

Why “the model cannot see the password” is not the same as “safe”

A password is only one route into an account. A valid session cookie can carry much of the same practical authority. If the account can view invoices, export customer data or change settings, the signed-in cloud browser may be able to reach those surfaces even though the model never received the password.

OpenAI's ChatGPT agent safety guidance explicitly warns that a signed-in agent can access sensitive emails, files and account settings. It also describes indirect prompt injection: malicious text on a page tries to redirect the agent toward an unintended action or data disclosure.

This is not a theoretical edge case. NIST's 2026 agent-hijacking analysis covered more than 250,000 attack attempts against 13 frontier models. At least one successful hijacking attack was found against every target. That study does not evaluate this specific sign-in flow, but it supports a conservative operating assumption: eventually, a browser agent will encounter content designed to manipulate it.

The right security boundary is therefore the account and workflow, not the secrecy of the password alone. Use the same design principle we apply in our AI agent security checklist: break the combination of untrusted input, valuable data and an outbound action path.

Cloud browser, app or custom integration: which should a business choose?

The cloud browser is compelling for a low-frequency task that crosses several portals, such as collecting quotes or reconciling a handful of invoices. It is a poor default for a high-volume posting, payment or account-administration process. Stable production work benefits from typed inputs, narrow scopes, deterministic validation and retries that cannot duplicate an action.

Our guide to making a product usable by AI agents covers the architecture behind that custom path. The browser route is useful precisely where the structured route does not exist yet. It should not become an excuse to avoid building one for a proven, repeatable workflow.

A 10-control checklist before your first signed-in task

1. Use a dedicated account. Do not begin with an owner, administrator, finance or production-support identity.
2. Apply least privilege at the source. Limit the account to the records and actions the pilot actually needs.
3. Keep website access on “Always ask.” Move to broader approval only after the domain list and task are stable.
4. Require MFA. Treat every unexpected authentication request as a reason to stop and inspect the domain.
5. Name forbidden actions in the task. State that the agent may prepare but not submit payments, messages, deletions or contractual changes.
6. Keep human confirmation for consequences. Do not turn an approval prompt into a routine click. Review the target, values and final state.
7. Separate browsing from sensitive apps. Enable only the connected apps needed for this job, and avoid mixing private inboxes with open-web research.
8. Review data controls and retention. Decide whether screenshots and task history fit your policy before exposing customer or employee data.
9. Clear browser data after the pilot. A password that the model never saw is irrelevant if an unnecessary authenticated cookie remains active.
10. Measure accepted outcomes. Track successful completion, human review minutes, retries, blocked sites and incidents, not just tasks started.

What website owners should change

Website teams face a different question: should they allow ChatGPT's browser through the WAF or bot layer? OpenAI's cloud browser allowlisting guide says its requests use Web Bot Auth and carry HTTP Message Signatures, including a Signature-Agent value for https://chatgpt.com. The underlying RFC 9421 standard provides integrity and authenticity for selected HTTP message components. It does not replace TLS, user authentication or authorization.

That means “allow the signed agent” and “trust the signed-in user to do everything” must remain separate decisions. Verify the signature at the edge, preserve normal account permissions, keep rate limits, and test login, OAuth redirects, captcha fallbacks and confirmation screens. Never allow a user agent string alone or disable the WAF for a broad IP range.

Also make the workflow machine-legible. Use labels tied to fields, stable button names, explicit validation errors and a clear review step before a write. If your team is still at the discovery layer, our agent-readable website guide explains the publishing side. Sign-in support adds an action channel; it does not fix unclear pages or weak authorization.

A commercial pilot with a stop condition

Choose one reversible workflow with a meaningful manual baseline. A useful first pilot might read three supplier portals and prepare a comparison for review. A poor first pilot changes payroll, publishes customer communications or purchases inventory.

Run 30 representative cases and record task success, accepted result, intervention time, blocked-site rate, retries and any unexpected data access. Stop if the agent reaches outside the approved domains, asks for credentials in chat, attempts a forbidden action or produces an unauditable result. Scale only when the accepted cost and risk beat the manual or integration alternative.