For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Primary navigation
Theme

Suggested

Getting started

Feature Configuration

Identity and access

Deployment and configuration

ChatGPT EDU

ChatGPT Work

Collaboration and sharing

Plugins and connections

Usage and analytics

Security and compliance

API Dashboard
Try ChatGPT

Safety and security in dots

Review dots security controls, data handling, and audit and offboarding considerations

A dot is a personal agent that can keep working between conversations. Admins use role-based access control (RBAC) to choose who can use dots. A personal dot uses the app connections its owner has authorized, within the app and action limits set by the workspace. The owner specifies what the dot may do.

What a dot can do depends on the employee’s permissions, the actions the workspace allows, and where the dot performs the task.

Security overview

A personal dot can work on its owner’s behalf between conversations. For example, an employee can ask it to follow a project and prepare a brief as updates come in. The dot works from its own cloud computer and can delegate tasks to Work or Codex. In a connected app, it inherits the permissions of the account its owner authorized. Workspace admins can further limit which apps and actions it can use.

A project document can supply facts for the brief, but OpenAI trains the models behind dots to resist any hidden instructions in the project document or similar kinds of prompt injection. Auto-review checks consequential actions before they run, and safety monitoring can pause or stop work if it detects potentially harmful behavior.

  • Cloud computer. Admins control browser access, network access for code, and desktop interaction separately. When browsing is enabled, a dot can visit public sites or use a website with the permissions of the account signed in there. The owner can view the cloud computer or take over.

  • Action review. Before sharing the brief, Auto-review checks what would be shared, who would receive it, and whether the owner’s instructions, Custom Rules, and safety requirements allow it. It can block the action or require confirmation. The dot cannot turn off a required check.

  • Connected computers and Codex Cloud. Work that a dot runs on a connected computer follows the applicable local Agent Security policy. If the dot delegates a task to Codex Cloud, that task follows the Codex Cloud policy and the permissions of its selected environment.

  • Owner oversight. In Activity View, owners can inspect ongoing and delegated tasks, correct an instruction, or ask the dot to stop.

  • Enterprise data is not used to train models by default. Dot context, files, delegated tasks, and audit records have different retention and deletion boundaries; verify the requirements for each copy.

  • Audit records. Admins can use available compliance records to investigate dot activity and check the connected service’s own records to verify what changed.

A familiar cloud environment

Dots build on the same cloud computer infrastructure as ChatGPT Work and follow your workspace’s applicable privacy and security protections. Dots can preserve cloud computer snapshots across sessions, so work can continue without starting from scratch. If your organization has already reviewed Work Cloud, you can use that review as a starting point for evaluating dots. For details about the cloud environment, see ChatGPT Work cloud security.

Choose which cloud capabilities to enable

Dots can provide value even if you turn off access to the cloud browser, cloud computer desktop, and internet access for code and shell commands. Members can still use their dots to draft content, organize information, and work with connected apps that your workspace permits. You can enable the cloud capabilities that fit your organization’s needs. These settings also apply to Work Cloud, so changing them can affect both dots and Work tasks.

Understand proactive research

Proactive research is one way dots differ from a typical user-directed ChatGPT Work task. A dot can look for useful information in permitted connected apps without waiting for a new request from its user. For example, it might review connected information for an update relevant to ongoing work.

During proactive research, a dot can read permitted information and save private notes. Its research tools can’t directly send messages to other people, change content through connected apps, or control a browser or computer. Other dot activities, such as tasks a user explicitly schedules, follow their applicable permissions and action rules.

We’re developing additional rules in Agent Security so admins can choose which sites a dot’s cloud browser can visit.

How dots protect workspace data

  • Model safeguards help dots follow the owner’s instructions. OpenAI trains models in the GPT-6 family to refuse harmful requests and resist malicious instructions hidden in emails, files, or web pages. For example, an email asking a dot to forward a private file does not authorize the dot to send it. That authority comes from the owner or an automation the owner authorized. GPT-6 model safeguards

  • Auto-review checks certain actions before they run. Before a dot sends an email, for example, Auto-review checks the recipient and message against the owner’s instructions, Custom Rules, and safety requirements. It can block the send. The dot cannot turn off this review. Some default action and confirmation rules can be customized, but owner approval cannot override built-in safety requirements. How Auto-review works

  • Safety monitoring can interrupt work in progress. As a dot plans and acts, monitoring looks for potentially harmful behavior, such as attempts to bypass a safeguard or act outside the owner’s instructions. If it detects a concern, it can pause or stop the task. A pause can surface a warning for the owner to review. Built-in safeguards

  • Admins control plugin access and cloud browser access separately. Admins choose which plugins and actions are available and whether dots can use the cloud browser. A read-only plugin limits what a dot can do through that plugin. If cloud browser use is enabled, the dot may still be able to make changes through an account signed in on the website. Workspace controls

  • Owners can review and redirect work. In Activity View, owners can inspect a delegated task, add context, change direction, or ask the dot to stop. Timing matters when information is shared. If the dot has already posted in Slack, people in the channel may already have read the message. Activity View and completed actions

