# Should you allow Atlas browser for work?

> A practical security review of Atlas browser for work, covering agent permissions, data flows, admin gaps, prompt injection, and offboarding.

OpenAI has scheduled ChatGPT Atlas to stop working on August 9, 2026. That makes the decision on a new deployment unusually simple: do not approve Atlas browser for work accounts. A browser that is entering shutdown is a poor place to put company sessions, passwords, bookmarks, and policy work, regardless of how interesting its agent features are.

Existing pilots still need a security review. Employees may have imported passwords, signed into company systems, enabled browser memories, or let the agent act inside authenticated tabs. Removing the application without understanding those paths can leave sessions active, data unexported, and the same unsafe habits waiting for the replacement browser. The useful question is therefore not whether Atlas deserves a fresh exception. It is what access Atlas accumulated, what evidence your team lacks, and how to close the pilot without carrying its risk into ChatGPT, Codex, or another agentic browser.

## The approval answer is no for new deployments

A new Atlas deployment has no defensible work case because OpenAI is discontinuing the browser. OpenAI's help article titled *Evolving Atlas into ChatGPT for browser-based agentic work* says Atlas is scheduled to stop working on August 9, 2026 and directs users toward supported browser experiences in ChatGPT, Codex, or a Chrome extension. The same article warns that browsers need continuing security maintenance and tells users to move before Atlas degrades or stops receiving updates.

That changes the normal pilot calculation. A useful but immature product can sometimes justify a narrow trial. A discontinued browser cannot earn back the identity work, endpoint packaging, policy testing, user training, and incident-response preparation required to introduce it. Every hour spent approving Atlas now creates migration work with no durable operating benefit.

Do not confuse a denial with a claim that every Atlas feature is unsafe. The problem is lifecycle plus authority. Atlas is a Chromium-based browser that can hold passwords, passkeys, cookies, autofill data, extensions, browsing history, and work sessions. Its agent can also read visible pages and take actions in the current browsing session. That is a large trust surface even when the software is actively maintained. During a wind-down, the acceptable threshold should be higher, not lower.

If Atlas is already installed, classify it as a time-bounded exception under removal rather than an approved corporate browser. Freeze new users, stop new password imports, block new extensions, and give the existing pilot an owner and an end date. The owner should be accountable for session revocation and data handling, not merely application removal.

## Atlas joins browser trust with agent authority

Atlas puts two different permission systems in one process: ordinary browser permissions and an agent's delegated authority. Security reviews often inspect the first and wave through the second because both happen in a tab. That is a category error.

Browser permissions govern what a website can request from the local browser, such as camera, microphone, location, notifications, clipboard access, pop-ups, downloads, and cookies. Chromium-style site settings and macOS privacy settings constrain those resources. Password storage, autofill, extensions, certificates, and remote debugging add separate controls at the browser and device layers.

Agent authority comes from context rather than a single permission dialog. In logged-in mode, the Atlas agent can use sites that already have valid cookies, move between pages, click controls, and complete multi-stage flows. It can also use browser memories when that feature is enabled. OpenAI documents that the agent cannot run code in the browser, download files, install extensions, or access other applications and the local file system. Those are meaningful boundaries, but they do not prevent the agent from sending a message, changing a setting, exposing page content, or submitting a form on a site where the user is already authenticated.

The distinction has an operational consequence. A site permission review might show that the microphone is blocked and downloads require approval, yet the agent may still have enough authority to read an internal ticket, copy customer information into a draft, and publish that draft in another signed-in service. No operating-system prompt appears because each individual web action fits within permissions the browser already has.

Treat the session cookie as the effective credential and the task prompt as a temporary delegation. The user may type a narrow request, but the reachable authority includes every authenticated site the agent can encounter in that session. Your review must map both layers. If the worksheet only asks which device permissions Atlas requests, it misses the more consequential half.

## Page visibility controls reading, not account access

Atlas page visibility limits whether ChatGPT can read a page for on-page help and browser memories, but it is not a company-wide authorization boundary. OpenAI's Web Browsing Settings documentation says a user can disable visibility for a site from browser settings or the address bar. A disabled page is excluded from on-page assistance and does not create new browser memories.

This is useful personal control. It is also easy to overstate. Visibility does not revoke the site's cookies, sign the user out, remove stored passwords, clear previous chat content, or change general data controls. A user can turn visibility back on unless an administrator can enforce an equivalent setting. The Atlas enterprise documentation lists no Atlas-specific domain allowlists or blocklists beyond limited controls and sign-in access, so a security team should not treat a user-managed toggle as a data-loss prevention policy.

The main content paths look like this:

