ChatGPT Work cloud security

ChatGPT Work runs cloud tasks in an isolated environment on OpenAI-managed infrastructure. This guide explains what those tasks can access, which controls administrators can apply, and how retention and auditing apply to different categories of information.

Capabilities and controls depend on the workspace plan, rollout, configuration, and connected integration. For the broader execution model, see the ChatGPT Work Overview.

Security at a glance

• Tasks in the cloud run on OpenAI-managed infrastructure, not on the user’s device.
• A cloud task doesn’t inherit local files, desktop applications, browser sessions, or private-network access from that device.
• Connected apps use the permissions of the authorized account, which can be an individual, shared, or agent-owned account.
• Workspace and feature-specific controls govern Work access, local execution, cloud browsing, connected apps, and code or shell networking.
• Business, Enterprise, and Edu workspace data is encrypted in transit and at rest and isn’t used to train OpenAI models by default.
• Retention and audit visibility depend on the data category, storage location, event, and applicable product configuration.

Where cloud tasks run

People can start cloud tasks from supported ChatGPT web, mobile, or desktop experiences. Work on the web and mobile runs in the cloud. The desktop app can run cloud or local tasks when the corresponding permissions are available and enabled.

The user’s device sits within the organization’s own IT-managed trust boundary, outside OpenAI-operated systems. Starting a cloud task from the desktop app doesn’t give the task direct access to the user’s computer. Execution stays in the OpenAI-managed environment regardless of the surface used to start it.

Work Cloud uses the Codex task-execution harness. Work and Codex share core execution and isolation mechanisms, but their available tools, permissions, and administrative controls aren’t identical. The customer controls workspace access, approved connections, and information intentionally supplied to a task; OpenAI manages the hosted execution environment.

Work Cloud runs on shared, OpenAI-managed infrastructure. In the current supported execution path, tasks run in VM-backed sandboxes, with execution state associated with the authenticated account user in the workspace. Work can reuse an environment across tasks or replace it while preserving eligible state. This doesn’t mean every task receives a new container or that each customer has a dedicated physical host. Customers don’t provide, host, or manage Work Cloud containers.

What a cloud task can access

A cloud task can use information made available through an authorized path:

• Information a person enters into a conversation.
• Files intentionally uploaded, attached from Library, or made available through a project.
• Content retrieved through an enabled app and an authorized account connection.
• Website content accessed through an enabled cloud browser or another permitted web capability, subject to applicable access controls.

A cloud task doesn’t directly inherit access to local files, installed applications, or the user’s browser session. A device’s access to a corporate VPN, internal website, or private network doesn’t grant the cloud task that access.

An authorized connection can make information from an internal system available through its own access path. That connection doesn’t give the cloud task unrestricted access to the employee’s device or network.

Apps, plugins, and connected accounts

An app can give Work access to information or actions in another system. A plugin can use an app as one of its underlying tools. Making a plugin available doesn’t automatically enable the underlying app, authorize an account, or approve every action the integration can perform.

A task that uses an app or connector can proceed only when:

• The workspace enables the app and any plugin that requires it.
• The person has the necessary workspace or role access.
• The connection is authorized for an individual, shared, or agent-owned account.
• The connected account, approved scopes, and available app action settings permit the requested information or operation.

For apps that support Action control, administrators can allow read-only actions, all actions, or a custom set. App permissions control when ChatGPT asks for confirmation to work with an app. Depending on the app and workspace, options can include Always ask, Any changes, Important actions, and Never ask. With Any changes, supported reads can proceed without a prompt while changes require confirmation.

When the approval policy allows it, an authorized action, including a write, can run without a prompt. This doesn’t expand the app’s allowed actions, workspace access, or the connected account’s permissions. ChatGPT can still block some high-risk actions.

Confirm the plugin and each underlying app are available in the workspace. Review role access, connected-account authorization, and action permissions as distinct decisions. See Plugin controls.

Personal and shared connections

A personal connection uses the connected employee’s permissions in the source system. A shared or agent-owned connection uses the permissions of its connected account instead. That account might access information or perform actions that the requesting person couldn’t access with a personal account.

Before enabling a shared connection, limit the account’s permissions and scopes, choose who can use it, and review the actions it can perform. See Workspace Agent connections and permissions.

Content retrieved from a connected app isn’t automatically saved as a Library file. If the content is later saved to a conversation, project, Library, or synced index, that copy follows the rules for its saved location.

Cloud browser and network access

The cloud browser, web search, connected apps, and code or shell networking are separate capabilities, and can each be configured. Restricting one doesn’t automatically disable the others.

Cloud browser

The cloud browser is a hosted tool a Work task can use to interact with websites. Opening ChatGPT in a web browser or desktop app doesn’t enable cloud browsing; a cloud task can run without it.