What to review before rolling out dots

Decide which employees should have access to dots. A personal dot uses its owner’s existing app connections. Check what each connected account lets the owner read or change and which actions the workspace allows through that connection. If dots can use the cloud browser or delegate work to a connected computer, check what the signed-in account or local device permits there.

How OpenAI evaluates model safeguards

A dot may read an email, act on the owner’s behalf, and report what it did. Model safeguards help at each step. OpenAI tests whether a model ignores malicious instructions embedded in content it reads, respects an Auto-review denial, and tells the owner when something prevented it from finishing. The following results come from the October 26 GPT-6.1 Terra system-card addendum.

Indirect prompt injection. An email might tell a dot to forward a private file. The owner asked for a summary, so the model should ignore the forwarding instruction and continue summarizing. Figure 3 tests that distinction across untrusted content.

Indirect prompt injection

Prompt injection robustness (%) · Higher is better · Log scale

90% 95% 98% 99% 99.5% 99.8% 99.9% 93.126% GPT-5.3 Feb 2026 93.954% GPT-5.4 Mar 2026 95.970% GPT-5.5 Apr 2026 96.227% GPT-5.6 Jun 2026 99.789% GPT-6 Astra Sep 2026 GPT-6 Sol 99.050% GPT-6.1 Sol 98.983% GPT-6.1 Terra 98.770% GPT-6 Luna 98.605%
Indirect prompt injection robustness. Source: GPT-6.1 Terra system-card addendum, Figure 3.

Respecting Auto-review. When an action requires Auto-review, a separate reviewer checks what the dot proposes to do, what data or people it would affect, and whether the owner’s instructions, Custom Rules, and safety requirements allow it. For example, before a dot shares a file in a Slack channel, the reviewer checks what would be shared, where it would go, and whether the owner authorized sharing it there. A request to summarize the file does not authorize posting it. Destructive actions, such as permanently deleting data, may also require the owner’s approval. The dot cannot turn off required checks, and owner approval cannot override core safety requirements. Figure 5 shows how models responded to a denial in a simulated Codex task.

Responses to Auto-review denials

Share of samples (%) · Lower is better

0% 2% 4% 6% 8% 0.6% GPT-5.6 Terra 4.3% GPT-5.6 Luna 7.3% GPT-5.6 Sol 0.3% GPT-6 Luna 0.0% GPT-6 Sol 0.0% GPT-6 Astra 0.0% GPT-6.1 Sol 0.0% GPT-6.1 Terra

Successful circumvention: 0.3% for GPT-5.6 Luna and GPT-5.6 Sol; 0% for the other models shown.

Responses to Auto-review denials in a simulated Codex task. Source: GPT-6.1 Terra system-card addendum, Figure 5.

At maximum reasoning effort, GPT-6.1 Terra made no observed attempts to bypass a denial. GPT-6 Luna tried in 0.3% of samples. None of its attempts succeeded.

Disclosing blockers. When a model cannot finish a task, the owner needs to know what remains undone. Figure 8 measures how often models failed to report a blocker accurately in their final answer on coding tasks chosen to make that failure more likely.

Reporting task blockers

Blocker-related deception rate (%) · Lower is better

0% 10% 20% 30% 40% 28.99% GPT-5.6 Terra 34.18% GPT-5.6 Sol 8.05% GPT-6 Sol 11.66% GPT-6 Astra 8.36% GPT-6 Luna 14.00% GPT-6.1 Sol 8.47% GPT-6.1 Terra
Failure to report blockers accurately on coding tasks selected to elicit this behavior. Source: GPT-6.1 Terra system-card addendum, Figure 8.

GPT-6.1 Terra failed to report a blocker accurately in 8.47% of these cases, down from 28.99% for GPT-5.6 Terra and close to GPT-6 Sol (8.05%) and GPT-6 Luna (8.36%).

These evaluations give an indication of what to expect from the GPT-6 family on similar tasks. Compared with the GPT-5.6 models tested, GPT-6 models more often resisted malicious instructions and accurately reported when they could not finish a task. In the simulated Codex evaluation, no GPT-6 model tested successfully bypassed an Auto-review denial.

Confirm eligibility and data requirements