- Asking ChatGPT about a visible page attaches current page content to the interaction. Verify page visibility and chat deletion.
- Enabling browser memories creates summaries from visited content and associates them with the account. Verify memory settings and history deletion.
- Running the agent while logged in exposes page content and actions available through active sessions. Verify logged-out mode, task scope, and session isolation.
- Enabling diagnostics shares technical logs and publicly known URLs for browsing and search diagnostics. Verify `Help improve browsing & search`.
- Opting into web training makes eligible browsed content available to the model improvement pipeline. Verify `Include web browsing`.

Training is only one path. OpenAI says `Include web browsing` is off by default and Business and Enterprise content is not used to train models. That answers a procurement question, but it does not answer where browser memories live, whether Atlas-specific data follows your retention policy, what an agent sent to a third-party site, or whether security can reconstruct the action. A promise of no training is not a promise of no processing, storage, or disclosure.

## Browser memories, chat memory, and cookies are separate

Deleting one Atlas data type does not reliably delete the others. Browser memories, ChatGPT memory, chat history, web history, cookies, passwords, and site data have different purposes and controls. An offboarding runbook must name each one.

OpenAI says browser memories contain facts and insights derived from browsing rather than complete page copies. When server-side summarization is used, web content is summarized on OpenAI servers, the source content is deleted after summarization, and privacy-filtered summaries are deleted within seven days. The documentation also describes safety filters intended to exclude credentials, government identifiers, account recovery material, addresses, and certain medical or financial information. On supported systems, users may have an on-device summarization option.

A filter is a risk reduction, not a basis for sending secrets. Filters can misclassify new formats, infer sensitive facts from ordinary pages, or preserve a harmless-looking project detail that becomes sensitive when combined with another memory. The stronger control is to keep confidential systems invisible and browser memories off for work identities.

Browser memory and ChatGPT memory are independent. Turning off one does not turn off the other. Clearing web history removes associated browser memories according to the Atlas data-controls page, although the settings documentation warns that refresh can take time. Deleting chat history does not clear cookies, saved passwords, browser memory, or all Atlas-specific browser data. Incognito avoids saving local history, cookies, site data, and form information after the session ends, but OpenAI explicitly notes that incognito does not make the user invisible to OpenAI, the employer, the school, the internet provider, or visited services.

Cookies deserve special attention because they carry authorization. Atlas can import saved passwords, browsing history, and other browser data during setup. It can keep users signed in just like another browser. Export guidance warns teams to treat cookie and session files as sensitive, and says active sessions cannot simply be imported into another browser. The safe migration path is to reauthenticate in the replacement and revoke old Atlas sessions at the identity provider or application, not to copy session material around.

## Logged-in agent mode expands every active session

Logged-in mode should be treated as broad delegated access to the user's current browser identity, not as a convenience switch. OpenAI's Atlas agent documentation says the agent can use sites where the user is already signed in and works inside the current browsing session. In logged-out mode it does not use pre-existing cookies and will not sign into accounts without specific approval.

That difference is the cleanest risk control Atlas offers for agent tasks. Logged-out mode reduces the chance that hostile page content can reach mail, source control, payroll, customer support, cloud consoles, or document systems through existing sessions. It also makes many work automations less convenient. Security should accept that trade. Convenience is precisely what collapses isolation.

Do not rely on confirmation prompts as the primary boundary. OpenAI says Atlas pauses so the user watches actions on certain sensitive sites such as financial institutions. It does not claim that every consequential company action requires a confirmation. Deleting a repository secret, inviting an external guest, changing a redirect URI, or publishing an internal document can be severe without fitting a consumer-finance category. Users also approve prompts quickly when interruptions become routine.

A reasonable company policy separates research from action. Public-web research can run logged out with no company identity. Drafting from an internal page should happen only after a user deliberately exposes that page, with browser memory disabled and no unrelated authenticated tabs available. Actions that create, modify, share, purchase, deploy, or delete company data need a supported agent surface with auditable approvals, or they stay manual. Atlas cannot satisfy that policy today because its lifecycle has ended and its enterprise evidence is incomplete.

Custom agent instructions can ask for preferred sources and approval checkpoints, but they remain user instructions interpreted by the model. They are useful guardrails for honest tasks. They are not equivalent to enforced permissions, transaction limits, or a deny rule applied outside the model.

## Prompt injection crosses tabs through trusted authority

Prompt injection is the dominant agent-specific risk because web content can issue hostile instructions while the agent holds trusted context. OpenAI describes the attack plainly in the ChatGPT Agent System Card: an attacker places instructions on a web page or in an email to override the intended task, extract data from another logged-in source, take an unintended action, or corrupt the answer. OpenAI also says its safeguards will not stop every attack. That qualification should drive policy.

Consider a founder asking Atlas to compare renewal terms across vendor portals and draft a recommendation in the company wiki. The agent starts on a legitimate vendor page while the browser also has active sessions for email, cloud storage, and the wiki. A hidden instruction in a support article tells the agent to find the latest budget spreadsheet, encode selected cells in a query parameter, and visit an attacker-controlled address before continuing. The requested job never mentioned email or cloud storage, but logged-in mode makes those accounts reachable.