The hosted browser doesn’t inherit the user’s local browser profile, open tabs, existing sign-ins, saved passwords, password manager, or browsing history.

Supported website interactions can include public forms and can combine information from an authorized app with a website task. Where available, website permissions include Always ask, Auto approve, and Always allow. Auto approve applies automated risk checks; Always allow removes the interactive website-access review. Neither grants new app permissions or approves every action on a website. Consequential actions can still require separate confirmation.

For a Work task to use the cloud browser in an Enterprise workspace, administrators must enable both Work access and cloud browser access. See Using cloud browser in ChatGPT.

Code and shell networking

Public internet access for code or shell execution follows its own network policy. When public internet access is off, network destinations required for ChatGPT Work can remain reachable through a managed destination allowlist.

The allowlist governs network destinations, not shell commands. Disabling public internet access for code or shell execution doesn’t, by itself, disable the cloud browser, web search, or connected apps. Changes to the network setting apply after the current code run or shell command finishes and the execution environment refreshes.

See Code and shell sandboxing.

Data handling and retention

Business, Enterprise, and Edu workspace data is encrypted in transit and at rest. OpenAI doesn’t use an organization’s business inputs or outputs to train or improve its models by default. See Enterprise privacy.

Information associated with a cloud task doesn’t follow one universal retention schedule:

Deleting a conversation, removing a Library file or saved memory, disconnecting an app, and clearing hosted browser data are separate actions. Review the relevant storage location instead of assuming one action removes every copy. See Chat and file retention policies.

Retaining appropriate conversation and execution context can help Work resume interrupted tasks, refer to previous steps, and produce more consistent results. Shorter retention or deletion can reduce that continuity, so choose settings that balance security requirements with the usefulness of the workflow.

Eligible Enterprise and Edu workspaces can use Enterprise Key Management for supported stored content, including supported hosted execution snapshots when customer-managed encryption is required. Coverage varies by data category and deployment. Rotating a key doesn’t delete existing data or, by itself, deny access to earlier encrypted content. Revoking or disabling key access is a separate action that can disrupt supported workflows. Neither replaces a retention or deletion policy.

Data residency and inference residency apply only to eligible content and supported workloads, subject to the organization’s agreement, region, and configuration. Connected apps, external providers, and some processing or synced indexes can follow separate location rules. Verify support for the product, integration, and region. See Data residency and inference residency.

OpenAI API Zero Data Retention is an API-specific control and doesn’t define retention for ChatGPT Work.

Administrator access controls

Review the controls that apply to each part of a cloud task:

• Work Cloud and Work Local: Where independent controls are available, manage cloud and local Work as distinct controls in Workspace settings > Permissions & roles. In other workspaces, local Work can share a control with Codex Local.
• Apps and plugins: Choose which integrations are available and which people or roles can use them.
• Connected-account actions: Review account permissions, application scopes, and available action or confirmation controls.
• Browser and networking: Assess cloud browser access and code or shell public-network access independently.

Where separate Work Cloud and Work Local controls are available, enable Work Cloud and disable Work Local for the intended role to permit cloud Work without local execution. Where local Work and Codex share a control, review the effect on both before disabling local execution. These controls don’t prevent an authorized person from intentionally uploading a file to a cloud task.

For supported role permissions with Default, On, and Off states, Default inherits the workspace setting, On grants access, and an explicit Off in any applicable ordinary role denies access. Some Work and plugin settings use different, two-state controls. Verify each person’s effective access, especially when more than one role applies. See Role-based access control.

Where available, the Work Cloud permission applies across supported web, mobile, and desktop experiences. It doesn’t independently select which of those surfaces can run cloud tasks. Consider device-management or other access controls if a deployment must exclude a particular surface.

Audit and compliance visibility

For eligible Enterprise and Edu workspaces, the Compliance Logs Platform can include supported Work prompts and responses. Connected-app calls have separate logs, and available source-system audit records vary by integration. Supported compliance endpoints can provide access to eligible Library files.

Coverage depends on the event and the system where it occurs. Don’t assume every shell command, browser interaction, app invocation, file operation, or approval appears in a customer-visible compliance export.

Endpoint monitoring can observe the ChatGPT client or network traffic on managed devices, but can’t inspect actions inside the hosted execution environment. Use supported Work, compliance, and connected-system records instead.

Review current compliance event coverage alongside workspace reporting, connected-system audit logs, and the retention policies of systems receiving exported records. See the OpenAI Compliance Platform.

Start with a restricted, useful workflow

A security team can upload a current vendor advisory, compare it with an authorized asset inventory, and review a draft exposure assessment before taking action. If cloud browsing or an app connection isn’t enabled, the team can provide the advisory and an approved inventory extract directly.

Start with a small group and enable only the access needed for the task. Verify connected-account permissions, data retention, human review points, and available logs before expanding the rollout. For rollout planning, see the Admin rollout guide.