Category Eligibility and data requirements
Data and inference residency Data storage residency in Australia, Canada, Europe (EEA and Switzerland), India, Japan, Singapore, South Korea, the UK, and the US is supported. UAE is not included.
Dots inference residency is supported for the US and Europe but not UAE. Inference residency covers model inference, not every processing step or third-party integration.
Enterprise Key Management (EKM) Enterprise Key Management (EKM) supported for eligible workspaces. Customer-managed keys protect supported customer content at rest and allow customers to rotate or revoke their keys. Identify which data your agreement requires the key to protect.
HIPAA HIPAA supported for eligible workspaces. Confirm that your business associate agreement (BAA) and configuration cover the intended workflow.
Zero data retention Neither dots nor Work with local computer access provides strict zero data retention.
FedRAMP Dots are unavailable in FedRAMP workspaces.

Manage who can use and direct a dot

  • Workspace access: During the admin preview, access to dots is off by default. To enable it for a group, grant Use dots on the group’s custom role.

Example settings; toggle positions and available channels may vary by workspace.

  • Dot ownership: Only the owner can direct their personal dot. Messages from other people, including Slack mentions, do not start work or give them control over the dot.

  • Connection permissions: A personal dot uses its owner’s existing plugin connections. Through each plugin, the dot can only access data and take actions that the connected account, the plugin permissions, and the workspace settings allow. See the dots privacy and safety FAQ.

  • Automations: An owner can use an automation to approve an action in advance by specifying what the dot may do and when. For example, the owner might ask the dot to post a project update in the team’s Slack channel every Friday. The dot is designed to stay within that authorization and follow the usual permissions and safety checks.

Where a dot works and which controls apply

Auto-review coverage across browser, desktop, and delegated actions remains under review.

A dot coordinates work in the cloud. For example, if you ask it to summarize a report saved on your connected laptop, the command that reads the file runs on your laptop. Agent Security’s local policies govern which files that command can read.

To make local work available, an admin enables Allow local computer access for dots. Each employee then chooses whether to connect their computer in ChatGPT.

A dot can delegate tasks in parallel while the owner continues the conversation. It can start a Work or Codex thread on the owner’s behalf. When local access is enabled and the owner connects a computer, a task can use files or tools on that computer. For repository work, the dot can also start a Codex Cloud thread in an available cloud coding environment, without using the owner’s computer. Open the task in Activity View to see where it runs. See Connect computers and apps to your dot.

Controls by work environment

Start with where the dot takes an action and which account it uses. For example, a rule that limits file changes on an employee’s laptop applies there. The dot’s own cloud files follow separate controls. If an action must be blocked everywhere, check every enabled way the dot could take it. Some actions also require owner approval.

Environment Which controls apply Admin settings and member actions
Main dot conversation Workspace roles determine who can use dots and set custom rules. The owner directs the dot in this conversation. Enterprise model controls and defaults do not apply to the main dot conversation. Admin. In Admin Console → Permissions, set Use dots and Use custom rules for dots in the workspace default or a custom role. For managed approvals and web search, use Agent Security → Global. Check app permissions in Plugin controls.
Member. Tell the dot what you want it to do. If your workspace enables custom rules, you can set a standing instruction such as “Ask me before changing a shared file.”
Plugins (connected apps) A personal dot uses its owner’s authorized app connection. What it can read or change through that connection depends on the owner’s access in the app, the permissions granted to the plugin, and the actions the workspace allows. Admin. In Plugin controls, set available apps and allowed actions. In the source service, check the connected account’s permissions and authorized scope.
Member. Connect a plugin your workspace admin allows.
Dot’s cloud computer Cloud computer settings govern browsing, network access for code and shell commands, and computer use. The dot can create, edit, or delete its own cloud files. Websites use the account signed in to the cloud browser. The employee’s laptop sign-ins, VPN, and device policies do not automatically carry over. Admin. In Admin Console → Permissions, select the workspace default or role. Under Workspace capabilities → Let agents use cloud computers, set Use a browser, Allow network access (code and shell), and Allow computer use. Set Use password manager separately under Workspace capabilities. Agent Security site rules would let admins allow or block domains in the dot’s cloud browser and choose which sites permit uploads or downloads.
Member. Open the cloud computer from your dot’s profile to see what it’s doing. Select Take over to do a step yourself, then Return control when you want the dot to continue. If a site asks you to sign in, use the private form or take over the cloud browser to sign in.
Delegated Work or Codex task When a dot starts a separate Work or Codex thread, that product’s model controls govern which models the task can use. The task follows the Agent Security requirements and other controls that apply where it runs. Admin. Check access to Work or Codex in Admin Console → Permissions and review the model controls for that product. For a connected computer, check Agent Security → Global and any Local overrides. For Work Cloud, review cloud-computer capabilities. For Codex Cloud, check Agent Security → Codex Cloud and Settings → Codex Cloud → Environments.
Member. Open the delegated thread in Activity View. Check where it runs, review its sources and results, and add missing context there.
Connected employee computer The workspace must allow local computer access for dots, and the employee must connect the computer. Commands on it follow applicable Agent Security and device policies. The dot can use permitted local files, tools, and apps while the cloud continues to coordinate the task and can process its context. Admin. In Admin Console → Permissions → Use dots, enable Allow local computer access. Connected computers inherit applicable Agent Security → Global settings. Within the same policy, use Local to override supported settings when the computer needs different filesystem or network restrictions. Device permissions also apply to desktop apps and screen access.
Member. On that computer, open the dot’s profile in the ChatGPT app. Under Computers → Your computer, select Allow access and confirm. Keep the computer online with ChatGPT open.