Several defenses may interrupt the chain. The model may recognize irrelevant instructions, monitoring may flag exfiltration, the destination may be restricted, or the agent may ask for confirmation. None changes the initial exposure: untrusted content and company authority share one decision loop. If the action looks like ordinary navigation, a user may never see the sensitive intermediate state.

The popular recommendation to tell the agent to ignore page instructions is inadequate. It is popular because it costs nothing and fits in a custom-instructions box. It is wrong because the policy and the attacker input are both text the model must interpret. Strong instruction hierarchy helps, but it cannot turn an authenticated general browser into a least-privilege system.

The reliable defenses sit outside that interpretation: remove unnecessary sessions, use a separate identity with limited roles, restrict reachable domains at an enforced layer, block outbound destinations where possible, and require human execution for high-impact changes. OpenAI's logged-out mode follows the same logic. It reduces ambient authority before asking the model to resist an attack.

## Enterprise controls fall short of a browser baseline

Atlas does not meet a normal enterprise-browser baseline, and OpenAI's own enterprise page says to keep regulated, confidential, and production data out of it. The page identifies Atlas for Business and Enterprise as early access and says existing ChatGPT Enterprise security and compliance commitments do not apply to Atlas. It also tells customers to treat Atlas as out of scope if they need the missing controls.

The gaps are concrete. OpenAI lists Atlas as outside its current SOC 2 and ISO attestation scope. Some web browsing data, browser memories, and agent activity may fall outside enterprise retention, storage, segregation, or deletion requirements. Atlas does not emit Compliance API logs or integrate with SIEM and eDiscovery. Atlas-specific data is not region-pinned. The documentation also lists no private egress settings, no IP allowlists, no enterprise update channel, no version pinning, and limited extension and browser-policy management.

There is an awkward documentation boundary around identity. The page says Enterprise access is off by default and admins can control sign-in and browser memories through workspace access settings. It also says the same workspace SSO settings apply to Atlas authentication. Yet Atlas lacks its own full lifecycle layer and policy bundles. The safe reading is that workspace authentication exists, while the browser does not inherit every control your team expects from a managed enterprise browser. Verify each control instead of assuming the ChatGPT workspace policy automatically covers Atlas data and browser behavior.

Atlas supports a limited set of MDM preferences under `com.openai.atlas.web`. Officially supported keys include cookie URL rules, extension allowlists and blocklists, forced extensions, extension settings, remote debugging, and password-manager enablement. Those controls help contain a pilot. They do not fill the missing audit, retention, residency, egress, update, and domain-policy gaps.

This distinction matters in procurement. A security questionnaire with a company-wide SOC 2 report and SSO checkbox can look complete while the specific beta browser sits outside those assurances. Ask for feature-level scope, data-type scope, and control enforcement. Product-family answers are not enough.

## A safe pilot isolates identity and data

Any existing pilot should use a dedicated low-privilege identity and synthetic or public data until removal. OpenAI recommends a small group, low-risk data, no production credentials, MDM preferences, and explicit alignment with legal, security, and procurement. Given the shutdown, that pilot should test migration and alternative workflows rather than expand Atlas use.

Use this five-part gate for every remaining task:

1. Name the exact sites and data classes the task needs; reject prompts such as checking everything or handling the inbox.
2. Run logged out unless the task cannot work without authentication, then use a dedicated account with the smallest role.
3. Disable browser memories and page visibility for confidential domains; do not store company passwords or payment methods in Atlas.
4. Require the user to perform any send, share, purchase, permission, deployment, or deletion action.
5. Record the task owner, affected systems, start time, result, and cleanup because Atlas cannot provide the audit trail for you.

MDM enforcement should cover the controls that Atlas actually exposes. The following shell checks give an endpoint engineer a reproducible way to see whether three important managed preferences reached a Mac:

```bash
for key in RemoteDebuggingAllowed PasswordManagerEnabled ExtensionInstallBlocklist; do
  printf '%s=' "$key"
  defaults read com.openai.atlas.web "$key" 2>/dev/null || printf 'UNSET\n'
done
```

The output shape is one `key=value` line per preference. Boolean values normally appear as `0` or `1`; the extension blocklist appears as an array when configured; and `UNSET` means the preference was not found in that domain. An example review result might read `RemoteDebuggingAllowed=0`, `PasswordManagerEnabled=0`, followed by the configured extension array. Test on a managed pilot device because MDM payload precedence and value rendering depend on how your organization delivers the profile.

A passed command does not approve the browser. It proves only that a narrow set of preferences landed. Keep a separate exception register for the controls Atlas lacks, including audit export, retention coverage, regional storage, private egress, domain restrictions, and update management. Each exception needs an owner and a removal date.