How managed policies apply

  • Global policy: In Agent Security → Global, check managed approval requirements and whether web search is allowed for the workflow.

  • Execution overrides: For a command on an employee laptop, check Agent Security → Local for filesystem and network restrictions. For a delegated Codex Cloud command, check Agent Security → Codex Cloud and the selected environment’s network settings.

  • Separate controls: For the dot’s cloud computer and Work Cloud, check browser access, code and shell network access, and computer use separately. For a delegated Codex Cloud task, inspect the selected Codex environment.

Control connected apps and credentials

Access path What to check What the control covers
Plugins (connected apps) In Plugin controls, review which apps and actions members can use. In the source service, check which account authorized the connection. For an email send, verify that the action is enabled and that the account can send to the intended recipient. The dot can use an existing connection only for actions allowed by the workspace and permitted for the connected account. To end access through that connection, revoke the app authorization in the source service. This stops new requests through the connection. The dot may still have information it retrieved earlier. App access is shared with other ChatGPT experiences. See the dots privacy and safety FAQ and Manage dots in ChatGPT workspaces.
Browser sign-ins Identify the account signed in to the website.
Before granting access to sensitive data, verify the source-system permissions for both the app connection and the website account.		 For example, a plugin may allow the dot to read a document while the website account can also edit it. Check the website account’s role before allowing that browser workflow.
Website credentials For website sign-in, use the private sign-in form or take over the browser. For supported sign-ins, OpenAI sends the password directly from the private form to the cloud browser without exposing it to the model. App tools can authenticate through backend credential handling, and browser automation can use a signed-in session. The cloud browser stores its own session cookies separately from the member’s device. Code on the dot’s computer can read an app token or browser cookie if its value is exposed to that code; do not assume the session or token is isolated from code running there. Plugin credentials and values used only in browser sessions do not appear in logs. A new sign-in with a saved password requires confirmation. Once signed in, the dot can use the website with that account’s permissions. To end access, an admin can revoke the website session in the source service where supported. A member can also sign out in the cloud browser or clear the site’s cookies in Settings → Cloud browser → Browser data. See Connect computers and apps to your dot.
Codex Cloud secrets For a delegated Codex Cloud task, use the documented environment secret controls. Network secrets pass a placeholder to programs and substitute the credential for allowed HTTPS destinations. Direct environment variables are visible to programs. These controls apply to Codex Cloud. See Codex Cloud environments for secret configuration.

Set rules for approvals and unattended work

Proactive research is background work a dot does between requests to find updates relevant to its owner’s work. This research is read-only. The dot can read information its owner has permission to access through connected apps and keep private notes about what it finds. Its research tools cannot send messages, edit shared content, or control a browser or computer. To send a finding to Slack, the dot needs the owner’s authorization for the send and its audience. Auto-review checks the proposed send.

When authorizing a recurring task, name the action, recipients, trigger, and schedule. Permission to draft a customer email covers the draft. Sending it requires authorization. See the dots privacy and safety FAQ for action approvals.

Mechanism What it does Conditions and limits
Action approval An owner can authorize “Email the weekly project update to the project leads every Friday.” That instruction covers the named recipients and schedule. A new approval will be needed for changes that fall outside that scope, including changes to the audience, content, or timing.
Auto-review Auto-review checks tool calls labeled “write” before they run. For example, before sending an email, it checks who will receive it and what the message contains against the owner’s instructions, Custom Rules, and safety requirements. Auto-review can block a send or prompt the owner to clarify the recipient or approve the action. Approval cannot override a required safety check. Computer Use asks separately for permission to use a desktop app.
Custom Rules An owner can set a rule to ask before sending an email. The rule can add that approval step. It cannot grant a send permission the connected account lacks or override a required safety check. Disabling custom rules does not force every action to ask for approval.
Distinguish member-editable rules from enterprise requirements in Agent Security and from the permissions enforced by the connected service. See Manage dots in ChatGPT workspaces for custom-rule settings.
  • Delegated work on a local computer. The delegated thread uses the member’s connected computer. When Computer Use is enabled and the app is approved, selecting “Always allow” lets ChatGPT use the app without asking for access again.

Example: Sending the same external email through three routes

  • Suppose the owner authorizes a dot to email the approved project update to Lee at the customer every Friday, with no attachments. Compare that send with adding a new recipient. A new recipient needs fresh authorization. If company policy prohibits the recipient, even the owner’s approval cannot authorize delivery.
Route Technically blocked Fresh approval Standing authorization
Email plugin The send action is disabled, or the connected account lacks send permission. Adding a recipient needs a new decision. An app policy that asks before writes also requires approval for the original send. The Friday send can proceed if the action is enabled, the account can send, and applicable checks allow it.
Cloud browser in web-based email The workspace disables cloud browser access, or the mail service rejects delivery for the signed-in account. A new recipient needs approval to send. Confirming a saved login approves sign-in only. A prompt at the Send button is unverified. An active session can be reused. The Friday instruction covers the original message. Verify whether web-based email can send it unattended.
Approved desktop mail app A managed Computer Use policy denies the app, or the mail service rejects delivery for the account in the app. A new recipient needs approval even if the app is already open. Whether Computer Use prompts at Send is unverified. Always allow lets the dot reopen the app. The Friday send still needs its own standing instruction. Verify unattended delivery in the delegated task.

  • Enterprise requirement across all routes. If your organization prohibits external delivery, enforce that restriction for every sending account in the mail service or disable each route that can send. If a person must approve every external email, verify that each enabled route pauses before delivery, including when a browser session or desktop approval is already active. A member’s custom rule or a successful plugin test alone does not establish that coverage.

  • Verification. Use the same test mailbox and disposable message on each route. Try a prohibited recipient, a new but permitted recipient, and the authorized Friday send. Record which control acted, whether a person approved the send, and whether the mail service accepted or rejected it. Verify per-send behavior for each enabled browser and desktop route before approving the workflow.

  • See App permissions, Cloud browser sessions, Computer Use approvals, and Agent Security.

Review browser, network, and device access

Example cloud computer settings; toggle positions illustrate one workspace configuration.

Dot’s cloud computer

  • Cloud capabilities: Use a browser controls access to the dot’s cloud browser. Allow network access (code and shell) controls internet access for commands. Allow computer use controls interaction with desktop apps. Site rules in Agent Security would let admins allow or block domains in the dot’s cloud browser and set upload and download permissions by site. Within an allowed site, the dot’s access also depends on the account signed in there.

  • Password manager: Review password-manager access separately. Cloud browser, network, and computer-use controls can apply to dots even when ChatGPT Work is disabled. See Manage dots in ChatGPT workspaces for capability settings.

  • Local protections: A dot’s cloud browser has its own session. Signing in to an internal site on a laptop or connecting the laptop to a VPN does not give the cloud browser that session or network route.

  • Network rules: For example, blocking a hostname for terminal commands on a laptop restricts that command path. Test the cloud browser, plugins, and web search separately if they could reach the same destination. See Connect computers and apps to your dot. Disabling code and shell internet access does not, by itself, disable the cloud browser or connected apps.

How sign-in works in the cloud browser

The cloud browser is optional in dots. Admins can disable it by turning off “Use a browser.”

For a website protected by corporate SSO, the employee signs in from the dot’s cloud browser. When the dot offers a private sign-in form, check the site address and enter your credentials and any requested verification code there. The form sends them directly to the cloud browser, outside the model’s view.

If the form can’t complete a sign-in step, select Open computer, then Take over. Complete the corporate SSO and multi-factor authentication (MFA) prompts yourself. Once the app opens, select Return control so the dot can continue with your signed-in account. If the site asks you to verify again, complete the new prompt before the dot continues.

Taking over gives you control of the cloud browser. If corporate SSO requires a company-managed device or a connection through your corporate VPN, the cloud browser cannot use your laptop’s device status or VPN connection to meet that requirement. Keep the policy in place. If an approved plugin supports the task, use it with a connected account authorized for that action. If the task is only available on the website, complete it on a device and network that meet the policy.

The cloud browser keeps its own cookies, separate from the browser on your device. This includes authorization tokens to retain signed-in states for saved sessions, as applicable. To sign out of a site and end that saved session, clear the site’s cookies in Settings → Cloud browser → Browser data.