## Offboarding must revoke sessions, not just remove the app

A complete Atlas exit removes access and verifies the residual data state before the application disappears. OpenAI says bookmarks do not transfer automatically, open tabs may not transfer, browser history will not transfer, and cookies or active sessions should not be treated as ordinary migration files. ChatGPT conversations remain separate from Atlas browser data.

Start by freezing changes. Tell pilot users not to import new passwords, create bookmarks, add extensions, or start long-running work in Atlas. Export bookmarks as HTML and save needed page addresses without copying cookies. Record which company services were used and which accounts were authenticated. The browser history is useful for this inventory, but it is not proof of every agent action.

Then revoke access at the server side. End Atlas sessions in your identity provider and in high-risk services that maintain independent sessions. Rotate credentials only when they were exposed, stored contrary to policy, shared, or cannot be reliably revoked; indiscriminate rotation creates noise and may miss token revocation. Remove OAuth grants or connected-app permissions created for the pilot. Review changes in mail forwarding, external shares, repository access, cloud roles, payment settings, and recovery methods based on the actual sites the pilot touched.

Clear chats, web history, cookies, saved passwords, autofill, downloads, site data, and browser memories as separate steps. Confirm browser memory and ChatGPT memory settings independently. Remove Atlas through device management, then verify the application, managed profile exceptions, extensions, and local user launch items are gone. Keep the offboarding record in your normal ticketing system because Atlas does not provide the compliance log your investigation may need later.

Finally, choose the replacement by control fit, not feature resemblance. OpenAI points users to supported browser capabilities in ChatGPT, Codex, and Chrome, but each surface has a different session model, permission boundary, and workspace policy. Run a fresh review. Do not copy the Atlas approval sheet and change the product name.

## Evidence must follow the action path

A replacement review should test what happens after the model decides to act, because permission screenshots rarely show the whole transaction. Security needs evidence at the identity provider, browser, model service, destination application, and endpoint. If one layer records only a successful sign-in while another records only the final page, investigators cannot tell which content influenced the agent or which intermediate systems it visited.

Start with a harmless canary in an isolated test tenant. Put a unique fake customer reference in a document the test identity may read, and place a benign instruction on an external test page asking the agent to include that reference in a request to a second controlled domain. The goal is not to prove that the model is good or bad. It is to learn whether domain policy stops the request, whether a user sees an approval, and which logs capture the attempted movement. Never use a real secret for this test.

Run the same task with no authenticated session, with a read-only identity, and with the normal pilot role. A secure design should show a material reduction in reachable data and possible actions at each lower privilege level. If the results look identical, the product probably treats browser context as a flat pool rather than a set of scoped grants. That finding matters more than a polished permissions screen.

Test cancellation as well. Stop the agent after it opens the source but before it reaches the destination, then inspect cookies, drafts, temporary files, conversation state, and remote task history. A stop button may halt future clicks while leaving a draft, an uploaded attachment, or retained screenshots behind. Your incident runbook needs to know which cleanup actions are manual and which happen automatically.

Finally, compare the logs with the questions an incident responder would ask: who started the task, which identity the agent used, which pages supplied instructions, what data crossed a boundary, which approvals occurred, what changed, and whether the action was rolled back. If the service cannot answer those questions, restrict it to tasks where losing that evidence has an acceptable cost. Do not fill missing telemetry with a policy that asks users to remember what the agent did.

This test also prevents a common procurement mistake. Teams often evaluate whether an agent completes the happy path faster than a person. Completion speed says nothing about containment, attribution, or recovery. The failure path is where a work browser earns permission to hold company sessions.

## Approve a bounded capability, not an AI browser

The reusable policy decision is to approve specific agent capabilities against specific identities and data classes. A blanket category such as AI browser hides the questions that determine risk: which page content the model can read, which sessions it can reuse, which actions it can take, where derived data is stored, which controls admins can enforce, and what evidence reaches security.

For a supported replacement, require a data-flow diagram that separates local browser state, model input, memory, chat retention, diagnostics, training, third-party actions, and audit logs. Require a permission matrix that maps read, draft, submit, share, change access, spend, deploy, and delete. Test prompt injection with a canary account and a harmless secret, then verify whether monitoring records the attempted cross-site access. Marketing demonstrations rarely exercise those boundaries.

The first policy question should be whether the product is supported through the planned deployment period. Atlas fails there today. The next questions concern least privilege, enforceable domain controls, session isolation, retention, residency, update ownership, and action-level evidence. A replacement that cannot answer them should stay on public data in a sandboxed identity, regardless of how much time its agent saves in a demo.

Do not allow Atlas onto new work accounts. For existing users, finish the session inventory, revoke server-side access, clear each data store separately, export only non-sensitive bookmarks, and remove the browser. August 9 is not a procurement milestone. It is the end of the exception.