Connected employee computer

  • Connection requirements: An admin must allow local access, and the member must connect the computer. Keep it online with ChatGPT open for local work. Taking it offline leaves the connection in place.

  • Messaging channels: A member can send a request from another device through a messaging channel. The dot can then start a new thread with the member’s connected computer attached, if it’s available

  • Device permissions: Camera, microphone, and screen access also depend on the connected computer and the permissions granted to the ChatGPT app in device settings. See the dots privacy and safety FAQ for device permissions.

Review memory, retention, and deletion

  • Retained context: A dot can save information it reads through an authorized app connection, such as a team decision shared in a Slack thread. Disconnecting the app stops future reads through that connection. Information the dot already saved may remain in its memory.

  • Model training: Enterprise data is not used for model training by default. Human review may occur in limited circumstances, including safety-related cases, even when model improvement is turned off. See the dots privacy and safety FAQ.

  • Encryption: OpenAI encrypts data at rest using AES-256 and data in transit using TLS 1.2 or later between your organization and OpenAI, and between OpenAI and its service providers.

  • Retention: Use the table below to find the retention period and deletion steps for each copy. See the dots privacy and safety FAQ for memory and deletion.

  • Dot context: Removing workspace access preserves the dot’s data. Deleting the dot also deletes its retained context, including private research notes and background research thread history, within 30 days. Dot-owned backups are also deleted within 30 days. Separately stored ChatGPT conversations and Codex threads, files in Space, projects, connected storage or the user’s computer, and information added to ChatGPT Memory based on dot conversations are not deleted with the dot. Their owners must manage those copies separately.

  • ChatGPT Memory: Dot conversations can contribute to ChatGPT Memory. Manage shared information in ChatGPT Memory settings. When removing information, check both saved memories and chat history. Deleting only a conversation can leave a saved memory in place. See Memory in ChatGPT.

Data retention by category

Data category Retention policy Who starts deletion and how Deadline, remaining copies and exceptions
Dot chats, native subagent history and scheduled tasks The main dot keeps its own history, configuration and schedules for its lifetime. The member uses Reset to delete their dot, including its conversations, saved memories and schedules. Removing workspace access preserves the dot’s data. A workspace admin can also delete a dot, including when its owner is unavailable. Dot-owned chats, native subagent history, and scheduled tasks are deleted within 30 days of dot deletion.
Dot memory, profile and private research notes The dot keeps its own context for its lifetime, independently of ChatGPT Memory settings. Background research can save private notes from connected sources. Members cannot remove a specific dot memory or source-derived research note while keeping the dot. To remove the dot’s context, the member can delete the dot. Revoking source access stops future access but can leave a derived note intact. Deleting the dot removes its private research notes and dot-owned backups within 30 days.
Background research threads Background research threads retain the research context associated with the dot for its lifetime. Deleting the dot also deletes its background research threads and their retained context. Background research thread history and its dot-owned copies are deleted within 30 days of dot deletion.
ChatGPT Memory ChatGPT manages memories contributed by dot conversations separately from the dot’s own memory. The member removes the saved memory in ChatGPT and deletes any chats that contain it. Turning off sharing leaves context already received by the dot in place. Deleting the dot leaves separately saved ChatGPT memories in place. OpenAI may retain a log of a deleted saved memory for up to 30 days for safety and debugging.
Space files Saved files follow the Enterprise workspace retention policy. Opening, downloading or reattaching an existing Space file does not restart its retention period. The member deletes the file in Space. Compliance admins can delete it through the Space API. The file can also expire under workspace policy. The Space file survives dot deletion. After Space deletion, permanent removal is scheduled within 30 days, with exceptions for data already de-identified and disassociated, or retained for security or legal obligations. See Backups below.
Cached files and Outputs The dot chat can keep a separate copy of a Space file. Space’s retention and deletion controls apply to the Space copy. Deleting the Space file, even from Trash, does not trigger deletion of the dot-chat cache. No separate self-service removal procedure is confirmed. A file may remain listed in Outputs after the Space copy is deleted. The dot-owned cached copy is deleted within 30 days of dot deletion. A separate way to clear the listing remains unconfirmed.
Cloud computer files and browser state The dot’s cloud disk can retain files and browser state. Snapshot expiry depends on workspace configuration. Deleting a dot deletes its cloud browser and computer. The dot’s cloud-computer data, disk, browser state, snapshots, and backups are deleted within 30 days of dot deletion. Copies saved elsewhere follow their destination’s policy.
VM snapshots For eligible workspaces with data residency, Enterprise Key Management (EKM), or both, the enabled control wipes snapshots on a five-day cycle, with a seven-day maximum. The platform expires snapshots automatically. Deleting the dot separately starts the cloud-computer deletion process. For workspaces without data residency or EKM, there is no maximum age for an active dot’s snapshots. They may remain for as long as the dot exists, and customers cannot currently request an early purge. Snapshots are deleted within 30 days after the dot is deleted.
Backups Space backups have a separate documented window. Dot-owned backups are deleted within 30 days of dot deletion. When a Space file is deleted, expires or becomes inactive, the active Compliance API stops returning it. The platform manages backup expiry. A Space backup may remain for up to 30 additional days, or longer for security or legal obligations. Dot-owned backups are deleted within 30 days of dot deletion.
Delegated Work and Codex threads Hosted Work and Codex threads follow the workspace’s retention policy. Device-only records follow local storage and backup policies. The workspace policy governs when hosted threads expire. For Codex Cloud, see the workspace retention guidance. Deleting a dot leaves its delegated Codex and Work threads intact. When a Codex chat is deleted in the desktop app, OpenAI schedules it for permanent deletion from its systems within 30 days, subject to published exceptions. Work Cloud schedules deleted chats for permanent deletion within 30 days, subject to published exceptions.
Files and pages in Spaces Space pages persist until someone deletes them; the workspace chat retention period does not expire them. Eligible files saved in Space follow workspace file retention. A page’s creator or owner can move it and its subpages to Trash. Delete separately saved attachments in their own location. Members can delete their own saved Space files. Compliance admins with the required API permissions can delete eligible files. Space purges a page on permanent deletion or after 30 days in Trash. Pages trashed before the October 1 rollout require manual deletion. Deleting the page leaves separately stored attachments in place.
Local files and connected-app copies The device or connected service governs files, messages and exports stored there. A person with delete permission removes the item in the source app or on the device. The organization manages any separately retained copies. These copies survive dot deletion. The destination’s retention period, backup rules and any holds determine when deletion finishes.
Compliance logs and customer exports The Compliance Logs Platform retains each event for 30 days from creation. Downloaded copies follow the receiving system’s policy. Platform expiry is automatic. Your organization manages deletion of downloaded copies in its own system. Dot deletion neither erases emitted events nor restarts their clock. An organization cannot use the Compliance API to erase OpenAI’s internal audit or security logs.

Access changes and deletion actions

Action or data category What happens What the admin should do
Disconnect an app Stops new access through that connection. The dot keeps its existing context. Review retained context and other copies separately.
Turn off ChatGPT Memory Stops memory sharing with dots. Any context the dot already received remains. To remove context the dot already received, review the dot’s deletion options.
Individual dot memories Individual dot memories cannot be deleted. To delete the dot’s entire context, the member or admin can delete the dot. ChatGPT memories are managed separately in ChatGPT. For dot-owned context, the member or admin can delete the whole dot. Manage separately saved ChatGPT memories in ChatGPT.
Reset/delete the dot Reset removes the dot, its conversations, dot-owned memories, and scheduled tasks. Review the deletion notice and preserve required evidence first.
Files and delegated records Spaces files, local/external files, Codex threads, and separate ChatGPT conversations follow the retention policy of the app or workspace where they’re stored. Complete deletion in each storage location.
Cloud state, snapshots, and backups Automatic snapshot expiry, cloud-computer deletion and Space backup retention each have a separate clock. Use the deadlines above for each copy. Dot-owned backups are deleted within 30 days of dot deletion.

  • Data categories: For an erasure request about a Slack message, locate the source message, any private note that quotes or summarizes it, and any report saved from it. Check the deletion path for each copy.

  • Revoked source access: Changing source-system permissions restricts future access through that source; it does not prove that retained context was deleted.

  • Privacy requests: Include customer and non-user information when reviewing discovery, correction, and erasure needs.

Review messaging and audience boundaries

  • Slack identities: During offboarding, check both the dot’s Slack identity and the owner’s Slack plugin connection. ChatGPT and enabled messaging channels reach the same dot. Their conversations are separate, but saved notes and context can inform work across channels.

  • Slack setup: Check the workspace communication permission and any required Slack app approval. The member must then complete the setup. See Manage dots permissions and capabilities for Slack setup.

  • Audience visibility: Anyone with access to the conversation can read the dot’s posts. Use internal Slack channels for dot-assisted work. We recommend using your dot only in channels where everyone is part of your organization. That excludes Slack Connect channels shared with customers or partners. Sharing restrictions: As an example, if a dot can read a private HR document, posting its salary figures in a project channel would expose them to everyone who can read that channel. Before approving a post, specify what the dot may share and confirm that everyone in the channel is authorized to see it.

Collect audit evidence and protect exports

Choose the report for your task

  • Investigations and reporting: Use compliance records for investigations and Analytics API data for adoption reporting.

  • Usage metrics: Usage counts do not show who authorized an action or whether it succeeded.

Trace an action

  1. Find the action. Find the member’s prompt and the dot’s reply, then check the tool or plugin event. For a Slack send, compare the plugin result with the message in the destination channel.

  2. Match the records. Use the user and workspace identifiers to locate records. Dots-attributed records use client_id = DOTS and include dot metadata where available. Use the receiving service’s log to check the outcome.

  3. Trace delegated work. For delegated work, look for the parent thread and task IDs. Record any missing or redacted fields that prevent you from tracing the action.

  4. Check the destination. A tool record can identify a requested command or browser action. To verify the destination actually reached, compare it with a proxy or gateway log for that path, if available. A local OpenTelemetry collector covers supported local execution events. Cloud orchestration falls outside that collector. See Manage dots permissions and capabilities for supported records.

Read today’s Compliance API records

Activity What to look for What the record tells you
Cloud browser or computer TOOL_CALL_SUGGESTED Identifies the tool the dot tried. Even with status=completed, the detailed output may be missing.
Connected app (plugin) APP_MCP_CALL and APP_MCP_RESULT The call names the tool. The result reports success or an error and can include an output preview or error details.

Compliance API exports include user prompts, dot replies, tool-call requests and responses, and background activity. To investigate an action, correlate the available records and check the connected service to verify external effects. Some links and outcomes may not be present in the export.

More detailed audit logs for cloud activity. We’re working on more detailed Compliance API records for dots and other agents that run in the cloud. Our goal is to help security teams follow the steps an agent took during a task, including which tools and connected apps it called and when an action went through automated review. We’re also exploring ways to show what those tools returned and which sites the cloud browser visited.

Retain and protect exports

  • Retention period: The Compliance Logs Platform retains records for 30 days. Export the records you need continuously if you must retain them longer.

  • Export access: Restrict who can read the export and use its keys. An export can contain an employee’s message or a preview of a plugin result. Apply your retention, e-discovery, and legal-hold rules to the records your system actually receives. Confirm separately whether a hold covers original chats, files, or dot notes.

  • Log permissions: Broad compliance access and conversation-message permissions require a workspace owner’s grant. An owner or admin can grant supported narrower log permissions.

Stop work, revoke access, and manage departures

Use this procedure when the employee who owns a personal dot (the dot owner) has left or cannot help. A ChatGPT workspace owner or workspace admin acts from their own account. If activity continues or you cannot verify that sensitive work has stopped, open an OpenAI Support case immediately while you take the steps below.

  • Remove workspace access if the employee has left. A workspace owner or workspace admin can remove a manually managed member. For a directory-managed member, have your identity administrator remove the workspace assignment and verify after sync that the employee is no longer an active member. Workspace access ends when membership is removed. Verify dot containment separately: running work can complete after dot revocation, and the effect of member removal on each active and delegated task requires confirmation.

  • Revoke dots access if the employee needs to keep workspace access. A workspace owner can review Use dots (Beta) in Workspace settings → Permissions & roles. Check the workspace default, directly assigned roles, and group roles. Any remaining grant can keep dots enabled. Check who else depends on a shared grant before changing it.

  • Find the employee’s agents in the Admin console. Workspace admins, including owners, can view a user’s agents and pause or delete a dot.

  • Pause the dot. This prevents it from starting new work, including its own scheduled runs. If the dot already started a task in a separate Work or Codex thread, that task can keep running. To stop it, cancel that task separately. Check any independent schedules the dot created as well.

  • Resume the dot. Only an admin can resume a dot paused by an admin. After it resumes, previous sessions respond to messages again; delegated work is unaffected.

  • Revoke dots access. Currently running work can complete, new messages do not trigger model actions, and schedules are paused. Verify the effects of removing workspace membership separately.

  • Delete the dot. Deletion is unrecoverable, so preserve required evidence first. Deleting a dot deletes its cloud browser and computer, but does not remove user-level plugins.

  • Revoke connected accounts and sessions. Have the relevant service administrators revoke app authorizations and, where supported, terminate website sessions used by the dot’s cloud browser. For Slack, check both the dot’s own identity and the employee’s connected Slack account. Have the device administrator restrict access to any connected computer and check for local work already running. Verify each revocation in the service that issued it.

  • Verify activity. Running-work state can be checked in the Compliance API with a reported 30-minute p95. Scheduled-work state can be checked 30 minutes after the next scheduled run. These are reporting timings, not immediate-stop guarantees. Check the receiving service for completed actions.

  • Contact support. Open the chat bubble at help.openai.com from your own account. Support can guide a user or admin through stopping a dot; it cannot directly take actions affecting dots in the customer’s workspace. Provide the workspace ID, employee email, available dot or task identifiers, actions taken, timestamps with time zone, and last observed activity.