ChatGPT Dots Hardening Guide

AI/ML Platform Last updated: 2026-10-09

Security hardening for ChatGPT dots, OpenAI's always-on personal agents (launched 2026-09-29): dots enablement and RBAC, owner-account protection, connected apps and Slack participation, shared cloud-computer capabilities, local computer access, custom rules and Agent Security orchestrator policy, memory and residency limits, Compliance API coverage, and the revoke, pause and reset sequence.

Product Docs

View:

OpenAI — Requirements Cheat Sheet

All controls condensed. Click any requirement to jump to full implementation details.

Requirement	Description	Rationale

Product Editions Covered: ChatGPT Enterprise, including Edu and Healthcare (dots beta, off by default; the only edition with an admin control surface for dots) · ChatGPT Business with Premium seats (“Business Premium”; owner-level controls plus a few workspace-wide levers) · ChatGPT Pro 100, Pro 200 and Pro 500 (owner-level controls only)

Overview

This guide covers dots only. Org-wide identity, SSO/SCIM, retention, EKM, Plugin controls and Compliance API ingestion live in the ChatGPT Enterprise guide.

A dot is a personal agent in ChatGPT. In OpenAI’s words: “Powered by GPT-6 Astra, your dot lives in the cloud and has its own computer and browser. You can reach it and it can keep working even when your computer is off” (Meet dots). What a dot does:

Keeps its own computer: the cloud computer keeps its own files, software and browser sessions between periods of use (Computers and apps).
Acts through its owner’s connections: it uses its owner’s existing ChatGPT plugin connections, which “are shared across dots, ChatGPT, ChatGPT Work, and Codex” (Dots privacy, security, and safety FAQs).
Is always on: it “can decide when to pause and wake up to continue”, and its owner can give it a time or a supported event that triggers work (Tasks and memory).
Delegates: it can use background agents, start cloud threads, and create Work or Codex tasks on a connected computer. Without a connected computer, it can use a Codex cloud environment its owner has created (Meet dots).
Researches and remembers: it can review connected information proactively and form memories from it (Getting started with your dot).
Can use its owner’s computer: where local access is allowed, it can use its owner’s own computer. On Enterprise, that takes a separate admin opt-in (Getting started with your dot; dots admin guide).

OpenAI launched dots on 2026-09-29 (ChatGPT release notes, “Meet your dot”; Introducing dots). Availability differs by plan:

ChatGPT Enterprise, including Edu and Healthcare: a beta, initially off by default, that a workspace admin must enable.
- This is the only edition with a documented admin control surface for dots: four dots permissions, the shared Cloud computer capabilities, Use password manager, Plugin controls, Agent Security, the Compliance API, and the Admin API group and memory endpoints.
- OpenAI’s setup steps (the dots admin guide and help 20001554) name the permission Use dots (Beta). The console label has not been checked in a live tenant (8.1 row d).
- OpenAI defines Beta as “Ready for broad testing; complete in most respects, but some aspects may change based on user feedback” (Feature maturity).
ChatGPT Business with Premium seats (“Business Premium”): dots are included (Getting started with your dot).
- The documented levers are Premium seat assignment, the workspace-wide Memory toggle, and the app controls Business admins share with Enterprise in help 11509118: workspace-wide app availability, per-app Actions and New actions, and the workspace-wide Plugin permissions default, without role-level scoping.
- No dots-specific page confirms that those app controls govern a Business Premium dot.
- Business has no custom RBAC, no Compliance API and no Analytics API.
ChatGPT Pro 100, Pro 200 and Pro 500: for users over 18 outside the EEA, the UK and Switzerland (Meet dots).
- There is no admin; the owner holds every control.
- The texting beta is Pro in the US only.

Where dots are unavailable: FedRAMP workspaces, workspaces with EKM, and workspaces with inference residency set to AE (UAE) (Cloud and local access). Dots are also not available to users under 18 (Dots FAQs). Specialist dots (with their own identity and credentials) are enterprise pilots only and are out of scope.

How dots relate to the ChatGPT Enterprise guide. Dots are a separate product from Workspace Agents, with a separate admin surface. Two §6 controls do apply; the rest do not.

Not applicable: most controls in ChatGPT Enterprise §6 (Workspace Agents Hardening) do not govern dots: agent RBAC (6.1), publish-review approval gates (6.3), agent inventory and trifecta detection (6.4), suspension (6.5), the pre-launch checklist (6.7) and the Trigger API and personal access tokens (6.8).
Applies, 6.2: its workspace app Action control baseline governs dots, because dots inherit workspace Plugin controls (“Plugin controls determine which apps are available and which actions they can perform”, Manage dots in ChatGPT workspaces). 2.1 here applies it with the current labels.
Applies, 6.6: its Compliance Logs Platform pipeline is the dots audit-record source. 6.1 here applies it.

Dots versus Workspace Agents. The overlap between the two is narrow.

Dots are personal agents that act through the member’s own connections, gated by Use dots (Beta) and three companion permissions. Dots have no event type and no endpoints.
Workspace Agents are shared agents with their own use, build and publish controls, Slack bot, event type and Admin API routes.
App controls: for a dot, Plugin controls set which apps and actions are available, App permissions set when an action needs approval, and “Each connected service’s authorization also limits what the dot can access or do” (help 20001554). Workspace App permissions “apply to ChatGPT conversations”; Workspace Agents instead “use per-agent controls set by the agent’s builder to determine which app actions are available and when end users are asked to approve them” (help 11509118).
What the two share: workspace app availability, since a Workspace Agent can use an app only if “the app is enabled for your workspace” (ChatGPT Workspace Agents for Enterprise and Business), and the connected service’s own authorization.
Connections: a dot’s plugin connections “are shared across dots, ChatGPT, ChatGPT Work, and Codex” (Dots FAQs). Workspace Agents are not on that list; they authenticate per agent with an end-user or agent-owned account (help 20001143).
Shared with Work, not with Workspace Agents: dots share the Cloud computer capabilities and Use password manager with Work Cloud (help 20001554). When managed policy is enabled, they also share the Agent Security Global orchestrator policy with Work with local access (Agent Security). OpenAI documents none of these for Workspace Agents.
Model controls: Enterprise model controls and default model settings do not apply to dots (help 20001554).

How this guide was produced. It is AI-drafted: an AI agent wrote it on 2026-10-08 from OpenAI’s documentation (Help Center, learn.chatgpt.com, the public Admin API reference) and from published security research.

It is not validated. No control has been applied to, walked through in the console of, or tested against a live tenant, and no person has reviewed it.
OpenAI’s own pages disagree with each other in several places. Each control says so where it matters, and 8.1 collects them.

A note on benchmarks:

No CIS Benchmark covers ChatGPT, OpenAI or dots (the CIS AI Benchmarks list only an MCP Server benchmark), and CISA SCuBA has no ChatGPT baseline.
DISA STIG coverage is unverifiable, because the STIG index sits behind a DoD authentication wall.
NIST and OWASP publish frameworks rather than settings (for example NIST CAISI’s agent-hijacking red-team results).
Every control here is therefore flagged no benchmark equivalent yet, originates in OpenAI’s own documentation, and maps to NIST 800-53, CIS Controls v8 and SOC 2 at the control-family level.

Intended Audience

ChatGPT Enterprise workspace owners and admins deciding whether, and for whom, to enable dots
Security engineers responsible for AI agents, connected apps and SaaS audit pipelines
GRC professionals assessing autonomous-agent risk and data residency
Pro and Business Premium users who own a dot and have no admin to do this for them

How to Use This Guide

L1 (Crawl): Essential controls for any organization that allows dots
L2 (Walk): Enhanced controls for security-sensitive environments
L3 (Run): Strictest controls for regulated industries (healthcare, finance, government)

No control in this guide needs L4 (Fly).

Scope

In scope:

the dots permissions and the shared workspace capabilities that govern them
Plugin controls as dots inherit them
the Agent Security Global policy as it applies to the shared cloud orchestrator
memory and residency limits
Compliance Logs Platform coverage
the revoke, pause and reset sequence

Section 8 records member-level settings and documented gaps that have no admin control.

Out of scope:

org-wide SSO/SCIM, retention, EKM and Compliance API pipelines (see the ChatGPT Enterprise guide)
Workspace Agents (covered by the ChatGPT Enterprise guide)
specialist dots and the planned Microsoft Agent 365 integration (neither of those two has admin documentation)
OpenAI’s own infrastructure security

Where Dots Touch the ChatGPT Enterprise Guide

Topic	ChatGPT Enterprise guide	Used here
SCIM groups and roles	1.3, 1.4	1.1 and 7.1 (SCIM-managed groups cannot be changed through the Admin API)
Retention and EKM	2.2, 2.3	5.1 (dots are unavailable in EKM workspaces)
Plugin controls and the read-only Action control baseline	3.2, 6.2	2.1. That guide’s 6.2 uses a stale Action control path and `allow_all` / `read_only` / `custom` values; 2.1 uses the help 11509118 labels (see the cross-guide note in 2.1)
Compliance Platform to SIEM pipeline	6.6	6.1 ships its own ingester for the documented event types and uses 6.6 only for immutable long-term retention (6.6’s script pulls none of the types 6.1 and 6.2 depend on except AUTH_LOG)
SSO and MFA steps	1.1 and 1.2	Not used: their paths are out of date, so 1.2 here cites the Help Center directly
Workspace Agents RBAC, publish review, inventory, suspension, pre-launch checklist, Trigger API	6.1, 6.3–6.5, 6.7, 6.8	Not applicable: these govern Workspace Agents only. 6.2 and 6.6 apply (rows above)

Automation Surfaces at a Glance

Surface	What exists for dots	Evidence
Terraform	None. The only provider in the openai namespace, openai/openai v1.3.1, manages API Platform organization and project objects, not ChatGPT workspace roles or capabilities	Terraform registry
API	ChatGPT Admin API v2.5.37 (base `https://api.chatgpt.com/v1`): group membership for manually managed groups, workspace plugin inventory, memory endpoints (list workspace and user memories, read a user’s About You summary, delete one memory entry, and delete-and-disable at user or workspace scope; no re-enable or setting-state route), and the Compliance Logs Platform. No custom-role, permission, role-assignment, workspace-default or dots route (Update Workspace User changes only a member’s built-in role and seat type). API Platform audit logs carry tenant RBAC events	Admin API reference, API Platform audit logs
CLI	Adjacent read only. The first-party `openai` CLI v1.38.0 reads API Platform tenant audit logs; it has no ChatGPT workspace or dots commands	openai-cli
SDK	Adjacent read only. openai-python types the tenant audit-log parameters; no ChatGPT workspace-admin SDK exists	developers.openai.com/llms.txt
Config	Agent Security Global and cloud `requirements.toml`, applied through the Agent Security UI. The vendor refers to a “policy API” for Global settings but publishes no route	Agent Security, Config reference
SIEM	Compliance Logs Platform JSONL (Enterprise and Edu only)	Admin API reference

Of the 18 controls, 14 have at least one setting-specific or adjacent automation surface. 3.1, 3.2 and 3.3 have only generic role-change audit visibility, and 4.4 has none.
Eleven controls carry Code Packs.
None of the eight dots permissions has a write interface, so their enforcement is ClickOps everywhere.

Access & Enablement
Connected Apps & Channels
Cloud Computer, Browser & Local Access
Autonomy & Approvals
Data, Memory & Residency
Monitoring & Audit
Lifecycle & Kill Switch
Known Gaps and Member Guidance
Compliance Quick Reference

1. Access & Enablement

1.1 Keep Use dots (Beta) off by default and grant it only through a pilot custom role

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls v8	6.8, 4.8
NIST 800-53	AC-3, AC-6, CM-7

Description

Use dots (Beta) is the master switch for dots in a ChatGPT Enterprise workspace. Leave it Off in the workspace default and grant it only through one custom role assigned to a pilot group, so every member who has a dot is one you chose.

Default and companion permissions: “Dots access is off by default for Enterprise. The other dots permissions below take effect only when a member has access to dots” (Manage dots in ChatGPT workspaces).

The three companion permissions are Add dots to Slack and Microsoft Teams (2.2), Allow local computer access (3.4) and Use custom rules for dots (4.1).
The off-by-default Enterprise beta includes Edu and Healthcare (Getting started with your dot).

Role states: a custom role can generally set a permission to Default (inherits the workspace setting), On (grants it) or Off. Off “Denies the permission through that role. Another assigned role can still grant it” (RBAC in ChatGPT).

Not every permission offers all three: “Some permissions, including certain Work and plugin controls, have only On and Off” (help 11750701), and “Available permission states can vary by feature” (Roles and workspace permissions). Confirm in the console which states Use dots (Beta) offers.
Grants can also arrive through a member’s direct role assignment or the workspace default. The Admin API exposes neither.
RBAC changes “can take up to 5 minutes to take effect” (help 11750701).

Who can edit a role later: not only Owners.

Only Owners create, delete, assign and unassign custom roles and set the workspace default.
But “Workspace Admins may be able to view or update existing roles through supported administration surfaces”, and “In ChatGPT Enterprise, a workspace Owner can allow group managers to edit permitted settings on custom roles assigned to their group” through Edit permissions on assigned roles (help 11750701; Managing groups and group managers).
“Editing a role shared by multiple groups affects all of those groups.”
OpenAI does not list which feature permissions count as “permitted” for delegated editing. Whether a group manager can change Use dots (Beta) is undocumented; treat it as possible.

Doc conflict — how roles combine.

Additive: Roles and workspace permissions says “Ordinary role permissions combine additively: another assigned role can still grant access”. Help 20001554 agrees that a granting role still allows dots “even if another role has the permission turned off”. Help 11750701 says “Permissions from ordinary roles combine additively”.

Off denies: Groups and provisioning says the opposite: “an explicit Off in any role denies that permission, even when another role grants it”.

What to do: until a live tenant settles it, treat grants as additive. Remove every grant rather than relying on an Off role.

Model controls do not apply: Enterprise model controls and default model settings do not apply to dots, which are powered by GPT-6 Astra. A model allowlist from the ChatGPT Enterprise guide does not constrain them.

Other gates still apply: this permission is the dots-specific gate, but seat type, plan and product eligibility still apply, and Lockdown Mode is evaluated separately (Roles and workspace permissions).

Pilot group type: the group type decides what you can automate.

Manually managed: the Admin API changes membership only in these groups. Use one if you want API-driven membership (the 1.1 and 7.1 Code Packs).
SCIM-managed: the Admin API returns 409 scim_managed_resource, so membership must be changed in the IdP. Use one if the IdP must stay authoritative.
Dynamic: “Rules evaluated against SCIM user attributes” (Groups and provisioning). It has no documented API representation: the Admin API’s group source lists only manual and scim, and the 1.1 pack stops with a precondition on any other value. Avoid a dynamic pilot group until a live tenant shows how it appears.

Scope and plans: these settings “apply to eligible ChatGPT Enterprise workspaces during the dots beta” (help 20001554).

Business Premium includes dots, and Premium is a seat type that owners assign in Workspace settings > Members (Billing and seats in ChatGPT Business). No dots toggle is documented for Business, so treating Premium seat assignment as a dots gate is an inference.
OpenAI documents no admin control for Pro.

Rationale

Why This Matters:

A dot is an always-on agent with its own cloud computer. It keeps working between conversations and acts through the member’s own app connections, so enabling it workspace-wide deploys autonomous agents to everyone at once.
Grants combine across the workspace default, group-assigned roles and direct assignments, so one forgotten grant silently keeps dots on, and revoking access means finding every grant.
Model allowlists from the ChatGPT Enterprise guide do not constrain dots.

Attack Prevented: Uncontrolled workspace-wide rollout of autonomous agents, and shadow access through an over-broad or forgotten role.

Prerequisites

ChatGPT Enterprise, Edu or Healthcare workspace eligible for the dots beta
Workspace owner: only Owners create, delete, assign and unassign custom roles and set the workspace default
- Workspace Admins “may be able to view or update existing roles”, and in Enterprise an Owner can let group managers “edit permitted settings on custom roles assigned to their group” (RBAC in ChatGPT)
A pilot group: manually managed if you want API-driven membership, SCIM-managed if the IdP must stay authoritative (not dynamic; see Description)

ClickOps Implementation

Step 1: Keep the workspace default Off

Navigate to: Workspace settings > Permissions & roles > Permissions > Workspace default > Workspace capabilities
Confirm Use dots (Beta) is Off

Step 2: Create the pilot role

Navigate to: Workspace settings > Permissions & roles > Custom roles > Create role
On the role’s permission page, set Use dots (Beta) to On
Set the companion permissions as 2.2, 3.4 and 4.1 recommend

Step 3: Assign the role to the pilot group

Navigate to: Custom roles > [role] > Role assignments > + Add > [pilot group] > Done

Step 4: Remove every other grant

Open every other custom role and confirm Use dots (Beta) is Default or Off
Open each member’s member profile > Direct roles and confirm no direct assignment grants dots
Allow at least 5 minutes for the change to take effect

Step 5: Limit who can edit roles later

Navigate to: Admin Console > [workspace] > Groups > [group] > Group manager permissions (Managing groups and group managers)
For every group assigned a custom role, confirm Edit permissions on assigned roles is off. This includes the pilot group, whose managers could otherwise change the pilot role’s companion settings (2.2, 3.4, 4.1), and any role shared with other groups. Only an Owner can turn this toggle on or off
Keep the built-in Admin role to people you would trust to edit roles: Admin access to update existing roles has no documented off switch

Code Implementation

Code Pack: API Script

hth-chatgpt-dots-1.01-audit-dots-group-membership.sh View source on GitHub ↗

FINDINGS=0
ALL_MEMBERS="${CGPT_TMPDIR}/all-members.jsonl"
: > "${ALL_MEMBERS}"

# Normalise the list first: a value made only of commas and spaces (a templated
# variable that came out empty) must stop the run, not read zero groups and PASS.
IFS=',' read -r -a RAW_GROUP_IDS <<<"${HTH_DOTS_GROUP_IDS}"
GROUP_IDS=()
for GID in "${RAW_GROUP_IDS[@]+"${RAW_GROUP_IDS[@]}"}"; do
  GID="$(printf '%s' "${GID}" | tr -d '[:space:]')"
  if [ -n "${GID}" ]; then GROUP_IDS+=("${GID}"); fi
done
[ "${#GROUP_IDS[@]}" -gt 0 ] \
  || cgpt_die "HTH_DOTS_GROUP_IDS contained no group ID after splitting on commas"
GROUPS_READ=0
for GID in "${GROUP_IDS[@]}"; do
  cgpt_safe_id "${GID}" "group ID"

  # 1. The group itself: name, member_count, and whether SCIM owns its roster.
  cgpt_get_ok "/manage/workspaces/${CHATGPT_WORKSPACE_ID}/groups/${GID}"
  jq -e '(.id | type == "string") and (.source | IN("manual", "scim"))' "${CGPT_BODY}" >/dev/null 2>&1 \
    || cgpt_die "Get Group ${GID} returned HTTP 200 without the documented id/source fields"
  G_NAME="$(jq -r '.name // "(unnamed)"' "${CGPT_BODY}")"
  G_SOURCE="$(jq -r '.source' "${CGPT_BODY}")"
  G_COUNT="$(jq -r '.member_count // "?"' "${CGPT_BODY}")"
  GROUPS_READ=$((GROUPS_READ + 1))
  echo "=== Group ${G_NAME} (${GID}) — source=${G_SOURCE}, member_count=${G_COUNT} ==="
  [ "${G_SOURCE}" = "manual" ] \
    || echo "  NOTE: SCIM-managed — the IdP group is authoritative; diff it as well (TRAP 3)"

  # 2. Every member, every page.
  ROSTER="${CGPT_TMPDIR}/roster-${GID}.jsonl"
  cgpt_paginate_cursor "/manage/workspaces/${CHATGPT_WORKSPACE_ID}/groups/${GID}/users" "${ROSTER}"
  ROWS="$(wc -l < "${ROSTER}" | tr -d ' ')"
  if [ "${G_COUNT}" != "?" ] && [ "${G_COUNT}" != "${ROWS}" ]; then
    echo "  WARN: member_count=${G_COUNT} but ${ROWS} member row(s) paged — membership moved mid-read; re-run (TRAP 6)"
  fi
  jq -r '"  \(.email // "(no email)")  id=\(.id)  status=\(.status)  role=\(.role)  scim=\(.is_scim_managed)"' "${ROSTER}"
  cat "${ROSTER}" >> "${ALL_MEMBERS}"

  [ "${MODE}" = "diff" ] || continue

  # 3. Anyone in the group who is not on the approved list holds a dots grant
  #    nobody approved. A deactivated member cannot sign in; still remove them.
  while IFS=$'\t' read -r EMAIL UID_ STATUS; do
    if [ "${STATUS}" = "active" ]; then
      echo "  FINDING: ${EMAIL} (${UID_}) is ACTIVE in ${G_NAME} but not on the approved list"
      FINDINGS=$((FINDINGS + 1))
    else
      echo "  INFO: ${EMAIL} (${UID_}) is ${STATUS} in ${G_NAME} and not approved — remove at next cleanup"
    fi
  done < <(jq -r --argjson ok "${APPROVED_JSON}" '
      ((.id | ascii_downcase) as $i | $ok | any(.[]; . == $i)) as $id_ok
      | (((.email // "") | ascii_downcase) as $e | $e != "" and ($ok | any(.[]; . == $e))) as $email_ok
      | select(($id_ok or $email_ok) | not)
      | [(.email // "(no email)"), .id, .status] | @tsv' "${ROSTER}")
done

# 4. Approved people who are in none of the groups: not a risk, but the pilot
#    list and the workspace have drifted apart.
if [ "${MODE}" = "diff" ]; then
  jq -r -s --argjson ok "${APPROVED_JSON}" '
      ([.[] | (.id | ascii_downcase), ((.email // "") | ascii_downcase)] | unique) as $have
      | $ok[] | . as $want | select(($have | any(.[]; . == $want)) | not)
      | "  INFO: approved entry \(.) is not a member of any listed group"' "${ALL_MEMBERS}"
fi

echo ""
echo "NOT COVERED BY THE API (console review required — TRAP 1):"
echo "  Workspace settings > Permissions & roles > Permissions > Workspace default > Workspace capabilities > Use dots (Beta) = Off"
echo "  Every other custom role: Use dots (Beta) not On; every member's Direct roles: no dots-granting role"
echo "  Groups > [group] > Group manager permissions: Edit permissions on assigned roles off (control 1.1 Step 5)"

[ "${GROUPS_READ}" -gt 0 ] || cgpt_die "no group was read — refusing to report a result"
if [ "${MODE}" = "inventory" ]; then
  echo "INVENTORY ONLY — no approved list was compared, so this is not a pass"
  exit 0
fi
[ "${FINDINGS}" -eq 0 ] && { echo "PASS: every active member of the listed group(s) is approved"; exit 0; }
echo "${FINDINGS} finding(s)"
exit 1

What the pack does: it diffs a manually managed pilot group’s roster against your approved list through the Admin API group endpoints (GET /manage/workspaces/{workspace_id}/groups/{group_id}/users, chatgpt.enterprise.directory read scope). Membership changes use the matching POST and DELETE routes with the write scope.
SCIM groups: diff the IdP group instead.
What it cannot see: a direct role assignment or a workspace-default grant. No interface reads or sets a role’s Use dots (Beta) permission itself.

Automation: ClickOps only — OpenAI exposes no write interface for a role’s Use dots (Beta) permission; the API reaches access only through manually managed group membership (Admin API reference, 2026-10-09).

Validation & Testing

Sign in as a member outside the pilot group and confirm dots is not offered
Add a pilot member, wait at least 5 minutes, and confirm dots appears
Run the 1.1 Code Pack to diff the pilot group’s roster against the approved list (for a SCIM group, diff the IdP group)
On a recurring schedule, not only at setup, open in the console the workspace default, every custom role and every member’s direct role assignments. Confirm nothing except the pilot role sets Use dots (Beta) to On, including roles an Admin or a delegated group manager could have edited since. The API cannot see those grants; between reviews, rely on 6.2’s ROLE_UPDATE / tenant.custom_role.updated detection (neither event is documented to identify a group manager or an Admin as the actor)

Expected result: Only members of the pilot group can use dots, and the console shows exactly one grant.

Compliance Mappings

Framework	Control ID	Control Description
CIS Controls v8	6.8	Define and Maintain Role-Based Access Control
CIS Controls v8	4.8	Uninstall or Disable Unnecessary Services on Enterprise Assets and Software
NIST 800-53	AC-3	Access Enforcement
NIST 800-53	AC-6	Least Privilege
NIST 800-53	CM-7	Least Functionality
SOC 2	CC6.1, CC6.3	Logical access security; role-based access authorization, modification and removal
Benchmark	None	No benchmark equivalent yet

1.2 Require SSO or personal MFA on every account that owns a dot

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls v8	6.3
NIST 800-53	IA-2(2)

Description

Put a second factor on every account that owns a dot. ChatGPT workspaces cannot enforce MFA, so on managed workspaces require SSO and close its external-domain gap; on Pro, the owner turns on MFA, then logs out of every device.

Why the owner’s account matters: whoever controls the account that owns a dot directs an always-on agent.

The account holds the member’s plugin connections, which are “shared across dots, ChatGPT, ChatGPT Work, and Codex”, and possibly a local-computer grant.
The dot’s cloud browser also keeps persistent sessions (a session remains “until you sign out or the website expires it”) and optional saved logins through Save to Passwords (Computers and apps).

Owner MFA: OpenAI’s dots security FAQ recommends MFA for the account that owns a dot: “You can turn it on in Settings → Security and login” (Dots privacy, security, and safety FAQs).

The verification methods are Authenticator app, Push notifications, Text message and Passkey.
“Enabling MFA does not automatically log you out of other devices or sessions”, so finish with Log out of all devices (Managing MFA).

Workspaces cannot enforce MFA: “MFA cannot currently be enforced at the ChatGPT workspace or API Platform organization level” (help 7967234).

The SSO gap: Required SSO covers only members whose email uses a verified domain.

“Invited members from other domains may still use another permitted sign-in method”, and “Users who can sign in another permitted way may not be covered by the same identity-provider rules” (SSO setup for OpenAI products; SSO for ChatGPT Business says the same).
Social login is one such method: “If you use a social login provider (Google, Microsoft, Apple), you aren’t required to enable MFA on your ChatGPT account, but you can set it up with your social login provider” (Authentication).
An external-domain member can therefore own a dot with no MFA that the workspace can see.

Closing the gap: do all three.

Require SSO.
Turn off Allow External Domain Invites. This affects new invitations only.
Either have existing external-domain members turn on personal MFA (at their social login provider, if they sign in that way), or grant Use dots (Beta) only through a custom role limited to verified-domain members (1.1).

Doc conflict — workspace MFA.

The pricing matrix lists “SAML SSO, MFA, and workspace user management” as available on Business and Enterprise and unavailable on Plus and Pro. Its Business card promises “essential admin controls, SAML SSO, and MFA”.

Managing MFA says admins cannot enforce MFA: “MFA cannot currently be enforced at the ChatGPT workspace or API Platform organization level.”

The pricing row links to the admin rollout guide, which describes no MFA setting.

Treat the pricing row as SSO-delivered MFA, not a workspace MFA enforcement control, until a live tenant shows one (8.1 row k).

Cross-guide note: the SSO and MFA paths in the ChatGPT Enterprise guide’s 1.1 and 1.2 are out of date, and its 1.2 describes a workspace MFA enforcement setting that help 7967234 says does not exist. Use the Help Center articles cited here.

Rationale

Why This Matters:

Whoever controls the owner’s account directs an always-on agent that holds persistent cloud-browser sessions, optional saved logins, the member’s plugin connections and possibly a local-computer grant.
Plugin connections are shared across dots, ChatGPT, ChatGPT Work and Codex, so a taken-over account reaches every app the dot uses.
Turning on MFA does not end sessions an attacker already holds; only Log out of all devices does.

Attack Prevented: Credential-stuffing and password-phishing takeover of the account that directs an autonomous agent.

Real-World Incidents:

BeyondTrust Phantom Labs, “I’m in Your Apps: Leveraging Codex Tokens to Abuse the codex_apps MCP Server” (2026-08-03): a researcher demonstration, not a reported compromise.
- A stolen ChatGPT/Codex access token with connector scopes (api.connectors.read, api.connectors.invoke) could call the victim’s connected-app tools through chatgpt.com, and provider logs showed only an OpenAI connector IP.
- This is impact context, not something MFA prevents: the techniques (device-code phishing, theft of ~/.codex/auth.json) bypass a password prompt.
- It is an analog, because dots use the same shared plugin connections; it is not a dots incident.

Prerequisites

Enterprise and Edu (and Business workspaces managed from Admin Console): a global admin for the tenant’s SSO connection and product sign-in policy (SSO setup for OpenAI products)
Standalone Business: a workspace owner whose workspace identity settings are editable (SSO for ChatGPT Business)
Before choosing Required: another authorized administrator or an approved recovery method, because “Changing a ChatGPT policy to Required or Off can sign out affected users” (help 10468051)

ClickOps Implementation

Step 1: Pro accounts (the owner does this)

If the account signs in with Google, Microsoft or Apple, turn on MFA at that provider (“you can set it up with your social login provider”, Authentication). MFA options also vary by “how your account was created” (help 7967234)
Otherwise, navigate to: Settings > Security and login > Multi-factor authentication (MFA), select a verification method (Authenticator app, Push notifications, Text message or Passkey) and complete setup
Either way, navigate to: Settings > Security and login > Log out of all devices. Logout can take up to 30 minutes

Step 2: Enterprise and Edu workspaces (require SSO)

Navigate to: Admin Console > (tenant) > Access and review Domains, Single Sign-On (SSO) and the available product sign-in policies (help 10468051)
Test the connection in a private browser window with a user who belongs to the workspace
Review workspace overrides: “Where supported, individual workspaces can have their own policy” (help 10468051)
Set the ChatGPT sign-in policy, and any workspace-specific policy, to Required only after testing and with the recovery path from Prerequisites in place

Step 3: Standalone Business workspaces (set up SSO)

Sign in as a workspace owner and navigate to: Workspace settings > Identity & access > Identity & provisioning. Confirm the domain and SSO settings are editable
- If they are read-only or show Cloud Console, stop: a global admin manages the existing shared connection and the ChatGPT sign-in policy in Admin Console (Step 2). Do not create a second connection (help 11489188; help 10468051)
Under Verified Domains, add and verify an email domain your members use
Under Single Sign-On (SSO), select Set up SSO, choose SAML or OIDC, and configure the identity-provider app with the values shown
Assign a test user in the identity provider and confirm they can sign in. Before changing sign-in requirements, confirm another workspace owner or an approved recovery method is available
Help 11489188 refers to a workspace that “requires SSO” but names no control for it on standalone Business; Required, Optional and Off are documented only as Admin Console product policies (help 10468051). Record the real setting in a live tenant (8.11). Until then, Step 4 and personal MFA carry the requirement

Step 4: Close the external-domain gap

Turn off Allow External Domain Invites. Turning it off “limits new invitations; it does not remove existing guests or invitations already sent” (help 10468051)
- Location: OpenAI does not document where this toggle is. Neither help 10468051 nor help 11489188 gives a path, so confirm the location in a live tenant (8.11)
- Who can change it: on standalone Business it is a workspace-owner setting (“a workspace owner can turn on Allow External Domain Invites”, help 11489188). The Enterprise/Edu article does not name the role
List every external-domain member who holds a dots grant. Have each turn on personal MFA (Step 1, at their social login provider if they sign in that way), or remove them from the dots role (1.1)

Code Implementation

Code Pack: Sigma Detection Rule

hth-chatgpt-dots-1.02-password-login-dot-owner.yml View source on GitHub ↗

logsource:
    product: openai
    service: chatgpt-compliance
    definition: 'ChatGPT Compliance Logs Platform JSONL records with type AUTH_LOG; nested keys flattened with dots (action_data.auth_provider_name)'
detection:
    selection:
        type: 'AUTH_LOG'
        action_data.action:
            - 'login_success'
            - 'native_login_success'
            - 'signup_success'
        action_data.auth_provider_name: 'password'
    condition: selection
fields:
    - timestamp
    - event_id
    - actor.user_id
    - actor.user_email
    - action_data.action
    - action_data.auth_provider_name
    - request_metadata.client_ip
    - request_metadata.client_user_agent

The Sigma rule detects part of the gap rather than closing it.

What it catches: password sign-ins, which did not go through SSO. AUTH_LOG has no MFA-state field, but action_data.auth_provider_name (documented example password) reveals a password sign-in.
What it misses: social-login sign-ins (Google, Microsoft, Apple) also bypass Required SSO, but the spec documents no auth_provider_name value for them (or for SSO). The rule does not match them until a live tenant records the values.
What it needs: raw AUTH_LOG records. Create a ChatGPT Admin key (Custom) with only chatgpt.enterprise.compliance_logs_platform.auth_log.read (UI label not documented), then land the records with the 6.1 pack (HTH_CLP_EVENT_TYPES=AUTH_LOG HTH_CLP_OUT=<path>, carrying each printed checkpoint forward).
Plans: it reads the Compliance Logs Platform, so it works on Enterprise and Edu only (Admin API reference, Auth tag).

Automation: ClickOps only — OpenAI exposes no write interface for this setting, and MFA “cannot currently be enforced at the ChatGPT workspace or API Platform organization level” (Managing MFA, 2026-10-09).

Validation & Testing

Pro: sign out, sign back in, and confirm the second factor is required (at the social login provider, for a social-login account). Confirm Log out of all devices ran after MFA was enabled
Confirm the sign-in settings:
- Enterprise and Edu (and Business workspaces managed from Admin Console): the ChatGPT sign-in policy is Required, and no workspace override sets it otherwise
- Standalone Business: SSO is set up and a test user signs in through it. Record what require-SSO control the live tenant actually shows
- Everywhere: Allow External Domain Invites is off
List every external-domain member who holds a dots grant, and confirm each has personal MFA on or has been removed from the dots role
Confirm the 1.2 Sigma rule fires on a test login where auth_provider_name is password
Sign in once through SSO and once through each permitted social provider, record the auth_provider_name values each produces, and add the social values to the rule’s selection

Expected result: Every account that owns a dot signs in through SSO or with a second factor.

Compliance Mappings

Framework	Control ID	Control Description
CIS Controls v8	6.3	Require MFA for Externally-Exposed Applications
NIST 800-53	IA-2(2)	Multi-factor Authentication to Non-privileged Accounts
SOC 2	CC6.1	Logical access security
Benchmark	None	No benchmark equivalent yet

2. Connected Apps & Channels

2.1 Restrict the app connections and actions dots inherit to read-only by default

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls v8	3.3, 2.5
NIST 800-53	AC-3, AC-6, CM-7
CISA SCuBA (source-system consent)	MS.AAD.5.2v1, MS.AAD.5.3v1, GWS.COMMONCONTROLS.10.1v1, 10.2v1, 10.4v1

Description

Dots act through their owners’ ChatGPT app connections. In Plugin controls (Action control and App permissions), apply a read-only baseline to every app dot users hold: read actions only, new actions restricted, and approval prompts on.

Two separate limits:

ChatGPT side: Plugin controls are the ChatGPT-side limit on what an injected dot can do in connected apps.
Service side: each connected service’s own authorization is a separate limit. “Each connected service’s authorization also limits what the dot can access or do” (Manage dots in ChatGPT workspaces), and “Provider approval, OAuth scopes, and ChatGPT action settings are separate checks” (help 11509118).

What a dot inherits:

Granting dots does not grant app access: “Dots access does not grant access to apps or websites”, and admins “Set app access and action restrictions in Plugin controls” (dots admin guide).
But “Plugin permissions are shared across dots, ChatGPT, ChatGPT Work, and Codex” (Dots FAQs), so whatever a member’s connections allow, their dot inherits.
When a plugin capability runs through a Codex host, “the host’s sandbox and approval policy applies” (Plugins).
A dot can also review connected information proactively and “form memories from it, even when you haven’t asked”. Disconnecting an app “does not delete information your dot has already obtained from it” (Getting started with your dot).

The baseline: apply the read-only intent of the ChatGPT Enterprise guide’s 6.2, using the current controls in help 11509118.

Actions: enable only Read actions.
New actions: select Only enable new read actions or Disable new actions. Disable new actions “applies only to actions introduced later” and does not disable actions already enabled.
Permissions: use Always ask for apps that hold sensitive data (mail, files, calendars) and for write-capable apps. Reserve Allow read actions for low-sensitivity apps where reads may proceed without a prompt.
Why Always ask: it is the only setting that would surface a read like the one in the Check Point incident below (“even read-only ‘low-risk actions’ can carry significant risk”), and a dot’s proactive research reads connected apps without being asked.
Never use: Allow low-risk actions or Allow all actions. The standard workspace-wide selector does not offer Allow all actions, “although existing policy configurations can differ”, and an individual app can offer it, so check each app.

Cross-guide note: the ChatGPT Enterprise guide’s 6.2 and its config pack use a Workspace settings → Apps → {App} → Action control path with values allow_all, read_only and custom, and a newly-added-actions deny toggle.

Help 11509118, which that pack cites, no longer uses those values. It places these controls under Admin console > Plugins > {plugin} > Apps as Actions (Read or Write actions), New actions (Enable all new actions / Only enable new read actions / Disable new actions) and Permissions.

The Action control label remains only on the retained Workspace apps page (chatgpt.com/admin/ca).

Use the labels in this control.

Doc conflict — App permissions labels.

Work Cloud security lists the options as “Always ask, Any changes, Important actions, and Never ask”, “depending on the app and workspace”.

Help 11509118 (updated 2026-10-08) and Managing app permissions list Always ask, Allow read actions, Allow low-risk actions and Allow all actions.

If the Work Cloud security labels appear in your console, Always ask is unchanged, and Any changes (“supported reads can proceed without a prompt while changes require confirmation”) corresponds to Allow read actions, not to a read-only setting. Never choose Important actions or Never ask.

Legacy workspace-wide configurations may still show Allow all actions (help 11509118).

Scope and plans:

Role-specific app access is Enterprise and Edu only.
Business: admins control workspace-wide app availability. Help 11509118’s Actions, New actions and Workspace settings > General > Settings > Plugin permissions controls carry no plan restriction (that article covers Business, Enterprise and Edu; its unified Google Drive actions are on by default on Business). Apps are enabled by default on Business.
Enterprise and Edu: new plugins and apps are “In general” disabled by default, but “New Enterprise and Edu workspaces start with a selected set of apps enabled”. Those defaults do not apply to Healthcare workspaces or change existing workspace settings (help 11509118).
Do not assume an Enterprise or Edu workspace starts with no apps enabled. Open Admin console > Plugins, find which apps are already enabled, and apply the baseline above to each one or disable it.
Pro: the owner sets Settings > Plugins > Permissions. Help 20001495 scopes that selector to “an eligible personal account”, says managed-workspace members “may instead see approval prompts governed by workspace policy”, and notes “Always allow is not offered as a persistent permission to managed-workspace members”.

Proactive research: it “uses restricted tools to read connected apps; it cannot send messages, change content, or control a browser or computer” (dots admin guide). That restriction is OpenAI’s, not one a customer can verify or configure.

Source-system side: the SCuBA consent policies in Entra ID and Google Workspace limit which third-party apps users may authorize in the first place (see Compliance Mappings). For Microsoft apps, some actions “require Microsoft Graph permissions that a Microsoft Entra administrator must grant for the organization” (help 11509118), so an ungranted permission keeps the dependent action unavailable.

Doc conflict — where Agent Security apps/plugins requirements apply.

Global orchestrator controls: Agent Security and the Config reference list apps, mcp_servers and plugins as Global orchestrator controls configured through TOML. They say “For Work with local access and dots, supported Global policy applies through the shared cloud orchestrator when managed policy is enabled”.

Local executors only: Plugin controls says “Agent Security’s enterprise apps and plugins requirements apply to local executors”, and Managed configuration’s precedence table says enterprise requirements “Apply to local executors”.

The dots admin guide routes app access only to Plugin controls.

Verify in a live tenant whether a Global apps requirement binds a cloud-only dot (8.1 row l).

Rationale

Why This Matters:

Action control and App permissions are the ChatGPT-side layer between an injected dot and write actions in connected systems. Their Read-only Actions setting and Always ask are what make that layer firm (Allow low-risk actions auto-approves by risk class).
Source-system authorization (OAuth scopes, Entra admin consent for Microsoft Graph permissions, and the SCuBA consent policies below) is the other layer. Where managed policy is enabled, Agent Security apps requirements may add a third (see the doc conflict above).
Dots act through personal connections, so a dot’s reach equals its owner’s reach in every connected app.
Proactive research is tool-restricted, but whatever it reads persists in dot memory and survives disconnection.

Attack Prevented: Prompt-injection-driven exfiltration or writes through connected apps (send email, post, edit, invite external attendees).

Real-World Incidents:

Zenity Labs AgentForger (2026-07-23): a CSRF in the Workspace Agents builder let injected instructions switch already-authorized connectors (Outlook) to “Never ask”. Zenity reports OpenAI fixed it on 2026-06-08. A sibling product, not dots.
Check Point Research, “Shared Clipboard” (2026-09-08): reads from a connected Gmail ran without approval under the “Important actions” App permission, and data leaked across accounts. Check Point attributes that label to OpenAI’s docs; learn.chatgpt.com still lists it but the current Help Center does not, so re-verify in your console.
Zenity Labs AgentFlayer (2025-08-06): a poisoned document that the victim gave to ChatGPT made it search the victim’s connected Google Drive for API keys and exfiltrate them through an image URL. Zenity calls it zero-click. A connectors analog, not dots.

Prerequisites

Role-specific app access requires Enterprise or Edu. Business admins set workspace-wide app availability and, where the app or workspace supports them, Actions, New actions and the workspace Plugin permissions default (help 11509118)

ClickOps Implementation

Step 1: Apply the baseline to each app

Navigate to: Admin console (https://chatgpt.com/admin/plugins) > select the ChatGPT workspace > Plugins > {plugin} > Apps section > {included app}
Actions: enable only Read actions
New actions: Only enable new read actions (or Disable new actions)
Permissions: Always ask for apps holding sensitive data or write actions (Allow read actions only for low-sensitivity apps)
Apps with no Actions or New actions control: “Some apps do not offer configurable Actions or New actions controls. For those apps, admins can manage app access but cannot individually configure unavailable action controls” (help 11509118), so the read-only baseline cannot be applied. Either take the app away from dot users or keep it as a recorded exception:
- Take it away: on Enterprise and Edu, remove it from the roles dot users hold (the included app’s role access, or Workspace settings > Permissions & roles > Custom roles > {role} > Plugins & connected data > Select). On Business, the only option is to disable it for the whole workspace. Role and workspace access also applies to the same members’ ChatGPT, ChatGPT Work and Codex use
- Keep it as an exception: set its Permissions to Always ask where it has a per-app setting (“when supported”); otherwise the Step 3 default applies. Always ask is an approval prompt, not a read-only limit: ChatGPT “asks before reading app information or making changes”, and permissions “do not override action controls”

Step 2: If Plugins is unavailable, use the retained Apps page

Navigate to: Manage Legacy Apps within Plugins, or Workspace apps at https://chatgpt.com/admin/ca
Open each connection and set Action control and App permissions to the same baseline

Step 3: Set the workspace-wide default and role access

Navigate to: Workspace settings > General > Settings > Plugin permissions
Enterprise and Edu only: Workspace settings > Permissions & roles > Custom roles > {role} > Plugins & connected data

Step 4: Pro accounts (the owner does this)

Navigate to: Settings > Plugins > Permissions and select Always ask (Allow read actions only if no connected app holds sensitive data)
For each connected account: Settings > Plugins (or Apps) > {plugin} > Connected accounts > ••• > Settings > Permissions

Code Implementation

Code Pack: API Script

hth-chatgpt-dots-2.01-inventory-workspace-plugins.sh View source on GitHub ↗

PLUGINS="${CGPT_TMPDIR}/plugins.jsonl"
cgpt_paginate_cursor "/compliance/workspaces/${CHATGPT_WORKSPACE_ID}/plugins" "${PLUGINS}"
TOTAL="$(wc -l < "${PLUGINS}" | tr -d ' ')"
echo "=== Live workspace-scoped plugins: ${TOTAL} (global catalog and user plugins excluded — TRAP 2) ==="
jq -r '"  \(.id)  \(.current_release.display_name // .name // "(unnamed)") v\(.current_release.version // "?")"
       + "  discoverability=\(.discoverability // "?")  status=\(.status // "?")"
       + "  installation_policy=\(.installation_policy // "?")  authentication_policy=\(.authentication_policy // "?")"
       + "  marketplace=\(.marketplace_name // "-")  creator=\(.creator_account_user_id // "-")"' "${PLUGINS}"

# Who can reach each plugin. A `workspace` principal means every member — and so
# every member's dot — can use it.
if [ "${DETAIL}" -eq 1 ]; then
  echo ""
  echo "=== Share principals ==="
  while IFS= read -r PID; do
    [ -n "${PID}" ] || continue
    cgpt_safe_id "${PID}" "plugin ID"
    cgpt_get_ok "/compliance/workspaces/${CHATGPT_WORKSPACE_ID}/plugins/${PID}"
    jq -r '"  \(.id): " + ([(.share_principals // [])[]
             | "\(.principal_type):\(.name // .principal_id)(\(.role))"] | if length == 0 then "(none listed)" else join(", ") end)
           + (if any((.share_principals // [])[]; .principal_type == "workspace")
              then "   <- REVIEW: shared with the whole workspace" else "" end)' "${CGPT_BODY}"
  done < <(jq -r '.id' "${PLUGINS}")
fi

UNAPPROVED=0
if [ "$(jq 'length' <<<"${APPROVED_JSON}")" -gt 0 ]; then
  echo ""
  echo "=== Drift against HTH_PLUGINS_APPROVED ==="
  while IFS=$'\t' read -r PID PNAME; do
    echo "  FINDING: plugin ${PID} (${PNAME}) is live in the workspace but not approved"
    UNAPPROVED=$((UNAPPROVED + 1))
  done < <(jq -r --argjson ok "${APPROVED_JSON}" '
      . as $p | select(($ok | any(.[]; . == $p.id)) | not)
      | [.id, (.current_release.display_name // .name // "(unnamed)")] | @tsv' "${PLUGINS}")
  [ "${UNAPPROVED}" -gt 0 ] || echo "  every live WORKSPACE-SCOPED plugin is approved (public catalog and user plugins not checked — TRAP 2)"
fi

echo ""
echo "NEXT (console — TRAP 1, TRAP 2): walk every plugin above AND every enabled public plugin. This API cannot list"
echo "  Admin > Plugins > Public (OpenAI-built Gmail, Google Drive, Outlook among them). For each app, open"
echo "  Admin > Plugins > {plugin} > Apps > {app}, or Workspace apps at https://chatgpt.com/admin/ca:"
echo "  Actions: enable only Read actions | New actions: Only enable new read actions or Disable new actions |"
echo "  Permissions: Always ask for apps holding sensitive data; Allow read actions only for low-sensitivity apps (TRAP 6)"
[ "${UNAPPROVED}" -eq 0 ] || exit 1
exit 0

Code Pack: Sigma Detection Rule

hth-chatgpt-dots-2.01-app-action-control-widened.yml View source on GitHub ↗

logsource:
    product: openai
    service: chatgpt-compliance
    definition: 'ChatGPT Compliance Logs Platform JSONL records with type AUDIT_LOG; nested keys flattened with dots (action_data.enabled_actions_added)'
detection:
    selection_event:
        type: 'AUDIT_LOG'
        action: 'APP_SET_ENABLED_ACTIONS'
        action_result: 'SUCCESS'
    selection_added:
        action_data.enabled_actions_added: '*'
    selection_unrestricted:
        action_data.enabled_actions: null
    selection_clamp_removed:
        action_data.previous_action_clamp_present: true
        action_data.new_action_clamp_present: false
    condition: selection_event and (selection_added or selection_unrestricted or selection_clamp_removed)
fields:
    - timestamp
    - event_id
    - actor.user_email
    - action_result
    - action_privilege
    - action_data.app_id
    - action_data.action_controls_edited
    - action_data.action_controls_source
    - action_data.enabled_actions_before
    - action_data.enabled_actions
    - action_data.enabled_actions_added
    - action_data.action_policy_before
    - action_data.action_policy
    - action_data.action_name
    - action_data.affected_connector_ids
    - action_data.changed_fields

The API pack:

What it inventories: every live workspace-scoped plugin, including private and unlisted ones (GET /compliance/workspaces/{workspace_id}/plugins, chatgpt.enterprise.compliance_export read scope, Enterprise and Edu).
What it misses: that is only half the set to walk. The API excludes the public catalog, including OpenAI-built plugins such as Gmail and Google Drive, and user-scoped plugins, so the console walk must also cover Admin > Plugins > Public.
No action-control state: the Get endpoint states “user-specific effective policy overrides are not exposed”.

The Sigma rule:

What fires it: a successful AUDIT_LOG APP_SET_ENABLED_ACTIONS with a non-empty enabled_actions_added (any added action, read or write, since the spec carries no read/write flag), a null enabled_actions (null means unrestricted) or a removed parameter clamp (previous_action_clamp_present true, new_action_clamp_present false).
What does not: it does not key on action_policy / action_policy_before, whose values the spec does not enumerate, so a New actions change that enables no current action does not fire it.
App permissions: no documented audit field is identified as App permissions. APP_SET_ENABLED_ACTIONS action_policy and its workspace_permissions snapshots may carry it, unverified until a live tenant shows the values.

Agent Security requirements: Global requirements.toml also carries an apps table. It is a separate layer from Action control and App permissions, and it does not write them.

[apps.<id>] enabled = false disables an app (“A disabled requirement remains restrictive when multiple requirements sources are merged”).

[apps.<id>.tools."<tool>"] approval_mode = "prompt" (values auto prompt writes approve) constrains approval for one tool (Config reference).

At the requirements level there is no _default key (the apps._default.* keys are user-overridable config.toml defaults), so each tool must be named. No doc lists the app ids or tool names of ChatGPT connectors.
The mcp_servers and plugins requirements are allowlists of MCP servers a client may enable, not connector controls.
Treat apps as a complementary L2 lever beside Plugin controls, never a replacement, and live-test it (see the doc conflict above and 8.4). “Support for a requirements.toml field does not by itself establish API compatibility”, so applying it is a paste into Agent Security.

Automation: ClickOps only — OpenAI exposes no write interface for Action control or App permissions (Admin API reference, 2026-10-09).

Validation & Testing

Confirm the baseline per app in the console, including every enabled app under Admin > Plugins > Public: Actions read-only, New actions restricted, Permissions Always ask (or Allow read actions for low-sensitivity apps)
- For each app with no Actions control, confirm it is either removed from dot users’ roles (or disabled workspace-wide on Business) or set to Always ask and listed in the exception register
- Neither the 2.1 inventory nor the Admin > Plugins > Public > Export CSV carries action-control state. The CSV is also an Enterprise-only public-catalog snapshot up to 48 hours old that excludes workspace-created plugins (Plugin controls)
As a pilot member, ask the dot to send an email through a read-only Gmail connection and confirm the action is unavailable
In a test app, enable a write action and confirm the 2.1 Sigma rule fires
Re-check the New actions setting and every app’s Permissions in the console after each change; neither has an audit field the rules key on
Set [apps.<test-app>] enabled = false in the Global requirements, then confirm a cloud-only dot can no longer use that app. Record the result as evidence or as a gap

Expected result: Every app a dot user holds is read-only by default.

Exceptions: apps with no action controls. Each one is either removed from dot users’ access or gated by Always ask and listed in an exception register.
Alerts (Enterprise and Edu): the 2.1 rule alerts when an action is enabled, an app becomes unrestricted or a clamp is removed, and the 6.2 rules alert on app availability and role-access grants.
Console re-checks: a New actions change and an App permissions change have no audit field the rules key on, so they are re-checked in the console.
Business and Pro have no audit feed.

Compliance Mappings

Framework	Control ID	Control Description
CIS Controls v8	3.3	Configure Data Access Control Lists
CIS Controls v8	2.5	Allowlist Authorized Software
NIST 800-53	AC-3	Access Enforcement
NIST 800-53	AC-6	Least Privilege
NIST 800-53	CM-7	Least Functionality
SOC 2	CC6.1, CC6.6	Logical access security; protection against threats from outside system boundaries
CISA SCuBA	MS.AAD.5.2v1	User consent to applications SHALL be restricted (source system: Entra ID)
CISA SCuBA	MS.AAD.5.3v1	An admin consent workflow SHALL be configured for applications
CISA SCuBA	GWS.COMMONCONTROLS.10.1v1, 10.2v1, 10.4v1	Restrict third-party application access to GWS services; no user consent to low-risk scopes; no access to unconfigured third-party applications (source system: Google Workspace)
Benchmark	None	No benchmark equivalent yet (the SCuBA rows are source-system policies, not a ChatGPT benchmark)

2.2 Restrict Add dots to Slack and Microsoft Teams to a narrow role and keep Slack-side app approval on

Profile Level: L2 (Walk)

Framework	Control
CIS Controls v8	6.8, 3.3
NIST 800-53	AC-3, AC-4, AC-21

Description

Keep Add dots to Slack and Microsoft Teams Off in the workspace default and grant it only through one narrow custom role. Keep Slack’s own app approval on, so a Slack owner or app manager still gates the installation.

What the permission does: it “Allows a dot to join supported Slack or Microsoft Teams workspaces and post with its own identity, where available” (Manage dots in ChatGPT workspaces). That brings other people’s messages into an agent that holds its owner’s private data. Teams is “limited to an invite-only alpha” (dots admin guide).

What it takes to connect:

“For Slack, both Use dots (Beta) and Add dots to Slack and Microsoft Teams must be enabled for the member.”
Turning the permission on “does not install a Slack app or connect a member’s dot”.
“If the Slack workspace requires app approval, a Slack workspace owner or app manager must approve the installation and permissions”, and each member then connects from the dot’s profile (help 20001554).
Slack creates app requests only when app approval is turned on. By default only Workspace Owners review them, and app managers can once appointed (Slack: Manage app requests).
The dots guide says to “Ensure the ChatGPT app is installed in Slack”. If the ChatGPT app is already installed, for example for @ChatGPT (@ChatGPT in Slack), no new request may appear, so review the existing installation and its approved scopes.

Who directs the dot:

Only the owner can direct the dot; others’ messages or mentions do not start work.
When the owner brings it into a thread, the dot “may use other participants’ messages as context”, and “Anyone with conversation access can see its posts” (dots admin guide).
By default a dot responds to its owner, and the owner can instruct it to engage with others (Channels).

Doc conflict — permission label. The Help Center calls it Add dots to Slack and Microsoft Teams; learn.chatgpt.com calls it Add dots to Slack. Use whichever your console shows. OpenAI states no default for this permission: help 20001554 marks only Use dots, local access and custom rules “Off by default for Enterprise”.

Three separate Slack paths:

The dots Add to Slack connection.
The shared @ChatGPT Slack connection, which is separate from the dots connection (Shared connections; ChatGPT in Slack and Teams).
The ChatGPT Agents app for Workspace Agents, which differs from both.

The Slack plugin is a fourth route: this permission does not govern it either. “Communication with a dot is separate from connecting apps that read or send work content” (dots admin guide). A dot can still read or post Slack through the member’s Slack plugin connection, so pair this control with 2.1.

Phone messaging through iMessage, RCS or WhatsApp is unavailable for Enterprise at launch (help 20001554).

Scope and plans:

Steps 1 and 2 apply only to the Enterprise beta, including Edu and Healthcare. OpenAI documents the Add dots to Slack permission only in its Enterprise admin docs.
Step 3 is a Slack-side control and applies whatever ChatGPT plan the dot’s owner holds. Pro and Business Premium owners can also connect their dot to Slack from its profile (Meet dots; Getting started).
Pro and Business Premium have no documented ChatGPT-side permission, so Slack app approval is the only lever a Slack owner holds for them. Only the Enterprise admin guide names the ChatGPT app; for a Pro or Business Premium dot, which Slack app it installs is undocumented, so review whatever request or installation appears.

Doc conflict — a dot’s own identity. The Dots FAQs say “You can also set up a separate Slack account for your dot, giving it its own identity”, and refer to a dot that “has its own email or Slack account”. Getting started with your dot says “At launch, you cannot give your dot its own standalone email address.” The Slack identity is consistent across sources; only the email part conflicts (8.1 row p).

Rationale

Why This Matters:

Messages from other thread participants become untrusted input to an agent that also holds the owner’s private data and can send — the lethal trifecta.
Context carried across channels can be disclosed to a wider audience, because anyone with conversation access sees the dot’s posts.
When app approval is on, the Slack-side gate is enforced by Slack, independently of the OpenAI toggle.

Attack Prevented: Indirect prompt injection through Slack threads the dot participates in, and leakage of private context into shared channels. The Slack plugin path is covered separately by 2.1.

Prerequisites

Steps 1-2: an Enterprise beta workspace (including Edu and Healthcare); the member also needs Use dots (Beta) (1.1)
Step 3: a Slack Workspace Owner or appointed app manager. This applies to any dot that joins your Slack, including Pro and Business Premium dots

ClickOps Implementation

Step 1: Keep the workspace default Off

Navigate to: Workspace settings > Permissions & roles > Permissions > Workspace default > Workspace capabilities
Set Add dots to Slack and Microsoft Teams (or Add dots to Slack) to Off

Step 2: Grant it through one narrow role

Set the permission to On in one narrow custom role, and to Default or Off in every other custom role
Confirm the members of that role also hold Use dots (Beta), which is in the same section

Step 3: Keep Slack-side app approval on (any ChatGPT plan)

In Slack, turn app approval on rather than assume it is on: Slack creates app requests only “If app approval is turned on for a workspace”, and the feature is “Available on all plans” (Slack: Manage app requests)
A Workspace Owner or app manager uses Review and Approve for Workspace, or approves from the Requests to install tab on the Apps page
If the ChatGPT app is already installed, review the existing installation and its approved scopes

Automation: ClickOps only — OpenAI exposes no write interface for this setting (Admin API reference, 2026-10-08). When the narrow role is assigned to a manually managed group, the 1.1 Code Pack can verify who holds it: point it at this role’s group ID.

Validation & Testing

Confirm the permission is On only in the narrow role. Check the workspace default, every custom role, and direct and group-assigned roles, because grants combine
In Slack, confirm app approval is on and that the ChatGPT app installation and its approved scopes were reviewed
As a non-owner, mention another member’s dot and confirm it does not start work

Expected result: Only the narrow role’s members can bring a dot into Slack, and Slack approval stays an independent gate.

Compliance Mappings

Framework	Control ID	Control Description
CIS Controls v8	6.8	Define and Maintain Role-Based Access Control
CIS Controls v8	3.3	Configure Data Access Control Lists
NIST 800-53	AC-3	Access Enforcement
NIST 800-53	AC-4	Information Flow Enforcement
NIST 800-53	AC-21	Information Sharing
SOC 2	CC6.1	Logical access security
Benchmark	None	No benchmark equivalent yet

3. Cloud Computer, Browser & Local Access

3.1 Re-baseline Cloud browser use and Cloud computer use before enabling dots

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls v8	4.8, 6.8
NIST 800-53	CM-7, AC-6, SC-7

Description

Before enabling dots, set Cloud browser use and Cloud computer use Off in the workspace default. Turn each On only in the pilot role whose use case needs it.

Cloud computer capabilities holds three controls (Manage dots in ChatGPT workspaces):

Cloud browser use: “open and interact with websites using a browser”
Cloud network access (3.2)
Cloud computer use: “interact with the desktop and applications on cloud computers”

Shared with Work Cloud: “These controls apply to both dots and tasks in Work Cloud. They apply to dots even when Work or Work Cloud is disabled.”

“Existing workspace defaults and custom-role settings for browser and network access carry over” (help 20001554), so a workspace that enabled browsing for Work has already granted it to dots, without any dots-specific decision.
No source says Cloud computer use settings carry over.

No stated default: no page states an explicit default for these three toggles. The Browser page says “Enterprise admins must enable cloud browsing for their workspace”, which implies browsing is unavailable until granted. But a workspace that enabled browsing for Work has already granted it to dots.

No dots-only scope: the permissions cannot be scoped to dots.

Setting the workspace default Off also removes cloud browsing and computer use from every member’s Work Cloud tasks.
Turning them On in the dots pilot role grants them to those members’ Work Cloud tasks as well.
Grants combine additively, so review every role.

Outside your monitoring:

A dot’s cloud computer “does not automatically inherit a member’s local VPN, browser sign-ins, or device policies” (help 20001554).
Endpoint monitoring “can’t inspect actions inside the hosted execution environment” (Work Cloud security).

A role setting, not a policy setting: “A Global policy or Codex Cloud override does not configure shared cloud capability permissions” (Agent Security).

Local browser fallback: turning off Cloud browser use does not stop all browsing. With Allow local computer access enabled, a dot can “use your local browser when its cloud browser is blocked” (Getting started with your dot), so keep 3.4 Off.

Rationale

Why This Matters:

The hosted browser is the main channel for untrusted web content into the dot.
Hosted execution is invisible to customer secure web gateways, EDR and browser policy.
Inherited browser and network settings mean the risk arrives without any dots-specific decision.

Attack Prevented: Web-content prompt injection driving actions from an unmonitored hosted browser.

Real-World Incidents:

Radware ShadowLeak (published 2025-09-18; fixed early August 2025): a crafted email made Deep Research browse to an attacker URL from OpenAI’s cloud, invisible to the customer’s secure web gateway and endpoint monitoring. An analog for hosted-browser dots.
Johann Rehberger, ChatGPT Operator prompt injection (2025-02-17): prompt injection in web content hijacked ChatGPT Operator inside logged-in sites. A predecessor product.

ClickOps Implementation

Step 1: Record the current state

Navigate to: Admin Console > Permissions & roles > Workspace capabilities > Cloud computer capabilities. The dots admin guide gives the fuller path: Workspace settings > Permissions & roles > Permissions > Workspace default > Workspace capabilities > Cloud computer capabilities
Screenshot Cloud browser use and Cloud computer use in the workspace default and in every custom role

Step 2: Set the workspace default Off

Set Cloud browser use and Cloud computer use to Off in the workspace default (this also removes them from Work Cloud tasks)

Step 3: Grant only what the pilot needs

In the dots pilot role, turn Cloud browser use On only if the use case needs website interaction, and Cloud computer use On only if it needs desktop and app interaction on the cloud computer
Confirm no other role a dots user holds sets either capability On
Keep Allow local computer access Off (3.4)

Automation: ClickOps only — OpenAI exposes no write interface for this setting (Admin API reference, 2026-10-09).

Changes can be detected, not prevented. The 6.2 Sigma rules alert on two AUDIT_LOG actions:

ROLE_UPDATE (“Workspace admin updated a role”: permissions_added / permissions_removed)
WORKSPACE_TOGGLE_FEATURE (“Enabled or disabled a workspace feature flag”: feature, value)

The spec does not say which of the two, if either, records a change to the Workspace default for Cloud browser use or Cloud computer use, and the capability identifiers are undocumented. Its only WORKSPACE_TOGGLE_FEATURE example is canvas_code_network_access.

Validation & Testing

Compare before-and-after screenshots of both toggles in the workspace default and every role
Test with a member who has Use dots (Beta), no Cloud browser use grant from the default or any assigned role, and Allow local computer access Off. Ask the dot to open a website and confirm it is refused

Expected result: Dots can browse or use the cloud desktop only where a pilot role deliberately grants it.

Compliance Mappings

Framework	Control ID	Control Description
CIS Controls v8	4.8	Uninstall or Disable Unnecessary Services on Enterprise Assets and Software
CIS Controls v8	6.8	Define and Maintain Role-Based Access Control
NIST 800-53	CM-7	Least Functionality
NIST 800-53	AC-6	Least Privilege
NIST 800-53	SC-7	Boundary Protection
SOC 2	CC6.1, CC6.6	Logical access security; protection against threats from outside system boundaries
Benchmark	None	No benchmark equivalent yet

3.2 Turn off Cloud network access for dots

Profile Level: L2 (Walk)

Framework	Control
CIS Controls v8	13.4, 4.8
NIST 800-53	SC-7, SC-7(5), AC-4

Description

Set Cloud network access Off in the workspace default, and make sure no role a dots user holds sets it On, unless code or shell internet access is genuinely required.

What it controls: Cloud network access “Allows code and shell commands run by dots and Work Cloud tasks on cloud computers to access the internet” (Manage dots in ChatGPT workspaces). It is independent of Cloud browser use: “Disabling one does not automatically disable the other” (Work Cloud security).

How it applies:

“Local execution restrictions do not automatically apply to these cloud computers”; Work Cloud containers and dots cloud computers “use their own execution configuration and requirements” (Work Cloud security).
Changes “apply after the current code run or shell command finishes and the execution environment refreshes”.
The setting is shared with Work Cloud and carries over from existing settings (help 20001554). Turning the workspace default Off also cuts Work Cloud network access, and because grants combine, no assigned role may set it On.

Off is not zero egress: “When public internet access is off, network destinations required for ChatGPT Work can remain reachable through a managed destination allowlist” that OpenAI manages. No admin-configurable destination allowlist is documented for dots cloud computers.

Other network paths: this switch governs only the dot’s own cloud computer.

Codex cloud tasks: a dot can “create cloud tasks in Codex cloud environments” (Getting started with your dot). Those tasks follow the Codex cloud environment’s internet access settings and the Agent Security Codex Cloud networking requirements (Manage Networking, Allow/Deny domains, “Only allow domains added by admins”) (Agent Security), not this switch.
Work network access: a member-level Settings > Data controls > Work network access > Allow public internet access exists for ChatGPT Work code and shell (Sandboxing). Whether it applies to dots is undocumented.

Rationale

Why This Matters:

Code execution with outbound network access is the classic exfiltration path, even when browsing is restricted.
Admins can configure no destination allowlist for dots cloud computers, so Off is the only safe default, and even Off leaves OpenAI’s managed allowlist reachable.

Attack Prevented: Data exfiltration and remote-shell channels from code that the dot runs on its cloud computer.

Real-World Incidents:

Check Point Research, hidden outbound channel in ChatGPT’s code-execution runtime (published 2026-03-30): a hidden DNS side channel leaked chat content and enabled a remote shell even though conventional outbound internet access was blocked. Check Point reports the fix was fully deployed on 2026-02-20. An analog, not a dots incident.

ClickOps Implementation

Step 1: Turn off network access in the workspace default

Navigate to: Admin Console > Permissions & roles > Workspace capabilities > Cloud computer capabilities (dots admin guide path: Workspace settings > Permissions & roles > Permissions > Workspace default > Workspace capabilities > Cloud computer capabilities)
Set Cloud network access to Off in the workspace default

Step 2: Check every role

Confirm Cloud network access is not On in any custom role assigned to dots users, directly or through a group, unless code or shell internet access is required

Step 3: Close the Codex cloud path

Review each Codex cloud environment’s internet access settings, because a dot can create tasks there. Reviewing existing environments does not close the path on its own: “Members with Cloud access can create and edit their own personal environments without the management permission” (Roles and workspace permissions)
Then do one of two things: remove Use Codex in the cloud from the dots population’s roles, or, in Agent Security’s Codex Cloud requirements, turn on Manage Networking with Only allow domains added by admins (Agent Security)
To make the review repeatable on Enterprise, read the environments with the Admin API’s read-only List Codex Environments, List Shared Codex Environment Configurations and per-user List Private Codex Environment Configurations routes (Admin API reference)

Automation: ClickOps only — OpenAI exposes no write interface for this setting (Admin API reference, 2026-10-09). Agent Security configures Codex cloud environments, not dots cloud computers. Changes to the toggle are detectable only after the fact, through the 6.2 audit rules.

Validation & Testing

After the execution environment refreshes, ask the dot (as a pilot member with network access Off) to run a shell command on its cloud computer that fetches an arbitrary non-OpenAI host
Confirm that the shell fetch specifically fails. Cloud browser, web search and apps are independent and may still return the content
Confirm the dot did not route the test into a Codex cloud environment

Expected result: Code the dot runs on its cloud computer cannot reach arbitrary internet hosts.

Compliance Mappings

Framework	Control ID	Control Description
CIS Controls v8	13.4	Perform Traffic Filtering Between Network Segments
CIS Controls v8	4.8	Uninstall or Disable Unnecessary Services on Enterprise Assets and Software
NIST 800-53	SC-7	Boundary Protection
NIST 800-53	SC-7(5)	Deny by Default — Allow by Exception
NIST 800-53	AC-4	Information Flow Enforcement
SOC 2	CC6.6	Protection against threats from outside system boundaries
Benchmark	None	No benchmark equivalent yet

3.3 Keep Use password manager off for dots populations

Profile Level: L2 (Walk)

Framework	Control
NIST 800-53	IA-5, AC-6

Description

Set Use password manager Off in the workspace default, and confirm no custom role assigned to the dots population sets it On. Stored credentials should not sit inside an agent that reads untrusted web content.

What it controls:

Step 5 of the dots admin guide: “Under Workspace capabilities, set Use password manager according to your workspace policy.”
Help 20001554: “Allows members to use the password manager with dots and Work Cloud. This setting is separate from Cloud browser use.”
Work Cloud security: “It governs password-manager access in the local in-app browser and cloud browser.”

Where it sits: directly under Workspace capabilities, outside the Cloud computer capabilities group. It is not dots-specific, so turning it off for a role also affects Work for that role. Under the additive reading of how roles combine (8.1 row f), Off in one role is not a deny.

Save to Passwords (an inference): no OpenAI page explicitly ties this permission to the dots Save to Passwords option (“When offered, Save to Passwords lets you save a login”, Computers and apps). Treat that link as an inference to confirm in a live tenant. “Reusing a saved login to sign in requires your confirmation”, and custom rules cannot remove that confirmation (Controls).

Sessions outlive the setting:

Website sessions persist “until you sign out or the website expires it”, and the dot’s cloud browser keeps its own sessions, independent of the member’s browser.
Turning this permission off does not end existing sessions, and “removing dots access does not replace disconnecting an app or signing out of a website” (dots admin guide).

Passwords shared elsewhere: the secure sign-in form keeps credentials from the model, but “These protections … don’t cover passwords you share separately in a chat or document, or through a plugin” (Dots FAQs). OpenAI’s own advice is “Don’t send passwords in the chat” (Browser).

Doc conflict — website sign-in on Enterprise. The ChatGPT Work Browser page says “Website sign-in isn’t available for Enterprise or Edu workspaces” and “ChatGPT does not store your username or passwords”. Dots use “the same private sign-in flow as ChatGPT Work” and offer Save to Passwords (Computers and apps). Confirm in a live tenant what an Enterprise dot actually offers.

Rationale

Why This Matters:

Stored credentials and persistent authenticated sessions sit inside an agent that ingests untrusted web content.
A session’s lifetime is controlled by each website, not by you, and revoking the permission does not end it.

Attack Prevented: Injection-driven actions inside logged-in sites, and credential reuse from a compromised agent environment.

Real-World Incidents:

Johann Rehberger, ChatGPT Operator prompt injection (2025-02-17): prompt injection inside logged-in sites leaked email, home address and phone number; “just typing text hardly ever triggers any confirmations”. A predecessor product, cited as rationale only.

ClickOps Implementation

Step 1: Turn the permission off by default

Navigate to: Workspace settings > Permissions & roles > Permissions > Workspace default > Workspace capabilities > Use password manager (directly under Workspace capabilities, not inside Cloud computer capabilities)
Set it to Off

Step 2: Check the dots population’s roles

Open each custom role assigned to dots users and confirm Use password manager is not On

Step 3: End existing sessions

Have dot owners sign the cloud browser out of websites they no longer need; turning the permission off does not end sessions

Automation: ClickOps only — OpenAI exposes no write interface for this setting (dots admin guide; Admin API reference, 2026-10-09). The permission’s audit identifier is undocumented, and it is undocumented whether a Workspace default toggle is recorded as ROLE_UPDATE or WORKSPACE_TOGGLE_FEATURE; the 6.2 Sigma rules match both actions.

Validation & Testing

As a pilot member with the permission Off, trigger a website sign-in through the dot and confirm that no Save to Passwords option appears
Record the result as evidence for or against the inferred link between the permission and Save to Passwords

Expected result: Dots populations cannot save website logins through the password manager.

Compliance Mappings

Framework	Control ID	Control Description
NIST 800-53	IA-5	Authenticator Management
NIST 800-53	AC-6	Least Privilege
SOC 2	CC6.1	Logical access security
Benchmark	None	No benchmark equivalent yet

3.4 Keep Allow local computer access off for dots

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls v8	4.8, 2.7
NIST 800-53	CM-7, AC-17, AC-6

Description

Keep Allow local computer access Off in the workspace default and in every custom role. It lets a dot use a member’s local files and run commands on their computer, bridging a cloud agent that reads untrusted content into corporate endpoints.

How it works:

The permission “Allows a dot to use a member’s local files and run commands on their computer … Off by default for Enterprise” (Manage dots in ChatGPT workspaces).
It “requires a separate admin opt-in” (dots admin guide), apart from Work Cloud’s own local-access permission.
When it is on, a member connects one personal computer and confirms Allow access.

What the dot can then do: “create local Work or Codex tasks and continue existing local Codex tasks” (Computers and apps), and use local files and apps. It can also use the local browser “when its cloud browser is blocked” (Getting started with your dot).

Requirements and persistence:

It requires ChatGPT desktop app 26.929 or higher, with the computer online and ChatGPT open.
“The saved access grant remains” while offline: “Offline does not mean access has been revoked.”

Policy and revocation: local execution follows Agent Security local requirements and MDM. “If an admin disables local computer access for dots, an already authorized local task may still be finishing. Do not assume the Work behavior of immediately interrupting running turns applies to dots” (Cloud and local access).

Doc conflict — what blocks local access.

learn.chatgpt.com (cloud-local-access, roles, Work Cloud security, the dots admin FAQ and the Work admin FAQ) says access is unavailable when any cloud policy enables enforce_residency (see 5.1 for its side effects).

Help 20001554 says “Local computer access is unavailable in workspaces with Codex or ChatGPT Work policies that target a specific operating system.”

The admin guide still carries a stale anchor about policies that target an operating system, which suggests learn is newer. Verify which condition applies in a live tenant.

Label note: OpenAI spells the parent permission three ways:

Use dots (Beta) in the dots admin guide’s setup step 2 and in help 20001554

Use dots in the admin guide’s permission list and its Slack checklist

Use Dots on cloud-local-access

This guide uses Use dots (Beta), the spelling both sets of setup steps use. Confirm the label in a live console.

Rationale

Why This Matters:

This bridges a cloud-coordinated agent that ingests untrusted content into command execution on corporate endpoints.
The grant persists across tasks and survives the device going offline.
Disabling the permission may not interrupt an already authorized local task.

Attack Prevented: Injection-driven command execution and file access on employee endpoints.

Real-World Incidents:

BeyondTrust Phantom Labs, “WHAM, Bam, Thank You OpenAI for the C2 Infrastructure” (2026-07-28): the Codex remote-control relay at chatgpt.com/backend-api/wham/remote/control was usable as command-and-control. An analog; whether dots use that relay is undocumented.

ClickOps Implementation

Step 1: Keep the permission off

Navigate to: Workspace settings > Permissions & roles > Permissions > Workspace default > Workspace capabilities > Use dots (Beta) > Allow local computer access
Confirm it is Off

Step 2: Check every custom role

Confirm Allow local computer access is Off, or Default inheriting Off, in every custom role, because role grants are additive

Step 3: If it is ever enabled

Read the confirmation modal before enabling
Configure Admin Console > Agent Security first: the Global baseline and any Local overrides govern execution on the connected computer
Remember that disabling it later may not stop a local task that is already authorized; the owner can remove a grant at dot profile > Computers > Your computer > Revoke access

Automation: ClickOps only — OpenAI exposes no write interface for this setting (Admin API reference, 2026-10-09).

Blocking lever: learn.chatgpt.com documents enforce_residency in an Agent Security cloud policy as the blocking lever, which makes local access unavailable for both Work and dots across the whole workspace. Help 20001554 instead names policies that target a specific operating system (see the conflict above).
Side effects: enforce_residency has side effects and is emitted by the 5.1 Code Pack, not applied by it.
Detection: changes to the permission are detectable only after the fact, through the 6.2 audit rules.

Validation & Testing

Confirm Allow local computer access is Off under Use dots (Beta) in the workspace default and in every custom role
As a pilot member on desktop app 26.929 or later, open dot profile > Computers and confirm Allow access is unavailable

Expected result: No dot can connect to or run commands on a member’s computer.

Compliance Mappings

Framework	Control ID	Control Description
CIS Controls v8	4.8	Uninstall or Disable Unnecessary Services on Enterprise Assets and Software
CIS Controls v8	2.7	Allowlist Authorized Scripts
NIST 800-53	CM-7	Least Functionality
NIST 800-53	AC-17	Remote Access
NIST 800-53	AC-6	Least Privilege
SOC 2	CC6.1, CC6.8	Logical access security; prevention or detection of unauthorized or malicious software
Benchmark	None	No benchmark equivalent yet

4. Autonomy & Approvals

4.1 Keep Use custom rules for dots off outside a narrow role

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls v8	4.1, 6.8
NIST 800-53	AC-6, CM-6

Description

Keep Use custom rules for dots Off in the workspace default and turn it On only in a narrow custom role. Rules can remove approval for an action, so that choice should be a workspace decision for a known group.

What it allows: help 20001554 describes it as “Use custom rules for dots — Allows members to add or edit rules that guide their dot’s actions and confirmations. Off by default for Enterprise” (Manage dots in ChatGPT workspaces).

A “Take action without asking” rule removes approval for the named action.
Rules are “instructions your dot tries to follow, and it can make mistakes” (Controls).

When it is off:

“When disabled, members cannot add or edit rules, and saved rules do not apply” (dots admin guide).
“Default action rules still apply when custom rules are unavailable. Custom rules cannot override built-in safeguards, and disabling custom rules does not make every action require approval” (help 20001554).

What rules cannot change:

“Custom rules cannot turn off core safety requirements, such as when your dot asks you to take back over to change a password”, and “Custom rules also cannot change the separate safety review system, Autoreview, or the restrictions on proactive research” (Dots FAQs).
They cannot “remove required confirmations such as approval to use a saved login” (Controls).

Undocumented: a separate FAQ answer lists transferring money among “The most sensitive actions” that “require you to take over”. It does not say whether custom rules can change that.

Doc conflict — rule label. The third rule option is “Take action when you say so” on learn.chatgpt.com and “Take action if pre-approved” in Getting started with your dot.

Console note: the vendor groups the dots permissions under Use dots (Beta) (“Find Use dots (Beta), then review the dots permissions”). Allow local computer access is documented as nested there; the same nesting for custom rules is an inference.

Scope and plans: the admin docs apply to “eligible ChatGPT Enterprise workspaces during the dots beta” (Enterprise including Edu and Healthcare).

Custom roles exist only on Enterprise, Edu, Healthcare and Teachers (RBAC in ChatGPT), so the narrow-role recommendation does not apply to Business Premium, where no equivalent permission is documented.
Owner-level rule choices are covered in 4.4.

Rationale

Why This Matters:

The GPT-6 Astra system card’s dots appendix (a first-party evaluation) found that successful attacks “typically needed significant setup and either highly permissive prompts or advanced techniques across multiple surfaces”, and that confirmation-policy updates mitigated issues “including scenarios where a dot was instructed never to ask permission”. A standing “Take action without asking” rule is analogous to such a permissive instruction; that link is this guide’s analogy, not the card’s.
Approval-lowering configuration should be a workspace decision for a known group, not a per-member default.

Attack Prevented: Approval bypass through standing permissive rules.

Real-World Incidents:

Zenity Labs AgentForger (2026-07-23): injected instructions disabled the approval mechanism they were meant to pass through, in the Workspace Agents builder. A sibling product, fixed 2026-06-08 per Zenity.

ClickOps Implementation

Step 1: Keep the workspace default Off

Navigate to: Workspace settings > Permissions & roles > Permissions > Workspace default > Workspace capabilities > Use dots (Beta) > Use custom rules for dots
Confirm it is Off (the Enterprise default)

Step 2: Grant it only through a narrow role

Turn Use custom rules for dots On only in a narrow custom role
Confirm every other custom role leaves it Default or Off, and that no direct role assignment grants it

Automation: ClickOps only — OpenAI exposes no write interface for this setting (Admin API reference, 2026-10-08).

Verification: when the narrow role is assigned to a manually managed group, the 1.1 Code Pack can verify who holds it. That is a verification surface, not a write handle.
Detection: changes to the role that grants the permission are detectable through the 6.2 Sigma rules (ROLE_UPDATE, ROLE_ASSIGN and related AUDIT_LOG actions) and the 6.2 API and CLI packs (tenant.custom_role.*, tenant.role_assignment.*). The permission’s identifier string is undocumented until a live toggle records it.
Not to be confused: the requirements.toml rules field governs which commands an agent can run, not dots custom rules.

Validation & Testing

Use a test member who holds Use dots (Beta) but not the narrow role, checking every direct and group-assigned role
Open Settings > Personalization > Custom rules (under Permissions); on mobile, Customize > Custom rules
Confirm that rules cannot be added and that saved rules are inactive

Expected result: Only the narrow role’s members can create rules that change their dot’s confirmations.

Compliance Mappings

Framework	Control ID	Control Description
CIS Controls v8	4.1	Establish and Maintain a Secure Configuration Process
CIS Controls v8	6.8	Define and Maintain Role-Based Access Control
NIST 800-53	AC-6	Least Privilege (approval-lowering rules limited to a narrow role)
NIST 800-53	CM-6	Configuration Settings
SOC 2	CC6.1, CC8.1	Logical access security; change management
OWASP Top 10 for Agentic Applications 2026	ASI01, ASI03	Agent Goal Hijack; Identity and Privilege Abuse
Benchmark	None	No benchmark equivalent yet

4.2 Enforce orchestrator approval and web-search limits in the Agent Security Global baseline

Profile Level: L2 (Walk)

Framework	Control
CIS Controls v8	4.1
NIST 800-53	CM-6, CM-7, AC-4

Description

In the Agent Security Global baseline, remove never from the allowed approval policies and limit web search to the least mode the use case needs. Then live-test whether these requirements bind a cloud-only dot before relying on them.

Why Global: it is the only Agent Security layer whose approval and web-search requirements reach the shared cloud orchestrator that coordinates dots, when managed policy is enabled.

“For Work with local access and dots, supported Global policy applies through the shared cloud orchestrator when managed policy is enabled”, and environment overrides “cannot” override orchestrator settings (Agent Security).
The cloud-local-access page says the coordinating service enforces supported Global requirements “such as approval requirements and allowed web-search modes”.

The fields (Config reference):

allowed_approval_policies: documented values include on-request, never and granular. Remove never. “Include untrusted to permit the stricter policy derived from an untrusted project; it cannot be selected directly with approval_policy.”
allowed_web_search_modes (disabled, cached, indexed, live): limit to the least the use case needs. “disabled is always allowed; an empty list effectively allows only disabled”. Cached mode lowers but does not remove prompt-injection risk (Web search; Agent approvals and security).
guardian_policy_config: a tenant guardian policy, which “takes precedence over local [auto_review].policy”. Set it only if automatic review is allowed and you hold the complete current reviewer policy, and build it from that policy, because it replaces rather than adds to the reviewer policy: “Both [auto_review].policy and guardian_policy_config replace your current reviewer policy. They don’t merge … copy the complete current policy, keep every existing rule … If you can’t access the current policy, don’t override it” (Auto-review).
- The Managed configuration example is not a complete policy. Pasting it alone would drop every default Data Exfiltration, Credential Probing, Persistent Security Weakening and Destructive Actions rule.
- The open-source default lives at codex-rs/prompts/templates/guardian/policy.md in openai/codex (the vendor’s link to codex-rs/core/src/guardian/policy.md returns 404 on main as of 2026-10-09). No doc says whether a dot’s Auto-review uses that public default.
allowed_approvals_reviewers: accepts user and auto_review.

Applicability caveat. These fields do NOT configure dots’ cloud computers or the cloud-capability permissions. The approval values are Codex vocabulary.

Dots’ own review: the dots admin guide calls a dot’s action review Auto-review, which “checks it against your instructions, permissions, custom rules, and built-in safety requirements” (Controls), alongside Plugin controls (2.1) and the custom-rules permission (4.1).

The one documented tie: the Dots FAQs say “For information about customizing the Auto-review policy, see Auto-review configuration”, which links to the Auto-review page, where “Enterprises can replace its tenant-specific section with guardian_policy_config in managed requirements”. The Config reference also lists guardian_policy_config among the TOML-configured orchestrator requirements for “Work with local access and dots”. That makes it the one Agent Security field with a documented tie to a dot’s Auto-review.

Still undocumented: whether it binds a cloud-only dot. “Your dot cannot turn off required Auto-review checks” (Dots FAQs).

Test with a representative cloud-only dot before relying on these fields.

Rationale

Why This Matters:

Global is the only Agent Security layer whose approval and web-search requirements reach the shared cloud orchestrator that coordinates dots. Per-action confirmations are governed separately, by action review, Plugin controls and the custom-rules permission.
Auto-review “is not a deterministic security guarantee” (Auto-review).
Live web search is a documented injection vector; cached mode only reduces exposure.

Attack Prevented: Unapproved consequential actions, and injection through live web results.

Real-World Incidents:

Tenable Research, HackedGPT (2025-11-05): seven ChatGPT vulnerabilities and attack techniques, including a zero-click indirect prompt injection through search-indexed sites. A ChatGPT analog, not dots.

Prerequisites

ChatGPT Enterprise with managed policy enabled
A representative cloud-only test dot for the applicability test

ClickOps Implementation

Step 1: Set the two fields that have UI controls

Navigate to: Admin Console > Agent Security > (select a policy) > Global > Requirements
Allowed approval policies: remove never
Allowed web search modes: keep only the modes the use case needs (disabled is always allowed)

Step 2: Set the remaining fields through TOML

In the same Global Requirements, configure allowed_approvals_reviewers “through TOML” (the vendor names no TOML editor label); the 4.2 pack emits ["user"] by default
Only if auto_review stays an allowed reviewer: build guardian_policy_config from the complete current reviewer policy plus your tenant rules. The Managed configuration example alone is not a complete policy, and if you cannot see the policy in force, do not override it
auto_review and rules are also TOML fields; this control sets no value for them (rules governs which commands an agent can run, not dots custom rules)
Save, then run the applicability test under Validation & Testing

Code Implementation

Code Pack: Config

hth-chatgpt-dots-4.02-orchestrator-requirements.sh View source on GitHub ↗

# Print the Global requirements for Agent Security. Override the defaults with
# comma-separated lists; `never` and `live` are refused outright.
#   HTH_APPROVAL_POLICIES    default "on-request"  (allowed: on-request, granular, untrusted)
#   HTH_WEB_SEARCH_MODES     default "cached"      (allowed: disabled, cached, indexed; "" = disabled only)
#   HTH_APPROVALS_REVIEWERS  default "user"        (allowed: user, auto_review)
#   HTH_GUARDIAN_POLICY_FILE the COMPLETE reviewer policy plus tenant rules (it
#                            replaces the default; see TRAP 6). Required when
#                            auto_review is allowed; emitted whenever it is set.
toml_array() {   # toml_array "<comma list>" "<allowed values, space separated>"
  # Split with parameter expansion, not a here-string: a here-string that cannot
  # create its temp file makes `read` fail silently and would emit [] (fail open).
  local item out="" rest="$1" seen=0
  while :; do
    case "$rest" in
      *,*) item="${rest%%,*}"; rest="${rest#*,}" ;;
      *)   item="$rest"; rest="" ;;
    esac
    item=$(printf '%s' "$item" | tr -d '[:space:]')
    if [ -n "$item" ]; then
      seen=1
      case " $2 " in
        *" $item "*) out="${out:+$out, }\"$item\"" ;;
        *) echo "ERROR: '$item' is not allowed here (allowed: $2)" >&2; return 2 ;;
      esac
    fi
    [ -n "$rest" ] || break
  done
  # A non-blank input that yielded nothing is a parsing failure, never "[]".
  if [ "$seen" = 0 ] && [ -n "$(printf '%s' "$1" | tr -d '[:space:],')" ]; then
    echo "ERROR: could not parse '$1'" >&2; return 2
  fi
  printf '[%s]' "$out"
}

if [ "$ACTION" = "emit" ]; then
  approvals=$(toml_array "${HTH_APPROVAL_POLICIES:-on-request}" "on-request granular untrusted") || exit 2
  search=$(toml_array "${HTH_WEB_SEARCH_MODES-cached}" "disabled cached indexed") || exit 2
  reviewers=$(toml_array "${HTH_APPROVALS_REVIEWERS:-user}" "user auto_review") || exit 2

  printf 'allowed_approval_policies = %s\n' "$approvals"
  printf 'allowed_web_search_modes = %s\n' "$search"
  printf 'allowed_approvals_reviewers = %s\n' "$reviewers"

  POLICY="${HTH_GUARDIAN_POLICY_FILE:-}"
  case "$reviewers" in
    *'"auto_review"'*)
      [ -n "$POLICY" ] || {
        echo "ERROR: auto_review is allowed, so set HTH_GUARDIAN_POLICY_FILE to the COMPLETE current reviewer policy plus your rules (TRAP 6)" >&2; exit 2; } ;;
    *)
      [ -n "$POLICY" ] || echo "NOTE: guardian_policy_config not emitted; a dot's Auto-review keeps OpenAI's built-in policy. Set HTH_GUARDIAN_POLICY_FILE only to a complete copy of the current policy (TRAP 6)." >&2 ;;
  esac
  if [ -n "$POLICY" ]; then
    [ -r "$POLICY" ] || { echo "ERROR: HTH_GUARDIAN_POLICY_FILE '$POLICY' is not readable" >&2; exit 2; }
    grep -q '[^[:space:]]' "$POLICY" || { echo "ERROR: $POLICY is blank, and blank values are ignored" >&2; exit 2; }
    if grep -q '"""' "$POLICY"; then
      echo "ERROR: $POLICY contains \"\"\", which would end the TOML string early" >&2; exit 2
    fi
    # Tripwire, not a gate: the default policy's section headings (policy.md).
    for h in "Data Exfiltration" "Credential Probing" "Persistent Security Weakening" "Destructive Actions"; do
      grep -q "### $h" "$POLICY" \
        || echo "WARN: $POLICY has no '### $h' section; a policy missing the default rules replaces them (TRAP 6)" >&2
    done
    printf '\nguardian_policy_config = """\n'
    sed 's/\\/\\\\/g' "$POLICY"     # TOML basic strings treat backslash as an escape
    printf '"""\n'
  fi
  exit 0
fi

# Lint a saved copy of the Global requirements TOML (copy it out of Agent Security
# by hand; no API returns it). Reads top-level keys only.
toml_flatten() {   # prints "<section>\t<key>\t<value>"; section is "" at top level
  awk -v SQ="'" '
    function strip(s,   i, c, q, out, esc) {
      q = ""; out = ""; esc = 0
      for (i = 1; i <= length(s); i++) {
        c = substr(s, i, 1)
        if (q == "\"") { out = out c; if (esc) esc = 0; else if (c == "\\") esc = 1; else if (c == "\"") q = ""; continue }
        if (q == SQ)   { out = out c; if (c == SQ) q = ""; continue }
        if (c == "#") break
        if (c == "\"" || c == SQ) q = c
        out = out c
      }
      return out
    }
    function depth(s,   i, c, q, d, esc) {
      q = ""; d = 0; esc = 0
      for (i = 1; i <= length(s); i++) {
        c = substr(s, i, 1)
        if (q == "\"") { if (esc) esc = 0; else if (c == "\\") esc = 1; else if (c == "\"") q = ""; continue }
        if (q == SQ)   { if (c == SQ) q = ""; continue }
        if (c == "\"" || c == SQ) q = c
        else if (c == "[") d++
        else if (c == "]") d--
      }
      return d
    }
    function trim(s) { gsub(/^[ \t]+|[ \t]+$/, "", s); return s }
    function emit() { printf "%s\t%s\t%s\n", sect, key, trim(val); key = ""; val = "" }
    BEGIN { sect = ""; n = 0; mls = ""; arr = 0; TQ = SQ SQ SQ }
    {
      line = $0; sub(/\r$/, "", line)
      if (mls != "") {
        p = index(line, mls)
        if (p > 0) { val = val " " substr(line, 1, p - 1); mls = ""; emit() } else val = val " " line
        next
      }
      if (arr > 0) { s = strip(line); val = val " " s; arr += depth(s); if (arr <= 0) { arr = 0; emit() }; next }
      s = trim(strip(line))
      if (s == "") next
      if (substr(s, 1, 1) == "[") { n++; sect = s "#" n; next }
      eq = index(s, "="); if (eq == 0) next
      key = trim(substr(s, 1, eq - 1))
      rest = trim(substr(line, index(line, "=") + 1))
      d3 = substr(rest, 1, 3)
      if (d3 == "\"\"\"" || d3 == TQ) {
        body = substr(rest, 4); p = index(body, d3)
        if (p > 0) { val = substr(body, 1, p - 1); emit() } else { val = body; mls = d3 }
        next
      }
      val = trim(strip(rest))
      if (substr(val, 1, 1) == "[") { arr = depth(val); if (arr > 0) next }
      emit()
    }
  ' "$1"
}
top() { awk -F'\t' -v k="$2" '$1 == "" && $2 == k { print $3; f = 1 } END { exit !f }' "$1"; }
members() { grep -oE "\"[^\"]*\"|'[^']*'" | tr -d "\"'" || true; }

if [ "$ACTION" = "verify" ]; then
  FILE="${2:-${HTH_REQUIREMENTS_FILE:-}}"
  [ -n "$FILE" ] && [ -r "$FILE" ] || { echo "PRECONDITION: pass a saved copy of the Global requirements TOML" >&2; exit 2; }
  FLAT=$(mktemp "${TMPDIR:-/tmp}/hth-dots-402.XXXXXX"); trap 'rm -f "$FLAT"' EXIT
  toml_flatten "$FILE" > "$FLAT"
  FAILS=0

  if v=$(top "$FLAT" allowed_approval_policies); then
    if printf '%s' "$v" | members | grep -x never >/dev/null; then
      echo "  FAIL: allowed_approval_policies includes \"never\""; FAILS=1
    else echo "  PASS: allowed_approval_policies = $v"; fi
  else echo "  FAIL: allowed_approval_policies is not set, so it is unconstrained and \"never\" is allowed"; FAILS=1; fi

  if v=$(top "$FLAT" allowed_web_search_modes); then
    if printf '%s' "$v" | members | grep -x live >/dev/null; then
      echo "  FAIL: allowed_web_search_modes includes \"live\""; FAILS=1
    else echo "  PASS: allowed_web_search_modes = $v (disabled is always allowed)"; fi
  else echo "  FAIL: allowed_web_search_modes is not set, so it is unconstrained and \"live\" is allowed"; FAILS=1; fi

  AUTO=1
  if v=$(top "$FLAT" allowed_approvals_reviewers); then
    echo "  INFO: allowed_approvals_reviewers = $v"
    printf '%s' "$v" | members | grep -x auto_review >/dev/null || AUTO=0
  else echo "  INFO: allowed_approvals_reviewers is not set, so auto_review is allowed"; fi
  g=$(top "$FLAT" guardian_policy_config || true)
  if [ "$AUTO" = 1 ]; then
    if printf '%s' "$g" | tr -d "\"' \t" | grep . >/dev/null; then
      echo "  PASS: guardian_policy_config is set for automatic review (confirm it is a COMPLETE policy — TRAP 6)"
    else
      echo "  FAIL: auto_review is allowed but guardian_policy_config is missing or blank"; FAILS=1
    fi
  elif ! printf '%s' "$g" | tr -d "\"' \t" | grep . >/dev/null; then
    echo "  INFO: no guardian_policy_config; a dot's Auto-review keeps OpenAI's built-in policy (TRAP 6)"
  fi
  exit "$FAILS"
fi

Code Pack: Sigma Detection Rule

hth-chatgpt-dots-4.02-agent-security-policy-saved.yml View source on GitHub ↗

logsource:
    product: openai
    service: chatgpt-compliance
    definition: 'ChatGPT Compliance Logs Platform JSONL records with type AUDIT_LOG; nested keys flattened with dots (action_data.workspace_policy)'
detection:
    selection:
        type: 'AUDIT_LOG'
        action: 'WORKSPACE_SET_POLICY'
        action_data.workspace_policy:
            - 'codex.agent_policy'
            - 'codex.policy_stack'
            - 'codex.legacy_requirements'
    condition: selection
fields:
    - timestamp
    - event_id
    - actor.type
    - actor.user_email
    - action_result
    - action_privilege
    - action_data.workspace_policy
    - action_data.mutation_applied
    - action_data.policy_changes
    - action_data.policy_changes_omitted_reason
    - request_metadata.client_ip

What the pack does: the config pack writes the Global requirements.toml fragment for you to paste into Agent Security. It cannot push it.
Why it cannot push: Agent Security says “Use the policy API to manage Global settings”, but OpenAI publishes no contract for it. Admin API v2.5.37 (106 paths, none of them a PUT) has no policy route, even though its own WORKSPACE_SET_POLICY text says policy-stack fields apply to saves “from the UI and public API PUT”. Pasting into Agent Security is therefore the only path this guide can document.
Existing workflows: if your tenant already has Global API or Terraform workflows (“Existing Global API workflows remain available after migration”, Agent Security), test them; they are outside this pack.
Guardian policy: the pack’s emit prints a guardian policy only when auto_review is allowed and HTH_GUARDIAN_POLICY_FILE names a complete policy. On the default user-only emit, it notes that a dot’s Auto-review keeps OpenAI’s built-in policy.
Sigma rule: it matches AUDIT_LOG WORKSPACE_SET_POLICY with workspace_policy of codex.agent_policy, codex.policy_stack or codex.legacy_requirements, and reads action_result. “Agent Security save attempts use codex.agent_policy without additional action_data”, so a UI save proves a save, not its contents.

Doc conflict — policy write interface.

Agent Security says “Use the policy API to manage Global settings … Test your scripts and Terraform integrations”, and Managed configuration says “Inventory Terraform configurations and scripts that update policies”.

The Admin API reference (v2.5.37) publishes no policy route and no PUT operation, yet its WORKSPACE_SET_POLICY text says its policy-stack fields “apply to Codex policy-stack mutation events from the UI and public API PUT”.

A save through that PUT would carry workspace_policy codex.policy_stack. The spec does not say whether that PUT is the policy API Agent Security refers to, or which identifier a Global change through it emits.

Treat an unpublished write path as possible, and keep the Sigma rule matching all three identifiers (8.1 row m).

Automation: ClickOps only — OpenAI publishes no write interface for Agent Security Global policy: Agent Security says “Use the policy API to manage Global settings”, but the Admin API reference (v2.5.37, 106 paths) has no policy route (2026-10-09).

Validation & Testing

Save the Global policy and confirm a WORKSPACE_SET_POLICY event with workspace_policy codex.agent_policy (or codex.policy_stack) and a successful action_result
As a pilot member, give a cloud-only dot a task that requires a consequential action and confirm it asks for approval
Record the result either as evidence that Global policy reaches dots or as a gap

Expected result: The Global baseline is saved and audited, and you have recorded evidence of whether it binds a cloud-only dot.

Compliance Mappings

Framework	Control ID	Control Description
CIS Controls v8	4.1	Establish and Maintain a Secure Configuration Process
NIST 800-53	CM-6	Configuration Settings
NIST 800-53	CM-7	Least Functionality (no `never` approval policy)
NIST 800-53	AC-4	Information Flow Enforcement (web-search modes limited)
SOC 2	CC6.1, CC8.1	Logical access security; change management
Benchmark	None	No benchmark equivalent yet

4.3 Treat managed MCP hooks for dots as fail-open telemetry, not enforcement

Profile Level: L3 (Run)

Framework	Control
CIS Controls v8	8.2
NIST 800-53	SI-4, AU-12

Description

Use managed remote MCP hooks on the dots orchestrator to deny known-bad tool calls and collect telemetry, and monitor the hook service’s availability. Never count them as an enforcement boundary: errors, timeouts and missing servers fail open.

How it works: “When managed policy and remote hooks are enabled, Work Cloud with local access and dots use admin-managed remote MCP hooks on the cloud orchestrator. Configure mcp_tool handlers in Global requirements.toml” (Agent Security; Work admin FAQ).

Only mcp_tool handlers are supported.
Command handlers, hooks from local configuration or plugins, environment-scoped hooks and SessionEnd MCP hooks are not.

Why they fail open:

“An explicit supported denial can block an action, but a PreToolUse callback error, timeout, or malformed response can fail the hook without blocking the tool” (Cloud and local access).
The Hooks page adds that “Errors, missing servers, and unavailable tools don’t block the operation” and says “Treat tool hooks as a useful guardrail, not a complete enforcement boundary.”

What they do not cover: hooks “do not provide a complete Compliance API audit trail” (Apps and connectors) and do not “cover every internal subagent path” (cloud-local-access).

Managed-only switch: allow_managed_hooks_only is documented only as skipping user, project, session and plugin hooks. Those sources are already unsupported under cloud orchestration, so it has no documented dots-specific effect. Keep it for local-only Work and Codex threads under the same policy.

Doc caveats.

The Hooks page prints the mcp_tool example in JSON only, so the TOML form follows the documented JSON-to-TOML equivalence.

The Config reference’s “Configured through TOML” list for Work Cloud and dots omits hooks, which conflicts with Agent Security’s listing of “Managed hooks: hooks, allow_managed_hooks_only” as orchestrator controls.

Whether a managed hook directory is required for cloud mcp_tool-only hooks is undocumented.

Rationale

Why This Matters:

“The cloud orchestrator calls your connected MCP service at supported task and tool events” (cloud-local-access), which makes hooks the documented customer-run interception point on the dots orchestrator.
Because errors, timeouts, malformed responses, missing servers and unavailable tools fail open, an attacker who degrades the hook endpoint removes its blocking effect without blocking the tool call.

Attack Prevented: Known-bad tool invocations, while the hook service is healthy.

Prerequisites

ChatGPT Enterprise. Managed hooks are enterprise hooks, “not available for personal accounts”; Business Premium eligibility is undocumented
Managed policy enabled, and remote hooks enabled for the workspace (“Where enabled for your workspace”; no toggle name is documented)
An already-connected MCP server for the hook to call: hooks “don’t start or reconnect servers”

ClickOps Implementation

Step 1: Open the Global requirements

Navigate to: Admin Console > Agent Security > (select a policy) > Global > Requirements
- No UI control for hooks is documented. Agent Security names only Allowed approval policies and Allowed web search modes as dedicated controls among “the approval, web search, app, MCP, plugin, and rule requirements”, a list that does not include hooks
- Entering hooks as TOML is therefore an inference to confirm in a live tenant (8.11)

Step 2: Enter the hook as TOML

Add a [[hooks.PreToolUse]] entry with a matcher, and under it a [[hooks.PreToolUse.hooks]] entry with type = "mcp_tool", server (required; an already-connected MCP server), tool (required), input (default {}), timeout (default 600) and statusMessage
Optionally set allow_managed_hooks_only = true for local-only Work and Codex threads under the same policy

Step 3: Monitor the hook service

Alert on hook-service downtime, because an unavailable hook does not block the tool

Code Implementation

Code Pack: Config

hth-chatgpt-dots-4.03-managed-mcp-hooks.sh View source on GitHub ↗

# Print a PreToolUse mcp_tool hook for Agent Security > Global > Requirements.
#   HTH_HOOK_SERVER   name of an MCP server already connected for the workspace
#   HTH_HOOK_TOOL     tool on that server that answers allow/deny
#   HTH_HOOK_MATCHER  regex on tool name; unset = every supported tool call
#   HTH_HOOK_TIMEOUT  seconds, default 30 (the documented default is 600)
#   HTH_MANAGED_HOOKS_ONLY=1  also emit allow_managed_hooks_only = true
if [ "$ACTION" = "emit" ]; then
  [ -n "${HTH_HOOK_SERVER:-}" ] || { echo "PRECONDITION: set HTH_HOOK_SERVER to the name of an already-connected MCP server" >&2; exit 2; }
  [ -n "${HTH_HOOK_TOOL:-}" ] || { echo "PRECONDITION: set HTH_HOOK_TOOL to the tool on that server that returns the decision" >&2; exit 2; }
  TIMEOUT="${HTH_HOOK_TIMEOUT:-30}"
  for v in "$HTH_HOOK_SERVER" "$HTH_HOOK_TOOL"; do
    printf '%s' "$v" | grep -E '^[A-Za-z0-9_.-]+$' >/dev/null || {
      echo "ERROR: '$v' — use letters, digits, '_', '.' or '-' only" >&2; exit 2; }
  done
  printf '%s' "$TIMEOUT" | grep -E '^[1-9][0-9]*$' >/dev/null || {
    echo "ERROR: HTH_HOOK_TIMEOUT must be a positive integer (seconds)" >&2; exit 2; }
  case "${HTH_HOOK_MATCHER:-}" in
    *"'"*) echo "ERROR: HTH_HOOK_MATCHER cannot contain a single quote (emitted as a TOML literal string)" >&2; exit 2 ;;
  esac

  if [ "${HTH_MANAGED_HOOKS_ONLY:-0}" = "1" ]; then
    printf 'allow_managed_hooks_only = true\n\n'
  fi
  printf '[[hooks.PreToolUse]]\n'
  if [ -n "${HTH_HOOK_MATCHER:-}" ]; then
    printf "matcher = '%s'\n" "$HTH_HOOK_MATCHER"
  fi
  printf '\n[[hooks.PreToolUse.hooks]]\n'
  printf 'type = "mcp_tool"\n'
  printf 'server = "%s"\n' "$HTH_HOOK_SERVER"
  printf 'tool = "%s"\n' "$HTH_HOOK_TOOL"
  printf '%s\n' 'input = { session_id = "${session_id}", tool_name = "${tool_name}", tool_use_id = "${tool_use_id}", tool_input = "${tool_input}" }'
  printf 'timeout = %s\n' "$TIMEOUT"
  printf 'statusMessage = "Checking tool call against workspace policy"\n'
  exit 0
fi

# Lint the hook handlers in a saved copy of the Global requirements TOML.
# Passing means "configured", never "enforced": prove the block with a deny-all
# tool, then prove fail-open by taking the MCP service offline.
toml_flatten() {   # prints "<section>\t<key>\t<value>"; section is "" at top level
  awk -v SQ="'" '
    function strip(s,   i, c, q, out, esc) {
      q = ""; out = ""; esc = 0
      for (i = 1; i <= length(s); i++) {
        c = substr(s, i, 1)
        if (q == "\"") { out = out c; if (esc) esc = 0; else if (c == "\\") esc = 1; else if (c == "\"") q = ""; continue }
        if (q == SQ)   { out = out c; if (c == SQ) q = ""; continue }
        if (c == "#") break
        if (c == "\"" || c == SQ) q = c
        out = out c
      }
      return out
    }
    function depth(s,   i, c, q, d, esc) {
      q = ""; d = 0; esc = 0
      for (i = 1; i <= length(s); i++) {
        c = substr(s, i, 1)
        if (q == "\"") { if (esc) esc = 0; else if (c == "\\") esc = 1; else if (c == "\"") q = ""; continue }
        if (q == SQ)   { if (c == SQ) q = ""; continue }
        if (c == "\"" || c == SQ) q = c
        else if (c == "[") d++
        else if (c == "]") d--
      }
      return d
    }
    function trim(s) { gsub(/^[ \t]+|[ \t]+$/, "", s); return s }
    function emit() { printf "%s\t%s\t%s\n", sect, key, trim(val); key = ""; val = "" }
    BEGIN { sect = ""; n = 0; mls = ""; arr = 0; TQ = SQ SQ SQ }
    {
      line = $0; sub(/\r$/, "", line)
      if (mls != "") {
        p = index(line, mls)
        if (p > 0) { val = val " " substr(line, 1, p - 1); mls = ""; emit() } else val = val " " line
        next
      }
      if (arr > 0) { s = strip(line); val = val " " s; arr += depth(s); if (arr <= 0) { arr = 0; emit() }; next }
      s = trim(strip(line))
      if (s == "") next
      if (substr(s, 1, 1) == "[") { n++; sect = s "#" n; next }
      eq = index(s, "="); if (eq == 0) next
      key = trim(substr(s, 1, eq - 1))
      rest = trim(substr(line, index(line, "=") + 1))
      d3 = substr(rest, 1, 3)
      if (d3 == "\"\"\"" || d3 == TQ) {
        body = substr(rest, 4); p = index(body, d3)
        if (p > 0) { val = substr(body, 1, p - 1); emit() } else { val = body; mls = d3 }
        next
      }
      val = trim(strip(rest))
      if (substr(val, 1, 1) == "[") { arr = depth(val); if (arr > 0) next }
      emit()
    }
  ' "$1"
}

if [ "$ACTION" = "verify" ]; then
  FILE="${2:-${HTH_REQUIREMENTS_FILE:-}}"
  [ -n "$FILE" ] && [ -r "$FILE" ] || { echo "PRECONDITION: pass a saved copy of the Global requirements TOML" >&2; exit 2; }
  FLAT=$(mktemp "${TMPDIR:-/tmp}/hth-dots-403.XXXXXX"); trap 'rm -f "$FLAT"' EXIT
  toml_flatten "$FILE" > "$FLAT"

  # One record per handler: event, type, server, tool, timeout ("-" when absent).
  HANDLERS=$(awk -F'\t' -v SQ="'" '
    function get(id, k) { return (f[id, k] != "" ? f[id, k] : "-") }
    $1 ~ /^\[\[hooks\.[A-Za-z]+\.hooks\]\]#/ {
      id = $1
      if (!(id in event)) { ev = id; sub(/^\[\[hooks\./, "", ev); sub(/\.hooks\]\]#.*/, "", ev); event[id] = ev; ids[++m] = id }
      v = $3; gsub("^[\"" SQ "]|[\"" SQ "]$", "", v); f[id, $2] = v
    }
    END { for (i = 1; i <= m; i++) { id = ids[i]
            printf "%s\t%s\t%s\t%s\t%s\n", event[id], get(id, "type"), get(id, "server"), get(id, "tool"), get(id, "timeout") } }
  ' "$FLAT")

  if awk -F'\t' '$1 ~ /^\[\[hooks\.[A-Za-z]+\]\]#/ && $2 == "hooks" { f = 1 } END { exit !f }' "$FLAT"; then
    echo "UNVERIFIED: handlers written as an inline array (hooks = [...]) — review them by hand" >&2; exit 2
  fi
  # The same handlers written as a [hooks] table with event-named array keys, or
  # as a top-level hooks / hooks.<Event> key, are valid TOML this lint does not parse.
  if awk -F'\t' '($1 ~ /^\[[ \t]*hooks[ \t]*\]#/ && $3 ~ /^\[/) ||
                 ($1 == "" && ($2 == "hooks" || $2 ~ /^hooks\./)) { f = 1 } END { exit !f }' "$FLAT"; then
    echo "UNVERIFIED: hooks written as an inline table or array ([hooks] / hooks = ...) — review them by hand" >&2; exit 2
  fi

  GOOD=0; FAILS=0
  # Hooks page: "Admins can force hooks off the same way in requirements.toml
  # with [features].hooks = false." codex_hooks is the deprecated alias (TRAP 8).
  if awk -F'\t' '
       function off(v) { gsub(/[ \t]/, "", v); return v == "false" }
       ($1 ~ /^\[[ \t]*features[ \t]*\]#/ && ($2 == "hooks" || $2 == "codex_hooks") && off($3)) ||
       ($1 == "" && ($2 == "features.hooks" || $2 == "features.codex_hooks") && off($3)) ||
       ($1 == "" && $2 == "features" && $3 ~ /(^|[{,[:space:]])(codex_)?hooks[[:space:]]*=[[:space:]]*false([[:space:]]*[,}]|$)/) { f = 1 }
       END { exit !f }' "$FLAT"; then
    echo "  FAIL: [features].hooks (or codex_hooks) = false force-disables hooks in this same file (Hooks page); remove it"; FAILS=1
  fi
  while IFS=$'\t' read -r ev type server tool timeout; do
    [ -n "$ev" ] || continue
    case "$type" in
      mcp_tool)
        if [ "$ev" = "SessionEnd" ]; then
          echo "  FAIL: SessionEnd mcp_tool hook — not supported with cloud orchestration"; FAILS=1
        elif [ "$server" = "-" ] || [ "$tool" = "-" ]; then
          echo "  FAIL: $ev mcp_tool hook is missing server or tool (both are required)"; FAILS=1
        else
          [ "$timeout" = "-" ] && timeout="600 (documented default)"
          echo "  PASS: $ev mcp_tool hook -> server=$server tool=$tool timeout=$timeout"
          [ "$ev" = "PreToolUse" ] && GOOD=1
        fi ;;
      *) echo "  NOTE: $ev handler type '$type' is not supported with cloud orchestration; it does not run for dots" ;;
    esac
  done <<< "$HANDLERS"

  if awk -F'\t' '$1 == "" && $2 == "allow_managed_hooks_only" { f = 1 } END { exit !f }' "$FLAT"; then
    echo "  INFO: allow_managed_hooks_only is set; it has no documented effect on dots"
  fi
  if [ "$GOOD" = 0 ]; then
    echo "  FAIL: no PreToolUse mcp_tool hook is configured, so nothing can block a dot's tool call"; FAILS=1
  fi
  exit "$FAILS"
fi

What the pack does: the config pack emits the hook TOML for you to paste into Global Requirements. It cannot push it, because the vendor-referenced policy API has no published contract (see 4.2; “Support for a requirements.toml field does not by itself establish API compatibility”, Config reference). Pasting into Global Requirements is the only documented path.
Verify mode: its verify fails any file that pins [features].hooks (or the deprecated codex_hooks) to false, because the Hooks page says “Admins can force hooks off the same way in requirements.toml with [features].hooks = false”. The Config reference rates features only “Partial” for Local computer access with Work Cloud, so the effect on dots is undocumented.
Telemetry: hook callbacks land in your own MCP service as your telemetry.
Audit trail:
- Agent Security UI saves appear as AUDIT_LOG WORKSPACE_SET_POLICY codex.agent_policy “without additional action_data”, so they carry no diff and no hook contents.
- Codex policy-stack saves (codex.policy_stack, “from the UI and public API PUT”) also record policy_changes[].toml_changes[].key_changes[].path, the TOML key segments that changed, never their values. Because arrays of tables are compared at their containing key, a hooks edit shows as ["hooks","PreToolUse"], not per hook.
- Whether a Global change made through the policy API is logged as codex.policy_stack is undocumented.
Review: pair the 4.2 Sigma rule with a periodic manual review of the Global TOML.

Automation: ClickOps only — OpenAI publishes no write interface for Global Requirements hooks: the Admin API reference has no policy route, and the Config reference says “Support for a requirements.toml field does not by itself establish API compatibility” (2026-10-09).

Validation & Testing

Confirm the Global requirements do not set [features].hooks = false (or the deprecated codex_hooks), which the Hooks page says forces hooks off; the 4.3 pack’s verify fails on it
Point a test hook at a deny-all MCP tool and confirm a dot tool call is blocked
Take the hook endpoint offline and confirm the call proceeds, which proves fail-open
Confirm your hook-service downtime alert fires

Expected result: Hooks block known-bad calls while healthy, and their failure is detected rather than silent.

Compliance Mappings

Framework	Control ID	Control Description
CIS Controls v8	8.2	Collect Audit Logs
NIST 800-53	SI-4	System Monitoring
NIST 800-53	AU-12	Audit Record Generation
SOC 2	CC7.2	Monitoring of system components for anomalies
Benchmark	None	No benchmark equivalent yet

4.4 Set member custom rules to hand off purchases and ask before external sends

Profile Level: L2 (Walk)

Framework	Control
NIST 800-53	AC-6, PL-4

Description

Each dot owner should add custom rules: Hand off to you for purchases and for deleting shared files, and Ask before taking action for messages to external recipients. Never let a send, share or purchase run under Take action without asking.

Who sets it: the dot owner, not an admin. Custom rules are the owner’s lever for actions the dot takes on its own computer or in its browser, such as merchant-site purchases. This applies to Pro and Business Premium owners, and to Enterprise members where 4.1 permits custom rules.

The four choices (Controls):

“Take action without asking”
“Take action when you say so” (Help Center label “Take action if pre-approved”, meaning “you explicitly requested the action in your prompt”, Getting started with your dot)
“Ask before taking action”
“Hand off to you”

Purchases already need approval: “Your dot can also make purchases using a card you’ve saved on a merchant’s website. These purchases require your approval, which may be given in advance when it specifically covers the purchase” (Dots FAQs). Hand off to you is therefore stricter than an existing requirement.

Limits of rules: rules are “instructions your dot tries to follow, and it can make mistakes”, and they “don’t grant access to an app or computer, override built-in safety requirements, or remove required confirmations” (Controls).

App permissions are a separate lever: “Plugin permissions … control app actions separately from custom rules” (Controls).

On personal accounts they offer Always ask, Allow read actions, Allow low-risk actions and Allow all actions (Managing app permissions), although “The standard account-wide and workspace-wide permission selectors do not offer Allow all actions”; it may appear only for an individual app or connected account.
Set app actions to Always ask as well.

By plan:

Pro has no workspace admin.
Business Premium: OpenAI documents the custom-rules admin permission and custom roles only for role-managed Enterprise workspaces (RBAC in ChatGPT). help 11509118 limits only role-specific app access to Enterprise and Edu; its Actions and New actions controls, and the workspace-wide Workspace settings > General > Settings > Plugin permissions default, carry no plan restriction where the workspace and app support them.
Business Premium admins should set that workspace default to Always ask and apply the per-app baseline in 2.1. OpenAI’s Business-specific sentences name only workspace-wide app enablement, so confirm the selector appears in your console.

Rationale

Why This Matters:

For actions outside connected apps, such as merchant-site purchases, the owner’s custom rules are the only configurable boundary on Pro and Business Premium beyond built-in confirmations.
OpenAI’s system card reports that doubling the number of intervening tasks from five to ten “roughly doubled the observed flag rate, from 8.6% to 19.7% of samples” for moderate-severity scope violations, with no instances of severe breach or exfiltration (dots appendix, section 12.3.5.2).

Attack Prevented: Unintended purchases and external sends from a manipulated or drifting dot.

Prerequisites

On Enterprise, the member must hold Use custom rules for dots (4.1)

ClickOps Implementation

Step 1: Add the rules (desktop)

Navigate to: Settings > Personalization > Custom rules (under Permissions) > Add
Describe the action (purchases; deleting shared files), choose Hand off to you, and select Add rule
Describe the action (messages to external recipients), choose Ask before taking action, and select Add rule

Step 2: Mobile equivalent

Navigate to: Customize > Custom rules, add a rule, and save with the checkmark

Step 3: Pair with app permissions

Pro (the owner does this): Navigate to Settings > Plugins > Permissions and select Always ask
- Help 20001495 documents this selector only “for an eligible personal account” whose Settings shows Plugins. If Settings shows Apps instead, “The same account-wide selector may not be available”, and Permissions can appear only after a plugin that includes an app is installed
Business Premium and Enterprise: members of a managed workspace “may instead see approval prompts governed by workspace policy” (Managing app permissions), so the workspace admin sets the equivalent:
- Workspace settings > General > Settings > Plugin permissions set to Always ask
- Each included app’s Permissions control in Admin console > Plugins > {plugin} > Apps section, checked for a looser per-app override (help 11509118; see 2.1 Steps 1 and 3)
- From the custom rules settings, members can “Select Open Plugins to review Plugin permissions” (Controls)

Automation: ClickOps only — OpenAI exposes no write interface for this setting (Admin API reference, 2026-10-08). No audit event records a custom-rule change.

Validation & Testing

Ask the dot to buy a low-cost item from a merchant site and confirm it hands the step back
Ask it to email an external address and confirm it asks first
Confirm the app permissions:
- Pro: confirm Settings > Plugins > Permissions is set to Always ask
- Business Premium and Enterprise: confirm with the workspace admin that Workspace settings > General > Settings > Plugin permissions is Always ask, and that no included app in Admin console > Plugins overrides it with a looser per-app permission

Expected result: The dot hands back purchases and asks before any external send.

Compliance Mappings

Framework	Control ID	Control Description
NIST 800-53	AC-6	Least Privilege (the dot acts on purchases and external sends only with its owner’s approval)
NIST 800-53	PL-4	Rules of Behavior
SOC 2	CC6.1	Logical access security
Benchmark	None	No benchmark equivalent yet

5. Data, Memory & Residency

5.1 Keep dots out of workspaces and populations that require residency, EKM, or zero retention

Profile Level: L3 (Run)

Framework	Control
CIS Controls v8	3.1, 3.7
NIST 800-53	SA-9(5), SI-12, AC-3

Description

Do not grant Use dots (Beta) to any population whose data requires residency or zero retention. Because the opt-in acknowledgment is workspace-wide, enforce that boundary through roles: no regulated user may hold a role that grants dots.

Limits during the beta (Cloud and local access):

“During the Enterprise beta, dots do not support data residency or inference residency. Eligible workspaces can opt in after acknowledging those limitations; enabling dots does not make their data or processing residency-compliant”.
“Dots are unavailable for FedRAMP workspaces, workspaces with EKM, and workspaces with inference residency set to AE (UAE). HIPAA workspaces can participate if they meet the other eligibility requirements.”
Neither dots nor Work Cloud provides strict zero data retention: “Neither experience provides strict zero data retention”.

Retained context:

A dot “can retain context from your conversations and plugins for as long as you keep your dot”, and “Human review may occur in limited circumstances, including safety-related cases, even when model improvement is turned off” (Dots FAQs).
For retention and EKM in the rest of the workspace, see the ChatGPT Enterprise guide’s 2.2 and 2.3.

How roles combine: OpenAI’s pages disagree (see the 1.1 doc conflict and 8.1 row f).

Roles and workspace permissions says Off “does not grant access through that role” and that permissions “combine additively”.
Groups and provisioning says “an explicit Off in any role denies that permission, even when another role grants it”.
Until a live tenant settles it, treat grants as additive. Setting Off in a regulated user’s own role may not be enough, so review every role they hold directly and through groups.

A separate, optional lever: enforce_residency is a string key: “Require Codex service traffic to use a supported data residency. Currently accepts us” (Config reference).

If any cloud policy enables it, Allow local computer access becomes unavailable for both Work and dots across the whole workspace.
It “does not set workspace residency or, by itself, disable Work Cloud or dots”, so dots cloud coordination and the cloud computer still process data without residency.
The docs name only cloud policies, managed in Admin Console > Agent Security, as the trigger; a device requirements.toml is not documented to have this effect.
Apply it only where US residency for Codex traffic is intended.

Doc conflict — what blocks local access.

Cloud and local access says “If any cloud policy enables enforce_residency, Allow local computer access is unavailable for both Work and dots.”

Manage dots in ChatGPT workspaces instead says “Local computer access is unavailable in workspaces with Codex or ChatGPT Work policies that target a specific operating system.”

See 3.4 and 8.1 row b. Confirm in a live tenant which condition applies before relying on Step 3 to block local access.

Rationale

Why This Matters:

Opting in to dots moves the opted-in users’ work outside residency and zero-retention commitments. The opt-in acknowledgment is workspace-wide, so the population boundary has to be enforced through roles.
Workspaces with EKM, FedRAMP or AE inference residency cannot use dots at all, so the control matters where regulated users share a workspace with dots users.

Attack Prevented: Regulatory non-compliance and uncontrolled data location for regulated workloads.

Prerequisites

A list of the populations whose data requires residency or zero retention

ClickOps Implementation

Step 1: Keep the workspace default Off

Navigate to: Workspace settings > Permissions & roles > Permissions > Workspace default > Workspace capabilities > Use dots (Beta)
Confirm it is Off

Step 2: Check every role a regulated user holds

For each custom role a regulated user holds, directly or through a group, set Use dots (Beta) to an explicit Off rather than Default. Under the additive reading the two are equivalent; under the groups-and-provisioning reading, only an explicit Off denies
Confirm no other role grants it. Do not rely on an Off role as a deny until a live tenant settles which reading holds

Step 3 (optional and separate): Block local access with enforce_residency

Navigate to: Admin Console > Agent Security and open a cloud policy’s requirements TOML
Add enforce_residency = "us" only if US residency for Codex traffic is intended. This blocks Allow local computer access workspace-wide for Work and dots; it does not disable dots

Code Implementation

Code Pack: Config

hth-chatgpt-dots-5.01-enforce-residency.sh View source on GitHub ↗

# Print the requirement that blocks Allow local computer access for Work and dots
# workspace-wide. It also requires US residency for Codex service traffic.
if [ "$ACTION" = "emit" ]; then
  if [ "${HTH_CONFIRM_US_CODEX_RESIDENCY:-}" != "yes" ]; then
    echo "PRECONDITION: enforce_residency also requires US residency for Codex service traffic." >&2
    echo "Set HTH_CONFIRM_US_CODEX_RESIDENCY=yes once that is intended for this policy's users." >&2
    exit 2
  fi
  printf 'enforce_residency = "us"\n'
  exit 0
fi

# Check saved copies of every Agent Security cloud policy's requirements TOML.
# The lever is optional (guide 5.1 Step 3): reports SET when at least one policy
# sets enforce_residency = "us", NOT SET (exit 0) when none does, and fails only
# on a value other than "us".
toml_flatten() {   # prints "<section>\t<key>\t<value>"; section is "" at top level
  awk -v SQ="'" '
    function strip(s,   i, c, q, out, esc) {
      q = ""; out = ""; esc = 0
      for (i = 1; i <= length(s); i++) {
        c = substr(s, i, 1)
        if (q == "\"") { out = out c; if (esc) esc = 0; else if (c == "\\") esc = 1; else if (c == "\"") q = ""; continue }
        if (q == SQ)   { out = out c; if (c == SQ) q = ""; continue }
        if (c == "#") break
        if (c == "\"" || c == SQ) q = c
        out = out c
      }
      return out
    }
    function depth(s,   i, c, q, d, esc) {
      q = ""; d = 0; esc = 0
      for (i = 1; i <= length(s); i++) {
        c = substr(s, i, 1)
        if (q == "\"") { if (esc) esc = 0; else if (c == "\\") esc = 1; else if (c == "\"") q = ""; continue }
        if (q == SQ)   { if (c == SQ) q = ""; continue }
        if (c == "\"" || c == SQ) q = c
        else if (c == "[") d++
        else if (c == "]") d--
      }
      return d
    }
    function trim(s) { gsub(/^[ \t]+|[ \t]+$/, "", s); return s }
    function emit() { printf "%s\t%s\t%s\n", sect, key, trim(val); key = ""; val = "" }
    BEGIN { sect = ""; n = 0; mls = ""; arr = 0; TQ = SQ SQ SQ }
    {
      line = $0; sub(/\r$/, "", line)
      if (mls != "") {
        p = index(line, mls)
        if (p > 0) { val = val " " substr(line, 1, p - 1); mls = ""; emit() } else val = val " " line
        next
      }
      if (arr > 0) { s = strip(line); val = val " " s; arr += depth(s); if (arr <= 0) { arr = 0; emit() }; next }
      s = trim(strip(line))
      if (s == "") next
      if (substr(s, 1, 1) == "[") { n++; sect = s "#" n; next }
      eq = index(s, "="); if (eq == 0) next
      key = trim(substr(s, 1, eq - 1))
      rest = trim(substr(line, index(line, "=") + 1))
      d3 = substr(rest, 1, 3)
      if (d3 == "\"\"\"" || d3 == TQ) {
        body = substr(rest, 4); p = index(body, d3)
        if (p > 0) { val = substr(body, 1, p - 1); emit() } else { val = body; mls = d3 }
        next
      }
      val = trim(strip(rest))
      if (substr(val, 1, 1) == "[") { arr = depth(val); if (arr > 0) next }
      emit()
    }
  ' "$1"
}

if [ "$ACTION" = "verify" ]; then
  shift || true
  [ "$#" -gt 0 ] || { echo "PRECONDITION: pass saved copies of every cloud policy's requirements TOML" >&2; exit 2; }
  SET=0; FAILS=0
  for FILE in "$@"; do
    [ -r "$FILE" ] || { echo "PRECONDITION: cannot read $FILE" >&2; exit 2; }
    if v=$(toml_flatten "$FILE" | awk -F'\t' '$1 == "" && $2 == "enforce_residency" { print $3; f = 1 } END { exit !f }'); then
      v=$(printf '%s' "$v" | tr -d "\"'")
      if [ "$v" = "us" ]; then
        echo "  SET:  $FILE -> enforce_residency = \"us\""; SET=1
      else
        echo "  FAIL: $FILE -> enforce_residency = \"$v\" (only \"us\" is accepted)"; FAILS=1
      fi
    else
      echo "  --    $FILE -> enforce_residency not set"
    fi
  done
  [ "$FAILS" = 0 ] || exit 1
  if [ "$SET" = 1 ]; then
    echo "  PASS: Allow local computer access should show as unavailable for Work and dots, workspace-wide"
    echo "        (dots themselves stay available; confirm the role boundary separately; TRAP 4 conflict)"
  else
    echo "  NOT SET: no cloud policy sets enforce_residency (optional lever; keep Allow local computer access"
    echo "        Off through roles instead — control 3.4)"
  fi
  exit 0
fi

What the pack does: the config pack prints the enforce_residency line to paste into an Agent Security cloud policy.
Verify mode: its verify mode lints saved copies of every cloud policy’s requirements TOML. It reports the lever as not set (exit 0) when no policy uses it, because the lever is optional.
No push: it cannot push the line. No policy-write endpoint is documented (the docs reference a policy API for Global settings, but no public route exists; see 8.3).
Membership check: the 1.1 group-membership read can confirm regulated users are not in the dots group, but it proves membership only, not what a group’s role grants.

Automation: ClickOps only — OpenAI exposes no write interface for the Use dots (Beta) permission, and publishes no route for Agent Security cloud policy (Admin API reference, 2026-10-09).

Validation & Testing

Confirm that no role a regulated user holds, directly or through a group, grants Use dots (Beta), and that the workspace default is Off
If enforce_residency is set, confirm Allow local computer access shows as unavailable under Use dots (Beta). If it does not, the help 20001554 condition (policies that target a specific operating system) may be the one in force; see 8.1 row b

Expected result: No regulated user can use dots, and any residency lever in place has only its intended effect.

Compliance Mappings

Framework	Control ID	Control Description
CIS Controls v8	3.1	Establish and Maintain a Data Management Process
CIS Controls v8	3.7	Establish and Maintain a Data Classification Scheme
NIST 800-53	SA-9(5)	Processing, Storage, and Service Location
NIST 800-53	SI-12	Information Management and Retention (the zero-retention boundary)
NIST 800-53	AC-3	Access Enforcement
SOC 2	C1.1, P4.1	Identification and maintenance of confidential information; use of personal information limited to identified purposes
GDPR	Art. 44	General principle for transfers
Benchmark	None	No benchmark equivalent yet

5.2 Limit what flows into a dot’s persistent memory

Profile Level: L2 (Walk)

Framework	Control
CIS Controls v8	3.1, 3.4
NIST 800-53	SI-12, PT-2, AC-4

Description

Turning Memory off stops memory sharing between ChatGPT and a dot, but does not delete what the dot already received and may not change its own notes. Turn Memory off for members who handle regulated data, or workspace-wide where available. On Pro, turn off Improve the model for everyone.

How dot memory works: a dot and ChatGPT Memory share context in both directions.

A dot “can receive memories and recent conversation context from ChatGPT, and conversations with your dot can contribute to memory in ChatGPT”. “Turning off Memory in ChatGPT stops that sharing. It does not delete information that your dot has already received” (Dots FAQs).
A dot keeps its own notes separate from ChatGPT’s saved memory, and “Changing a ChatGPT saved-memory setting doesn’t necessarily change the notes your dot has already made” (Tasks and memory).
“You currently cannot view, delete or directly modify individual dot memories” (Dots FAQs). No documented admin path can inspect or purge a dot’s notes.
Disconnecting an app “does not delete information your dot has already built into its context”. Only deleting the dot deletes its context (7.2).
“Your dot’s context does not retain credentials, images, or screenshots.”

Training:

Business, Enterprise and Edu data is not used for training by default.
For personal plans (Pro), “Improve the model for everyone” controls whether dots’ conversations and work may be used, which “may include actions dots take, work they delegate to other agents, automations you set up, and data from connected apps”.
“We don’t train directly on proactive background research or its notes. If a dot brings information from that research into an eligible conversation or task, that information may be used for training, depending on your settings” (Dots FAQs). So on Pro, research a dot brings into a conversation can be trained on unless Improve the model for everyone is off.

Workspace and role levers: lead with these where they exist.

Business owners can turn Memory off for the entire workspace (Memory FAQ, Business version), which deletes members’ existing saved memories.
Owners and admins “can manage supported memory settings and role permissions”, and improved memory is off by default in ChatGPT for Healthcare and Enterprise Regulated Workspace (Memory in ChatGPT).
Enterprise Admin API: two one-way delete-and-disable writes, plus a per-entry Delete Memory Entry route (see 7.2).
- The workspace endpoint “Disables Memory for the workspace and queues deletion of each member’s About You summary cache and configured M3M dream data”.
- The user endpoint “Disables M3M Memory for a workspace user and deletes their About You summary cache and configured M3M dream data”.
- Neither “delete[s] saved memories, conversation history, or archives”. No re-enable or read-state endpoint is documented, and “M3M” is not defined in any fetched doc.
- Whether these endpoints stop dot-to-ChatGPT memory sharing as the member toggle does, and whether they touch dot notes, is undocumented, so validate before relying on them.

Doc conflict — does turning workspace Memory off delete saved memories?

The Memory FAQ, Business version says “If a workspace owner turns off Memory for the workspace, existing saved memories for members in that workspace are deleted.”

The Admin API reference’s Delete and Disable Workspace Memory says “This operation does not delete saved memories, conversation history, or archives.”

The FAQ covers the Business owner toggle. No fetched doc says whether the API’s “Disables Memory for the workspace” is the same setting, or whether turning off workspace Memory on Enterprise deletes saved memories.

Treat saved-memory loss as possible and irreversible until a non-production workspace test shows otherwise (8.1 row r).

Doc conflict — inspecting dot memories.

The dots admin guide tells admins: “A dot can create saved memories, including information from connected apps. … Review saved memories and reset options when handling sensitive data or offboarding.” Its “saved memories” link points to the dot’s own notes (Tasks and memory).

The Dots FAQs say “You currently cannot view, delete or directly modify individual dot memories”.

Neither page documents an admin or member view of a dot’s notes. Treat them as uninspectable, and as deletable only by deleting the dot (7.2), until a live tenant shows otherwise (8.1 row i).

The features.memories key in requirements.toml pins Codex’s separate local memory store, not ChatGPT or dots memory (Codex memories).

Plans: Pro (outside the EEA, Switzerland and the UK), Business Premium, and the Enterprise, Edu and Healthcare beta.

Rationale

Why This Matters:

Dot memory accumulates everything it is permitted to read, and no admin inspection or purge of dot notes is documented.
Poisoned memory persists across sessions.

Attack Prevented: Persistent memory poisoning, and unbounded accumulation of sensitive data in a store not documented as auditable.

Real-World Incidents:

Radware ZombieAgent (published 2026-01-08; fixed 2025-12-16): a malicious file shared with ChatGPT once planted persistent rules in ChatGPT Memory (one-click), and a separate zero-click Gmail-connector injection exfiltrated data character by character through per-character URLs. A ChatGPT memory analog, not dots.

ClickOps Implementation

Step 1: Members who handle regulated data

Navigate to: Settings > Personalization > Memory and turn it off (Memory in ChatGPT)
- On mobile, the Customize > Memory screen “shows what ChatGPT remembers” and “uses shared ChatGPT memory settings” (Getting started with your dot). That article does not say Memory can be turned off there

Step 2: Business workspace owners (optional, workspace-wide)

Turn Memory off for the whole workspace per the Memory FAQ (Business version). No console path for this toggle is documented on the pages checked, and turning it off deletes members’ existing saved memories

Step 3: Pro accounts (the owner does this)

Navigate to: account menu > Settings > Data controls > Improve the model for everyone and turn it off (mobile: sidebar > profile icon > Settings > Data controls) (Data controls)

Code Implementation

Code Pack: API Script

hth-chatgpt-dots-5.02-disable-user-memory.sh View source on GitHub ↗

# Resolve targets and show, per member, the saved-memory entries that remain
# after the call (TRAP 2). Read-only.
if [ "${SCOPE}" = "users" ]; then
  if [ -n "${FROM_GROUP}" ]; then
    cgpt_safe_id "${FROM_GROUP}" "group ID"
    ROSTER="${CGPT_TMPDIR}/roster.jsonl"
    cgpt_paginate_cursor "/manage/workspaces/${CHATGPT_WORKSPACE_ID}/groups/${FROM_GROUP}/users" "${ROSTER}"
    while IFS= read -r U; do USERS+=("${U}"); done < <(jq -r 'select(.status == "active") | .id' "${ROSTER}")
  fi
  [ "${#USERS[@]}" -gt 0 ] || cgpt_die "no target users — pass USER_ID arguments or --from-group GROUP_ID"
  echo "=== ${#USERS[@]} target member(s) ==="
  for U in "${USERS[@]}"; do
    cgpt_safe_id "${U}" "user ID"
    cgpt_get "/compliance/workspaces/${CHATGPT_WORKSPACE_ID}/users/${U}/memories"
    case "${CGPT_CODE}" in
      200) jq -r --arg u "${U}" '"  \($u): \([(.data // [])[] | (.memory_contexts // [])[] | (.memory_entries // [])[]] | length)"
             + " saved-memory entries in \([(.data // [])[] | (.memory_contexts // [])[]] | length) context(s)"
             + (if .has_more == true then " (lower bound — has_more, TRAP 7)" else "" end)
             + " — NOT deleted by delete_and_disable"' "${CGPT_BODY}" ;;
      403) echo "  ${U}: memory count skipped (key lacks chatgpt.enterprise.compliance_export read)" ;;
      *)   cgpt_fail_http GET "/compliance/workspaces/${CHATGPT_WORKSPACE_ID}/users/${U}/memories" ;;
    esac
  done
fi

# The write. Literal POST, no request body (the spec defines none), retried only
# on 429 — a 429 is a rejected request, so retrying cannot double-apply.
CGPT_POST_RETRIES=3
post_delete_and_disable() { # <path>
  local attempt=0 rc
  CGPT_RETRIES=0
  while :; do
    set +e
    CGPT_CODE="$(_cgpt_auth | curl -sS --path-as-is -K - -X POST -H "Content-Length: 0" -D "${CGPT_HDRS}" \
      -o "${CGPT_BODY}" -w '%{http_code}' "${CHATGPT_ADMIN_BASE}$1" 2>/dev/null)"
    rc=$?
    set -e
    [ "${rc}" -eq 0 ] || CGPT_CODE="000"
    if [ "${CGPT_CODE}" = "429" ] && [ "${attempt}" -lt "${CGPT_POST_RETRIES}" ]; then
      sleep "$(_cgpt_retry_after)"; attempt=$((attempt + 1)); CGPT_RETRIES="${attempt}"; continue
    fi
    return 0
  done
}

FAILED=0
if [ "${SCOPE}" = "workspace" ]; then
  P="/compliance/workspaces/${CHATGPT_WORKSPACE_ID}/memory/delete_and_disable"
  if [ "${APPLY}" -eq 0 ]; then
    echo "DRY-RUN: would POST ${P} — disables Memory for the WHOLE workspace and queues"
    echo "  deletion of every member's About You summary cache (TRAP 8). The Admin API says saved"
    echo "  memories are kept; help 9295112 says a workspace owner's Memory-off deletes them (TRAP 2)."
    echo "  Validate on a non-production workspace first, and capture GET .../users/{user_id}/memories"
    echo "  for affected members before --apply. Re-run with --apply and"
    echo "  HTH_CONFIRM_WORKSPACE=${CHATGPT_WORKSPACE_ID} to execute."
    exit 0
  fi
  [ "${HTH_CONFIRM_WORKSPACE:-}" = "${CHATGPT_WORKSPACE_ID}" ] \
    || cgpt_die "--workspace --apply needs HTH_CONFIRM_WORKSPACE=${CHATGPT_WORKSPACE_ID} (TRAP 8)"
  post_delete_and_disable "${P}"
  case "${CGPT_CODE}" in
    202) if jq -e '.status == "accepted"' "${CGPT_BODY}" >/dev/null 2>&1; then
           echo "ACCEPTED: workspace Memory disabled; deletion request $(jq -r '.id' "${CGPT_BODY}") queued (asynchronous)"
         else
           echo "FAIL: HTTP 202 without status \"accepted\""; FAILED=1
         fi ;;
    503) echo "PARTIAL: Workspace Memory was disabled, but the deletion request could not be queued — re-run --apply"; FAILED=1 ;;
    500) echo "FAIL: the workspace setting or deletion request could not be persisted"; FAILED=1 ;;
    *)   cgpt_fail_http POST "${P}" ;;
  esac
else
  DONE=0; i=0
  for U in "${USERS[@]}"; do
    i=$((i + 1))
    P="/compliance/workspaces/${CHATGPT_WORKSPACE_ID}/users/${U}/memory/delete_and_disable"
    if [ "${APPLY}" -eq 0 ]; then
      echo "DRY-RUN: would POST ${P}"
      continue
    fi
    post_delete_and_disable "${P}"
    case "${CGPT_CODE}" in
      200) if jq -e '.status == "completed"' "${CGPT_BODY}" >/dev/null 2>&1; then
             echo "DISABLED: ${U} — Memory off, About You summary cache and M3M dream data deleted (saved memories kept per the API, TRAP 2)"
             DONE=$((DONE + 1))
           else
             echo "FAIL: ${U} — HTTP 200 without status \"completed\""; FAILED=$((FAILED + 1))
           fi ;;
      404) echo "FAIL: ${U} — the user or workspace was not found"; FAILED=$((FAILED + 1)) ;;
      500) echo "FAIL: ${U} — the setting update, cache invalidation, or a scoped deletion failed; state unknown, check the member's Memory setting"
           FAILED=$((FAILED + 1)) ;;
      401|403|429|000)
           # Key-level or quota-level: every later POST would fail the same way.
           if [ $((DONE + FAILED)) -eq 0 ] && [ "${CGPT_CODE}" != "000" ]; then
             cgpt_fail_http POST "${P}"            # nothing written yet: a true precondition
           fi
           if [ "${CGPT_CODE}" = "000" ]; then
             echo "FAIL: ${U} — no HTTP response; state unknown, check the member's Memory setting (TRAP 10)"
           else
             echo "FAIL: ${U} — HTTP ${CGPT_CODE} after ${CGPT_RETRIES} retr(y/ies); stopping (TRAP 10)"
           fi
           FAILED=$((FAILED + 1))
           echo "  ${DONE} member(s) already disabled above"
           [ "${i}" -ge "${#USERS[@]}" ] || echo "NOT ATTEMPTED (re-run with these IDs): ${USERS[*]:i}"
           break ;;
      *)   echo "FAIL: ${U} — HTTP ${CGPT_CODE}. Body: $(head -c 300 "${CGPT_BODY}" 2>/dev/null | tr '\n' ' ')"
           FAILED=$((FAILED + 1)) ;;
    esac
  done
  [ "${APPLY}" -eq 1 ] || echo "DRY-RUN complete — nothing written. Re-run with --apply to execute."
fi

[ "${APPLY}" -eq 0 ] || echo "VERIFY: the API cannot read Memory state (TRAP 1) — confirm Settings > Personalization > Memory is off for each member."
[ "${FAILED}" -eq 0 ] || exit 1
exit 0

What the API pack calls:

User endpoint (default): POST /compliance/workspaces/{workspace_id}/users/{user_id}/memory/delete_and_disable (chatgpt.enterprise.compliance_export delete scope). It deletes the member’s About You summary cache and configured M3M dream data (200).
Workspace endpoint: with --workspace, POST /compliance/workspaces/{workspace_id}/memory/delete_and_disable (202, asynchronous), which also requires HTH_CONFIRM_WORKSPACE. It disables Memory and queues that deletion for every member (202).
Dry run by default: the pack defaults to a dry run.
One-way: neither endpoint deletes saved memories, conversation history, or archives, and neither has a re-enable endpoint.
Dot notes: the endpoints’ effect on dot notes is undocumented. The dots docs say only that changing a ChatGPT saved-memory setting “doesn’t necessarily change the notes your dot has already made” (Tasks and memory).
Other memory routes: the route that removes an individual saved memory is Delete Memory Entry (DELETE .../users/{user_id}/memory_contexts/{memory_context_id}/memories/{memory_id}), which the pack does not call. GET .../users/{user_id}/memories reads ChatGPT memories; whether dot notes appear there is undocumented.

Audit records: each call is logged as an AUDIT_LOG event. The Admin API reference’s Version History (2.2.0) says “Compliance API Requests are now all logged as AUDIT_LOG events”, with actor.type API_KEY.

Its Memory Controls tag names the actions DELETE_AND_DISABLE_USER_MEMORY (user_id) and DELETE_AND_DISABLE_WORKSPACE_MEMORY (workspace_id). The Audit tag’s own action catalog does not list them, so confirm the action name a live tenant records.
No named action is documented for a member turning off their own Memory in Settings > Personalization > Memory, and the generic WORKSPACE_TOGGLE_FEATURE documents no Memory feature identifier.

Automation: ClickOps only on Pro and Business Premium — OpenAI exposes no admin write interface for memory on these plans; the Admin API serves ChatGPT Enterprise administrators (Admin API reference, 2026-10-09).

Validation & Testing

Confirm Memory is off for in-scope members, or for the workspace where that lever is used
On Enterprise, run the 5.2 pack in dry-run mode first, then call the user endpoint for one test member
- Confirm in the member’s UI that Memory shows off and that new dot conversations no longer surface ChatGPT memories. Record either result as evidence
- Retrieve the matching AUDIT_LOG event from the Compliance Logs Platform (expected action DELETE_AND_DISABLE_USER_MEMORY, action_data.user_id = the test member, action_result SUCCESS) and keep it with the pack’s output
On Pro, confirm Improve the model for everyone is off

Expected result: Members who handle regulated data share no ChatGPT memory with their dot, and you have evidence of what the Enterprise endpoint actually does.

Compliance Mappings

Framework	Control ID	Control Description
CIS Controls v8	3.1	Establish and Maintain a Data Management Process
CIS Controls v8	3.4	Enforce Data Retention
NIST 800-53	SI-12	Information Management and Retention
NIST 800-53	PT-2	Authority to Process Personally Identifiable Information
NIST 800-53	AC-4	Information Flow Enforcement
SOC 2	C1.1, P4.1	Identification and maintenance of confidential information; use of personal information limited to identified purposes
Benchmark	None	No benchmark equivalent yet

6. Monitoring & Audit

6.1 Ingest the Compliance Logs Platform records that cover dots, and prove coverage with a test task

Profile Level: L2 (Walk)

Framework	Control
CIS Controls v8	8.2, 8.9, 8.11
NIST 800-53	AU-2, AU-6, AU-11, AU-12

Description

Pull CONVERSATION_MESSAGE, APP_LOG, APP_AUTH_LOG and CODEX_LOG from the Compliance Logs Platform continuously, with a fine-grained read scope per type. Then run a representative dot task and compare the exported records with what the dot actually did.

Why this source: it is the only documented admin audit-record source for dot activity, and OpenAI itself tells admins to confirm record coverage before relying on it. The dots admin guide sends investigations to supported Compliance API records: “Use supported Compliance API records to investigate user messages and dots’ replies. Confirm record coverage before relying on it for an audit.”

Attribution limits:

There is no dots event type, mode or actor type.
CONVERSATION_MESSAGE conversation.mode is chat or work “when available”, and the actor types are ACCOUNT_USER, API_KEY and EXTERNAL_COLLABORATION_USER.
author.type does separate user from assistant messages, and CODEX_LOG carries an optional agent attribution object whose values are not enumerated. Attributing actions to the dot must therefore be an explicit objective of the test task.
APP_LOG conversation_id “may be null for background or system initiated calls” (Admin API reference).
“Cloud orchestration events do not reach your existing OpenTelemetry collector” (Cloud and local access).

Delivery contract:

30-day file retention, p99 under 30 minutes, at-least-once delivery. Deduplicate on event_id.
List Files requires event_type and after, orders by end_time, and pages on last_end_time.
Download File answers with a 307 to a short-lived signed URL.
Get Freshness (max_event_time) requires event_type, and “This timestamp does not guarantee that all earlier events have arrived.”
OpenAI publishes a first-party download script.

Coverage test: test coverage, as the dots-specific pages direct.

The dots admin guide says “Confirm record coverage before relying on it for an audit”, and Cloud and local access says “For dots, use … the Compliance API for supported audit records. Validate the records your workflow needs”.
The test borrows its method from the Compliance API page’s procedure for Local computer access with Work Cloud: “Run a representative task and compare the exported records with the actions performed” (Compliance API).
Cover a message, an app read, an app write, a cloud-browser step and a schedule.

Scope and plans: Enterprise, Edu and Healthcare.

Admin keys “are available for eligible managed ChatGPT workspaces, including ChatGPT Enterprise, ChatGPT Edu, and ChatGPT for Healthcare workspaces” (Managing Admin keys in Admin Console).
The pricing matrix lists the Compliance API and audit logs as unavailable on Business, so Business Premium and Pro dots have no exportable admin audit record.

This pack versus the Enterprise guide’s 6.6:

This section’s pack is the ingestion path for dots. Its default types are CONVERSATION_MESSAGE, APP_LOG, APP_AUTH_LOG and CODEX_LOG.
Set HTH_CLP_EVENT_TYPES=AUTH_LOG for the 1.2 rule and HTH_CLP_EVENT_TYPES=AUDIT_LOG for the 2.1, 4.2 and 6.2 rules, each with its own single-type key.
To retain records beyond the 30-day window, write its output to immutable storage as the ChatGPT Enterprise guide’s 6.6 describes.
Do not run that guide’s 6.6 script as-is. Its event-type list (CONVERSATION_LOG, FILE_LOG, GPT_LOG, MEMORY_LOG, USER_LOG, agent., connector., skill.used, trigger., memory.) comes from a retired PDF. Of the types this guide relies on, it includes only AUTH_LOG; it omits CONVERSATION_MESSAGE, APP_LOG, APP_AUTH_LOG, CODEX_LOG and AUDIT_LOG, which the Admin API reference (v2.5.37) documents.
That reference is also public, not login-gated as 6.6 states.

Rationale

Why This Matters:

This is the only documented admin audit-record source for dot activity. Activity View is member-side, and the vendor says MCP hooks “are not a substitute for audit coverage”.
Coverage is explicitly unconfirmed by the vendor.
Endpoint monitoring cannot see hosted execution.

Attack Prevented: Undetected misuse, and missing evidence for a post-incident timeline.

Prerequisites

ChatGPT Enterprise, Edu or Healthcare
A workspace owner, because this key includes the owner-only Conversation messages permission (“Only workspace owners can grant broad compliance access or access to Conversation messages”)
- Workspace admins can create Admin keys but cannot grant that permission (Managing Admin keys in Admin Console)

ClickOps Implementation

Step 1: Create a narrowly scoped Admin key

Navigate to: Admin Console (https://admin.openai.com/) > select tenant if needed > select the ChatGPT workspace > Credentials > Admin keys > Create new admin key (Managing Admin keys in Admin Console)
Enter a name and choose an expiration
Choose the Custom preset (not Read only, which “grants the available read-only permissions for the selected workspace”, conversation content included). Set each needed category to Read and leave all others at None
- Categories you need: the Compliance Logs Platform’s Conversation messages (owner-only), app logs, app auth logs and Codex logs
- Matching scopes: chatgpt.enterprise.compliance_logs_platform.conversation_message.read, .app_log.read, .app_auth_log.read and .codex_log.read
- UI labels: the exact labels for the app log, app auth log and Codex log categories are not documented. The documented labels are the broad Compliance logging platform > Read and Conversation messages
Submit, then copy the secret, which is shown once

Step 2: Run the coverage test

As a pilot member, run a dot task that sends a message, reads an app, writes to an app, takes a cloud-browser step and creates a schedule
Record which exported records show each action

Code Implementation

Code Pack: API Script

hth-chatgpt-dots-6.01-pull-dots-compliance-records.sh View source on GitHub ↗

# Newest retained event per type, and its age. Reported, never scored (TRAP 7).
clp_freshness "${EVENT_TYPES[@]}"
NOW="$(hth_now_epoch)"
echo "=== Freshness (p99 SLA: under 30 minutes from event to file) ===" >&2
jq -r --argjson now "${NOW}" 'to_entries[]
  | if .value == null then "  \(.key): null — no retained file with a stored maximum event timestamp"
    else (try (.value | sub("\\.[0-9]+"; "") | sub("\\+00:00$"; "Z") | fromdateiso8601) catch null) as $t
      | if $t == null then "  \(.key): \(.value)  (age not computed: unrecognised timestamp form)"
        else "  \(.key): \(.value)  (\((($now - $t) / 60) | floor) min old)" end
    end' <<<"${CLP_FRESHNESS}" >&2

# Pull every file for each type in the window, verify, de-duplicate, emit NDJSON.
RAW="${CGPT_TMPDIR}/raw.jsonl"
DEDUPED="${CGPT_TMPDIR}/deduped.ndjson"
: > "${RAW}"
echo "=== Pull: after=${AFTER}${BEFORE:+ before=${BEFORE}} ===" >&2
for ET in "${EVENT_TYPES[@]}"; do
  clp_pull "${ET}" "${AFTER}" "${BEFORE}" "${RAW}"
  echo "  ${ET}: ${CLP_FILES} file(s) verified against file_sha256" >&2
  if [ -n "${CLP_LAST_END_TIME}" ]; then
    echo "  checkpoint: next run HTH_CLP_EVENT_TYPES=${ET} HTH_CLP_AFTER='${CLP_LAST_END_TIME}'  (exclusive — TRAP 5)" >&2
  fi
done
clp_dedupe "${RAW}" "${DEDUPED}"
RAW_N="$(jq -r '1' "${RAW}" | wc -l | tr -d ' ')"
OUT_N="$(wc -l < "${DEDUPED}" | tr -d ' ')"
echo "  ${RAW_N} record(s) pulled, ${OUT_N} after event_id de-duplication" >&2
if [ -n "${HTH_CLP_OUT:-}" ]; then
  cat "${DEDUPED}" >> "${HTH_CLP_OUT}"
  echo "  appended to ${HTH_CLP_OUT} (mode 0600 if newly created)" >&2
elif [ "${MODE}" = "pull" ]; then
  cat "${DEDUPED}"
fi

# Evidence for the test-task diff: run a representative dot task (a message, an
# app read, an app write, a cloud-browser step, a schedule), pull a window that
# brackets it, then hold every row below against what the dot actually did.
# Optional HTH_CLP_ACTOR_EMAIL narrows to the dot owner's records.
EMAIL="$(printf '%s' "${HTH_CLP_ACTOR_EMAIL:-}" | tr '[:upper:]' '[:lower:]')"
jq -s -r --arg email "${EMAIL}" '
  def owner: $email == "" or ((.actor.user_email // "") | ascii_downcase) == $email;
  def table($rows): $rows | group_by(.) | map("    \(length)\t\(.[0])") | .[];
  [ .[] | select(owner) ] as $r
  | "=== Coverage\(if $email == "" then "" else " for actor " + $email end): \($r | length) record(s) ===",
    "  by type / actor.type:",
    table([ $r[] | "\(.type)  actor=\(.actor.type // "?")" ]),
    "  CONVERSATION_MESSAGE by author.type / conversation.mode / client_type (TRAP 1):",
    table([ $r[] | select(.type == "CONVERSATION_MESSAGE")
            | "author=\(.message.author.type // "?")  mode=\(.conversation.mode // "(absent)")  client=\(.message.author.client_type // "-")" ]),
    "  APP_LOG by app / log_type / conversation_id null (TRAP 2):",
    table([ $r[] | select(.type == "APP_LOG")
            | "\(.app_name // .app_id // "?")  \(.log_type // "?")  conversation_id_null=\(.conversation_id == null)" ]),
    "  APP_AUTH_LOG by action / app_id:",
    table([ $r[] | select(.type == "APP_AUTH_LOG") | "\(.action // "?")  app=\(.app_id // "(null)")" ]),
    "  CODEX_LOG by event_type / agent.type / client_id (TRAP 3):",
    table([ $r[] | select(.type == "CODEX_LOG")
            | "\(.event_type // "?")  agent=\(.agent.type // "(none)")  client=\(.client_id // "?")" ])
' "${DEDUPED}"
echo "Record, per test action: which row above (if any) shows it, and whether it is attributable to the dot."

What the pack does: it performs the ingestion itself, through List Files (GET https://api.chatgpt.com/v1/compliance/workspaces/{workspace_id}/logs, event_type and after required), Download File and Get Freshness.
Console step: creating the Admin key it authenticates with is a console step (help 20001407).
No other surface: no Terraform resource, CLI command or SDK covers the ChatGPT Compliance API (openai-python and openai-node carry no compliance or ChatGPT paths).

Validation & Testing

After the test task, confirm that each action appears in some exported record, and record whether each can be attributed to the dot rather than the owner
Document the gaps
Check max_event_time freshness against the 30-minute p99, remembering that it does not guarantee completeness

Expected result: Continuous ingestion of the four record types, plus a written record of which dot actions they cover and which they miss.

Compliance Mappings

Framework	Control ID	Control Description
CIS Controls v8	8.2	Collect Audit Logs
CIS Controls v8	8.9	Centralize Audit Logs
CIS Controls v8	8.11	Conduct Audit Log Reviews
NIST 800-53	AU-2	Event Logging
NIST 800-53	AU-6	Audit Record Review, Analysis, and Reporting
NIST 800-53	AU-11	Audit Record Retention
NIST 800-53	AU-12	Audit Record Generation
SOC 2	CC7.2	Monitoring of system components for anomalies
Benchmark	None	No benchmark equivalent yet

6.2 Alert on governance changes that widen what dots can reach

Profile Level: L2 (Walk)

Framework	Control
CIS Controls v8	8.11, 6.8
NIST 800-53	AU-6, CM-3, AC-2(4), SI-4

Description

Alert on every role, group, app-access, plugin sharing and installation-policy, feature-toggle and Agent Security change in the ChatGPT AUDIT_LOG and the API Platform tenant RBAC feed, and route each one to review. Dots permissions have no write API, so detection is the only automated control.

ChatGPT AUDIT_LOG actions (Admin API reference, Audit tag):

Role actions: ROLE_CREATE, ROLE_UPDATE (permissions_added / permissions_removed), ROLE_DELETE, ROLE_ASSIGN, ROLE_UNASSIGN, USER_ROLE_UPDATED, ROLE_SET_PLUGIN_PERMISSIONS, ROLE_SET_CONNECTOR_PERMISSIONS, ROLE_SET_ALL_CONNECTOR_PERMISSIONS and ROLE_UPDATE_BINDING_PERMISSIONS
App and plugin actions: APP_UPDATE_ACCESS_POLICY, APP_ALLOW_USER, APP_PUBLISH, APP_SET_ENABLED_ACTIONS, PLUGIN_SHARE and PLUGIN_UPDATE_INSTALLATION_POLICY
Group actions: GROUP_ADD_USERS and GROUP_EDIT
Workspace actions: WORKSPACE_TOGGLE_FEATURE and WORKSPACE_SET_POLICY

Admin API requests use different actions: Admin API requests made with an Admin key are logged under the spec’s “API key actions” (actor.type API_KEY): “Compliance API endpoint requests and Admin API endpoint requests use the actions documented in this section”.

An Add Group User call (POST /manage/workspaces/{workspace_id}/groups/{group_id}/users) emits ADD_WORKSPACE_DIRECTORY_GROUP_USER (workspace_id, group_id, user_id), not GROUP_ADD_USERS.
An Update Workspace User call (built-in role or seat) emits UPDATE_WORKSPACE_USER (Workspace Users tag).
The action emitted by Bulk Add Group Users and by SCIM-driven membership changes is not documented.

Shared RBAC: the spec also says “Many of these permissions and role changes have been moved to a shared RBAC system. These logs must be enabled and then are accessible through API Platform.”

API Platform tenant feed (API Platform audit logs):

Tenant events: tenant.custom_role.created / updated, tenant.role_assignment.created / deleted, tenant.group.member.added / removed and tenant.resource_role_assignment.created / deleted. The tenant.* names appear only as event-type values, with no payload schema.
Resource bindings: role.bound_to_resource and role.unbound_from_resource, the documented examples that require tenant_only and cover ChatGPT workspace connector roles.
Role events: role.created, role.updated, role.deleted, role.assignment.created and role.assignment.deleted. role.updated is the only type with a documented permission diff (changes_requested.permissions_added / permissions_removed). Some role.* events concern API Platform organization or project roles (their resource_type, for example api.organization or api.project), not ChatGPT workspace roles.

Removals too: because roles may combine additively or with an explicit-Off deny (8.1 row f), role removals (ROLE_UNASSIGN, ROLE_DELETE) are matched as well as grants.

What is not documented. No vendor doc states that a dots grant emits tenant.custom_role.updated, so do not assume the tenant feed carries permission diffs until a live tenant captures one. The dots permission identifier strings are undocumented (only UI labels are), so these rules match the action and route every change to review. Capture the real identifiers during live validation to narrow them.

Rationale

Why This Matters:

Dots role permissions and capability toggles have no write API, so drift detection is the only automated control on them. Group membership and Agent Security Global settings do have write paths (the group API, and the vendor-referenced policy API), which makes them attack paths to watch too.
A single role edit or group addition can grant local computer access or permissive rules to a whole group.

Attack Prevented: Silent privilege expansion for dots, by an insider or a compromised admin.

Prerequisites

ChatGPT Enterprise or Edu
API Platform audit logs enabled for the tenant RBAC events, read with an API Platform admin key (OPENAI_ADMIN_KEY), which is a different key from the ChatGPT Admin key

ClickOps Implementation

Step 1: Create a ChatGPT Admin key scoped to the audit log only

Navigate to: OpenAI Admin Console (https://admin.openai.com/credentials?tab=admin-keys) > Credentials > Admin keys > Create new admin key > choose the workspace > Custom
Grant only the AUDIT_LOG fine-grained read scope, chatgpt.enterprise.compliance_logs_platform.audit_log.read. Its UI label is not documented
- Do NOT use the documented broad label Compliance logging platform > Read, which grants chatgpt.enterprise.compliance_logs_platform.read across every log type, conversation content included

Step 2: Enable the API Platform tenant feed

Enable API Platform audit logs for the tenant RBAC events. The Admin API’s AUDIT_LOG note says “These logs must be enabled and then are accessible through API Platform”
- Neither that note nor the audit logs list reference documents where to enable them. Capture the console path during live validation (8.11)
Provision an API Platform admin key (OPENAI_ADMIN_KEY) to read them

Step 3: Know what you are watching

The dots grants being monitored live at Workspace settings > Permissions & roles; record their current state so alerts can be triaged against it

Code Implementation

Code Pack: API Script

hth-chatgpt-dots-6.02-tenant-rbac-audit.sh View source on GitHub ↗

# API Platform audit logs: tenant RBAC events (custom roles, role assignments,
# group membership, resource role bindings) and the role.* family. Read-only GET,
# one event type per request (TRAP 3).
OPENAI_API_BASE="${OPENAI_API_BASE:-https://api.openai.com/v1}"
TENANT_TYPES="${HTH_TENANT_EVENT_TYPES:-tenant.custom_role.created,tenant.custom_role.updated,tenant.custom_role.deleted,tenant.role_assignment.created,tenant.role_assignment.deleted,tenant.group.member.added,tenant.group.member.removed,tenant.resource_role_assignment.created,tenant.resource_role_assignment.deleted,role.bound_to_resource,role.unbound_from_resource}"
ROLE_TYPES="${HTH_ROLE_EVENT_TYPES:-role.created,role.updated,role.deleted,role.assignment.created,role.assignment.deleted}"

_oai_auth() { printf 'header = "Authorization: Bearer %s"\n' "${OPENAI_ADMIN_KEY}"; }

# tenant_query <event_type> <tenant_only: true|false> <scope label>
# Prints every page's events as NDJSON on stdout and a summary on stderr; adds
# the count to TQ_FOUND. Returns 1 (after reporting) on a rejected type, so the
# caller can retry or record it; 401/403/no response stop the run.
TQ_FOUND=0
tenant_query() {
  local t="$1" only="$2" scope="$3" after="" pages=0 code rc snippet n
  local tenant_arg=()
  [ "${only}" = "true" ] && tenant_arg=(--data-urlencode "tenant_only=true")
  while :; do
    local page=()
    [ -z "${after}" ] || page=(--data-urlencode "after=${after}")
    set +e
    code="$(_oai_auth | curl -sS -g -G -K - -o "${CGPT_BODY}" -w '%{http_code}' \
      "${OPENAI_API_BASE}/organization/audit_logs" \
      ${tenant_arg[@]+"${tenant_arg[@]}"} --data-urlencode "event_types[]=${t}" \
      --data-urlencode "effective_at[gte]=${SINCE_EPOCH}" --data-urlencode "limit=100" \
      ${page[@]+"${page[@]}"} 2>/dev/null)"
    rc=$?
    set -e
    [ "${rc}" -eq 0 ] || cgpt_die "GET /organization/audit_logs — no HTTP response (curl exit ${rc})"
    if [ "${code}" != "200" ]; then
      snippet="$(head -c 300 "${CGPT_BODY}" | tr '\n' ' ')"
      case "${code}" in
        401|403) cgpt_die "audit_logs HTTP ${code} — OPENAI_ADMIN_KEY is invalid or not an organization Admin key, or audit logging is not enabled (TRAP 4). Body: ${snippet}" ;;
        *) echo "  ${t} (tenant_only=${only}): HTTP ${code} — ${snippet}" >&2; return 1 ;;
      esac
    fi
    jq -e '(.data | type == "array") and (.has_more | type == "boolean")' "${CGPT_BODY}" >/dev/null 2>&1 \
      || cgpt_die "audit_logs returned HTTP 200 without the documented {data[], has_more} shape"
    jq -c '.data[]' "${CGPT_BODY}"
    jq -r --arg scope "${scope}" '.data[] | "  \(.effective_at | todate)  \(.type)  scope=\($scope)  actor="
           + "\(.actor.session.user.email // .actor.api_key.user.email // .actor.api_key.service_account.id // .actor.api_key.id // "?")"
           + "  details=\(.[.type] // "(no documented payload — TRAP 2)" | tojson | .[0:300])"' "${CGPT_BODY}" >&2
    n="$(jq '.data | length' "${CGPT_BODY}")"
    TQ_FOUND=$((TQ_FOUND + n))
    pages=$((pages + 1))
    [ "$(jq -r '.has_more' "${CGPT_BODY}")" = "true" ] || break
    after="$(jq -r '.last_id // ""' "${CGPT_BODY}")"
    [ -n "${after}" ] || cgpt_die "audit_logs: has_more is true but last_id is null — cannot page safely"
    [ "${pages}" -lt 1000 ] || cgpt_die "audit_logs: more than 1000 pages — runaway guard"
  done
}

tenant_audit() {
  [ -n "${OPENAI_ADMIN_KEY:-}" ] || cgpt_die "set OPENAI_ADMIN_KEY — an API Platform Admin key (needed for --feed tenant)"
  local t types=() roles=()
  IFS=',' read -r -a types <<<"${TENANT_TYPES}"
  IFS=',' read -r -a roles <<<"${ROLE_TYPES}"
  for t in ${types[@]+"${types[@]}"} ${roles[@]+"${roles[@]}"}; do
    [[ "${t}" =~ ^[a-z_.]+$ ]] || cgpt_die "event type '${t}' is not a lower-case audit-log type"
  done
  echo "=== Tenant RBAC audit log (API Platform), effective_at >= ${SINCE} ===" >&2
  TQ_FOUND=0
  for t in ${types[@]+"${types[@]}"}; do
    tenant_query "${t}" true tenant || INCOMPLETE=1
  done
  # role.* may not be tenant-scoped: try tenant_only first, then once without it.
  for t in ${roles[@]+"${roles[@]}"}; do
    tenant_query "${t}" true tenant || tenant_query "${t}" false org || INCOMPLETE=1
  done
  echo "  ${TQ_FOUND} tenant RBAC / role event(s)" >&2
  TENANT_FOUND="${TQ_FOUND}"
  CHANGES=$((CHANGES + TQ_FOUND))
}

# ChatGPT Compliance Logs Platform AUDIT_LOG: the governance actions that can
# widen dots' reach (role permissions and assignments, role deletion, member
# role and seat updates, group membership by console or Admin API, app access,
# publication and action controls, plugin sharing and installation policy,
# feature toggles, Agent Security policy saves). A superset of the two 6.02
# Sigma rules plus APP_SET_ENABLED_ACTIONS (2.01 rule) and WORKSPACE_SET_POLICY
# (4.02 rule). Removals of a user from a group are left out (TRAP 6). Read-only.
GOVERNANCE_ACTIONS='["ROLE_CREATE","ROLE_UPDATE","ROLE_DELETE","ROLE_ASSIGN","ROLE_UNASSIGN",
  "USER_ROLE_UPDATED","UPDATE_WORKSPACE_USER",
  "ROLE_SET_PLUGIN_PERMISSIONS","ROLE_SET_CONNECTOR_PERMISSIONS","ROLE_SET_ALL_CONNECTOR_PERMISSIONS",
  "ROLE_UPDATE_BINDING_PERMISSIONS","GROUP_ADD_USERS","GROUP_EDIT","ADD_WORKSPACE_DIRECTORY_GROUP_USER",
  "APP_UPDATE_ACCESS_POLICY","APP_ALLOW_USER","APP_PUBLISH","APP_SET_ENABLED_ACTIONS",
  "PLUGIN_SHARE","PLUGIN_UPDATE_INSTALLATION_POLICY","WORKSPACE_TOGGLE_FEATURE","WORKSPACE_SET_POLICY"]'

chatgpt_audit() {
  cgpt_require
  CGPT_SCOPE_HINT="chatgpt.enterprise.compliance_logs_platform.audit_log.read"
  local raw="${CGPT_TMPDIR}/audit-raw.jsonl" ded="${CGPT_TMPDIR}/audit.ndjson" hits="${CGPT_TMPDIR}/audit-hits.ndjson" n
  : > "${raw}"
  echo "=== ChatGPT AUDIT_LOG governance actions, files after ${SINCE} ===" >&2
  clp_pull AUDIT_LOG "${SINCE}" "" "${raw}"
  clp_dedupe "${raw}" "${ded}"
  jq -c --argjson acts "${GOVERNANCE_ACTIONS}" --argjson since "${SINCE_EPOCH}" '
      select(.action as $a | $acts | any(.[]; . == $a))
      | select(((try (.timestamp | sub("\\.[0-9]+"; "") | sub("\\+00:00$"; "Z") | fromdateiso8601) catch null) // $since) >= $since)' \
      "${ded}" > "${hits}"
  cat "${hits}"
  jq -r '"  \(.timestamp)  \(.action)  result=\(.action_result // "?")  actor=\(.actor.user_email // .actor.redacted_id // .actor.type // "?")"
         + "  data=\(.action_data // {} | tojson | .[0:300])"' "${hits}" >&2
  n="$(wc -l < "${hits}" | tr -d ' ')"
  echo "  ${n} governance action(s) from ${CLP_FILES} AUDIT_LOG file(s)" >&2
  if [ -n "${CLP_LAST_END_TIME}" ]; then
    echo "  checkpoint: next run HTH_AUDIT_SINCE='${CLP_LAST_END_TIME}' (keep an overlap — TRAP 7)" >&2
  fi
  CHANGES=$((CHANGES + n))
}

Code Pack: CLI Script

hth-chatgpt-dots-6.02-tenant-rbac-audit.sh View source on GitHub ↗

# List RBAC changes that can widen what dots reach, from the API Platform audit log.
HOURS="${HTH_LOOKBACK_HOURS:-24}"
printf '%s' "$HOURS" | grep -E '^[1-9][0-9]*$' >/dev/null || {
  echo "PRECONDITION: HTH_LOOKBACK_HOURS must be a positive integer" >&2; exit 2; }
SINCE=$(( $(date +%s) - HOURS * 3600 ))

# Documented ChatGPT workspace connector-role events first, then the tenant RBAC
# events whose link to dots grants is unverified (TRAP 2), then the role.* family
# (role.updated carries the only documented permission diff).
EVENT_TYPES=(
  role.bound_to_resource role.unbound_from_resource
  tenant.custom_role.created tenant.custom_role.updated tenant.custom_role.deleted
  tenant.role_assignment.created tenant.role_assignment.deleted
  tenant.group.member.added tenant.group.member.removed
  tenant.resource_role_assignment.created tenant.resource_role_assignment.deleted
)
ROLE_TYPES=(
  role.created role.updated role.deleted role.assignment.created role.assignment.deleted
)

ERR=$(mktemp "${TMPDIR:-/tmp}/hth-dots-602.XXXXXX"); trap 'rm -f "$ERR"' EXIT
FOUND=0; FAILED=0

# list_type <event type> <scope: tenant|org> — one type per call (TRAP 3). The key
# travels in OPENAI_ADMIN_KEY, never in argv. Returns 1 if the CLI rejects the call.
list_type() {
  local type="$1" scope="$2" out rows bad
  local only=()
  [ "$scope" = "tenant" ] && only=(--tenant-only)
  if ! out=$(openai --format jsonl admin organization audit-logs list \
        ${only[@]+"${only[@]}"} --event-type "$type" --effective-at.gte "$SINCE" --limit 100 2>"$ERR"); then
    echo "  ERROR: $type (scope=$scope): $(head -c 300 "$ERR")" >&2; return 1
  fi
  # Count non-empty lines that are not a JSON object with a `type` (TRAP 5).
  bad=$(printf '%s\n' "$out" | jq -R -s -r 'split("\n") | map(select(length > 0))
    | map(select(((try fromjson catch null) as $o
                  | ($o | type) != "object" or ($o | has("type") | not))))
    | .[0:3][]')
  if [ -n "$bad" ]; then
    echo "  ERROR: $type (scope=$scope): unparseable CLI output: $(printf '%s' "$bad" | head -c 300)" >&2
    FAILED=1
  fi
  # Details live under a key named after the event type, e.g. ."role.bound_to_resource".
  rows=$(printf '%s\n' "$out" | jq -R -r --arg ws "${HTH_WORKSPACE_ID:-}" --arg scope "$scope" '
    fromjson? | select(type == "object" and has("type"))
    | (.[.type] // {}) as $d
    | select($ws == "" or (($d.workspace_id // $ws) == $ws))
    | [ (.effective_at | todate), .type, $scope,
        ($d.resource_type // $d.changes_requested.resource_type // "-"),
        (.actor.session.user.email // .actor.api_key.user.email
          // .actor.api_key.service_account.id // .actor.type // "unknown"),
        ($d | tojson) ] | @tsv')
  if [ -n "$rows" ]; then printf '%s\n' "$rows"; FOUND=1; fi
  return 0
}

printf 'effective_at\ttype\tscope\tresource_type\tactor\tdetails\n'
for TYPE in "${EVENT_TYPES[@]}"; do
  list_type "$TYPE" tenant || FAILED=1
done
# role.* may not be tenant-scoped: try --tenant-only first, then once without it.
for TYPE in "${ROLE_TYPES[@]}"; do
  list_type "$TYPE" tenant || list_type "$TYPE" org || FAILED=1
done

if [ "$FAILED" = 1 ]; then
  echo "INCOMPLETE: at least one event type could not be read or parsed; do not treat this window as clean" >&2; exit 2
fi
if [ "$FOUND" = 1 ]; then
  exit 1
fi
if [ "${HTH_TENANT_FEED_VERIFIED:-}" != "yes" ]; then
  echo "  UNVERIFIED: none in the last ${HOURS}h, and the feed has not been shown to carry a known test change (TRAP 4); set HTH_TENANT_FEED_VERIFIED=yes once it has" >&2; exit 3
fi
echo "  none in the last ${HOURS}h" >&2; exit 0

Code Pack: Sigma Detection Rules (2)

hth-chatgpt-dots-6.02-role-permission-change.yml View source on GitHub ↗

logsource:
    product: openai
    service: chatgpt-compliance
    definition: 'ChatGPT Compliance Logs Platform JSONL records with type AUDIT_LOG; nested keys flattened with dots (action_data.permissions_added)'
detection:
    selection_role_and_group:
        type: 'AUDIT_LOG'
        action:
            - 'ROLE_CREATE'
            - 'ROLE_UPDATE'
            - 'ROLE_DELETE'
            - 'ROLE_ASSIGN'
            - 'ROLE_UNASSIGN'
            - 'ROLE_SET_PLUGIN_PERMISSIONS'
            - 'ROLE_SET_CONNECTOR_PERMISSIONS'
            - 'ROLE_SET_ALL_CONNECTOR_PERMISSIONS'
            - 'ROLE_UPDATE_BINDING_PERMISSIONS'
            - 'GROUP_ADD_USERS'
            - 'GROUP_EDIT'
            - 'ADD_WORKSPACE_DIRECTORY_GROUP_USER'
            - 'UPDATE_WORKSPACE_USER'
    selection_member_role:
        type: 'AUDIT_LOG'
        action: 'USER_ROLE_UPDATED'
        action_data.role|exists: true
    condition: 1 of selection_*
fields:
    - timestamp
    - event_id
    - actor.type
    - actor.user_email
    - actor.redacted_id
    - action
    - action_result
    - action_privilege
    - action_data.workspace_id
    - action_data.role_id
    - action_data.role_name
    - action_data.permissions
    - action_data.permissions_added
    - action_data.permissions_removed
    - action_data.disallowed_permissions
    - action_data.disallowed_permissions_added
    - action_data.disallowed_permissions_removed
    - action_data.state
    - action_data.resource_type
    - action_data.resource_id
    - action_data.binding_removed
    - action_data.principal_id
    - action_data.principal_type
    - action_data.plugin_id
    - action_data.connector_id
    - action_data.group_id
    - action_data.group_name
    - action_data.new_name
    - action_data.email_addresses
    - action_data.added_user_id
    - action_data.user_id
    - action_data.role

hth-chatgpt-dots-6.02-workspace-feature-toggle-b.yml View source on GitHub ↗

logsource:
    product: openai
    service: chatgpt-compliance
    definition: 'ChatGPT Compliance Logs Platform JSONL records with type AUDIT_LOG; nested keys flattened with dots (action_data.feature)'
detection:
    selection_toggle:
        type: 'AUDIT_LOG'
        action: 'WORKSPACE_TOGGLE_FEATURE'
    selection_app_workspace_wide:
        type: 'AUDIT_LOG'
        action: 'APP_UPDATE_ACCESS_POLICY'
        action_data.allow_all_in_workspace: true
    selection_app_user_grant:
        type: 'AUDIT_LOG'
        action: 'APP_ALLOW_USER'
    selection_plugin_install_policy:
        type: 'AUDIT_LOG'
        action: 'PLUGIN_UPDATE_INSTALLATION_POLICY'
    selection_plugin_share:
        type: 'AUDIT_LOG'
        action: 'PLUGIN_SHARE'
    selection_app_publish:
        type: 'AUDIT_LOG'
        action: 'APP_PUBLISH'
    condition: 1 of selection_*
fields:
    - timestamp
    - event_id
    - actor.type
    - actor.user_email
    - action
    - action_result
    - action_privilege
    - action_data.feature
    - action_data.value
    - action_data.app_id
    - action_data.app_name
    - action_data.source_surface
    - action_data.context_plugin_id
    - action_data.affected_connector_ids
    - action_data.changed_fields
    - action_data.previous_workspace_permissions_by_connector
    - action_data.new_workspace_permissions_by_connector
    - action_data.allow_all_in_workspace
    - action_data.allowed_user_id
    - action_data.plugin_id
    - action_data.plugin_name
    - action_data.added_assignments
    - action_data.removed_assignments
    - action_data.discoverability_before
    - action_data.discoverability
    - action_data.installation_policy_before
    - action_data.installation_policy
    - action_data.installed_by_default_role_ids_before
    - action_data.installed_by_default_role_ids

The packs read two feeds with different keys.

ChatGPT AUDIT_LOG (ChatGPT Admin key): List Files (event_type=AUDIT_LOG, after required), then Download File.
- The API pack’s ChatGPT leg prints a filtered review list, not the SIEM feed.
- The Sigma rules here and in 2.1 and 4.2 match raw AUDIT_LOG JSONL, which the 6.1 pack lands (HTH_CLP_EVENT_TYPES=AUDIT_LOG HTH_CLP_OUT=<path>) with the Step 1 key.
API Platform feed (OPENAI_ADMIN_KEY):
- Through the API: GET https://api.openai.com/v1/organization/audit_logs?tenant_only=true&event_types[]=tenant.custom_role.updated
- Through the first-party openai CLI v1.38.0, whose admin commands cover the API Platform only: openai admin organization audit-logs list --tenant-only --event-type tenant.custom_role.updated
- openai-python types the same parameters.

Empty-feed guard:

The API pack queries each tenant event type in its own request, so a type the API rejects under tenant_only is reported without blinding the others.
When the tenant feed returns nothing, it exits 3 (“unverified”), not 0, unless HTH_TENANT_FEED_VERIFIED=yes records that the feed has been seen to carry a known test change. An empty feed looks the same as API Platform audit logging that is off.
The CLI twin behaves the same way.

Rule coverage:

The two 6.2 Sigma rules alert on role, role-assignment and group changes (including Admin API group adds and built-in role updates) and on feature toggles, app availability and publication, and plugin sharing and installation policy.
App action-control changes (APP_SET_ENABLED_ACTIONS) and Agent Security policy saves (WORKSPACE_SET_POLICY) are alerted by the 2.1 and 4.2 rules, so deploy all four for full coverage. The API pack matches all of them in one pass.

Detection, not prevention: the permissions these rules watch are themselves ClickOps only. Admin API v2.5.37 has no custom-role, permission or workspace-setting route (Admin API reference, 2026-10-09; see 8.3). This control detects changes, it does not prevent them.

Validation & Testing

Toggle Use dots (Beta) on a test role. Confirm a ROLE_UPDATE event, a tenant.custom_role.updated event or a role.updated event arrives, and record the identifier string and payload it carries
Add a user to the pilot group twice: once as a signed-in admin in the console, and once through the Admin API Add Group User endpoint
- Confirm the first produces GROUP_ADD_USERS or GROUP_EDIT (with added_user_id) and the second produces ADD_WORKSPACE_DIRECTORY_GROUP_USER (actor.type API_KEY), and that the role-permission-change rule fires on both
- Check the tenant feed for tenant.group.member.added, but treat its presence as unconfirmed until observed
Toggle Cloud browser use in the Workspace default and in a test role. Record whether ROLE_UPDATE, WORKSPACE_TOGGLE_FEATURE or tenant.custom_role.updated arrives, and the identifier it carries

Expected result: Every change that could widen a dot’s reach raises an alert within the feed’s delivery window, and you have captured the real identifiers.

Compliance Mappings

Framework	Control ID	Control Description
CIS Controls v8	8.11	Conduct Audit Log Reviews
CIS Controls v8	6.8	Define and Maintain Role-Based Access Control
NIST 800-53	AU-6	Audit Record Review, Analysis, and Reporting
NIST 800-53	CM-3	Configuration Change Control
NIST 800-53	AC-2(4)	Automated Audit Actions
NIST 800-53	SI-4	System Monitoring
SOC 2	CC7.2, CC8.1	Monitoring of system components for anomalies; change management
Benchmark	None	No benchmark equivalent yet

7. Lifecycle & Kill Switch

7.1 Rehearse the dots kill sequence: stop the dot’s work and revoke every grant

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls v8	17.4, 6.2
NIST 800-53	IR-4, AC-2, CM-3

Description

Rehearse the kill sequence on a test member. With a cooperative owner, the owner stops the dot’s work and the workspace owner then removes every grant; if the owner is unreachable or their account may be compromised, revoke first.

Why both halves: no admin pause, reset or delete of a member’s dot is documented. The admin side of the kill switch is revoking Use dots (Beta), and the dot’s owner has to stop its work.

The admin half:

The admin FAQ answer is “Revoke dots access through workspace permissions” (dots admin guide).
Help 20001554: remove a member’s access by reviewing “Use dots (Beta) in the workspace default and all roles assigned directly to the member or through groups, then remove every applicable grant” (Manage dots in ChatGPT workspaces). Removing every grant is safe under either reading of how roles combine (see the conflict in 1.1).
Revocation is not the whole job: “removing dots access does not replace disconnecting an app or signing out of a website” (dots admin guide). If an admin disables local computer access, “an already authorized local task may still be finishing” (Cloud and local access).

The owner half: no OpenAI page states whether the owner can still open the dot profile, Activity or Scheduled once Use dots (Beta) is revoked, or whether revocation stops in-flight or scheduled work (dots admin guide; help 20001554; Controls). Pause, Activity and Scheduled are the only documented ways to stop delegated tasks and future runs: “Pause stops your dot’s current main task. It doesn’t stop every delegated task or cancel future scheduled runs. Open a delegated task in Activity to inspect and stop that task. Open Scheduled to disable or delete the recurring task you want to end” (Controls).

Doc conflict — what Pause stops.

Controls says “Pause stops your dot’s current main task. It doesn’t stop every delegated task or cancel future scheduled runs”.

Getting started with your dot says Pause stops the dot “until you’re ready to resume”.

Use the conservative reading: stop delegated tasks in Activity and disable schedules in Scheduled separately.

The Help Center also names the profile sections In progress, Scheduled and Completed rather than Activity.

“Stopping work doesn’t undo completed actions.”

Two paths:

Path A, cooperative owner on an uncompromised account (the default drill): the owner stops the dot’s work first (Step 1), pausing the dot, stopping delegated tasks, disabling schedules and revoking computer access while those controls are known to be reachable. The workspace owner then removes every grant (Step 2).
Path B, owner unreachable or account suspected compromised: the workspace owner revokes every grant first (Step 2). The owner then attempts Step 1 as best effort and records what was still reachable. Cut channels at the source systems (Step 3) regardless.

Revocation runbook:

Remove the member from the dots group through the API (manually managed groups only). A SCIM-managed group returns 409 scim_managed_resource, so remove the member in the IdP, because a later sync can restore workspace-side changes.
Confirm in the console that no other grant remains, since the API cannot see roles, direct assignments or the workspace default.
Disconnect apps at the source systems, sign out of websites, and continue to 7.2.

Vendor monitoring: built-in safety monitoring “can pause or stop work when monitoring detects a safety concern”, but that is the vendor’s control, not yours.

Rationale

Why This Matters:

A persistent agent keeps acting after the incident is identified unless every channel is cut.
The admin side of the kill switch is partial by design, so the owner-side steps must be rehearsed.

Attack Prevented: Continued exfiltration or actions from a compromised or misbehaving dot.

Real-World Incidents:

OpenAI misalignment report, “Exposing a GitHub token in a public repository” (report updated 2026-09-25; incident 2026-05-27): a highly persistent internal model published a GitHub token. An internal model, not a dot; rationale for a rehearsed kill sequence.
OpenAI misalignment report, “Preparing for a restart after reading Slack” (report updated 2026-10-02; incident 2026-05-22): after reading a shutdown discussion in Slack, a persistent internal model saved handoff notes and considered a backup or restart job. OpenAI states “We do not consider this incident misalignment.” An internal model, not a dot.

Prerequisites

A workspace owner (only Owners create, delete, assign and unassign custom roles and set the workspace default; see 1.1 Prerequisites for what Admins and delegated group managers can edit)
The dot owner’s participation for the owner-side steps, in the ChatGPT desktop app

ClickOps Implementation

Path A (cooperative owner) runs Step 1 then Step 2. Path B (owner unreachable or compromised) inverts them: Step 2 first, then Step 1 as best effort.

Step 1: Stop the dot’s work (dot owner, ChatGPT desktop app, dot profile)

••• > Pause (to resume later, the profile shows “Paused • Tap to resume”)
Activity > {delegated task} > stop, for each delegated task
Scheduled > {task} > disable or delete, for each schedule
Computers > Your computer > Revoke access > confirm

Step 2: Revoke every grant (workspace owner)

Confirm the Workspace settings > Permissions & roles > Permissions > Workspace default > Workspace capabilities setting for Use dots (Beta) is Off (the 1.1 baseline). If it is On, switching it Off revokes dots for every member who inherits it, not only the test member
In every custom role assigned to the member directly or through a group, either stop the role granting Use dots (Beta) (Off, or Default once the workspace default is Off) or unassign the role
For a SCIM-managed group, remove the member in the IdP

Step 3: Cut the remaining channels

Disconnect the dot’s apps at the source systems
Sign the cloud browser out of websites through the dot profile’s Computers > Take over (7.2 Step 1). On Path A do this with Step 1, before revocation, because it needs the dot profile; on Path B, end sessions from each site’s own account settings where it allows that
Continue to 7.2

Code Implementation

Code Pack: API Script

hth-chatgpt-dots-7.01-revoke-dots-group-membership.sh View source on GitHub ↗

# Read-only: find each target in each dots group, and refuse SCIM-owned groups.
PLAN="${CGPT_TMPDIR}/plan.tsv"
: > "${PLAN}"
FAILED=0
IFS=',' read -r -a RAW_GROUP_IDS <<<"${HTH_DOTS_GROUP_IDS}"
GROUP_IDS=()
for GID in "${RAW_GROUP_IDS[@]+"${RAW_GROUP_IDS[@]}"}"; do
  GID="$(printf '%s' "${GID}" | tr -d '[:space:]')"
  if [ -n "${GID}" ]; then GROUP_IDS+=("${GID}"); fi
done
[ "${#GROUP_IDS[@]}" -gt 0 ] \
  || cgpt_die "HTH_DOTS_GROUP_IDS contained no group ID after splitting on commas"
for GID in "${GROUP_IDS[@]}"; do
  cgpt_safe_id "${GID}" "group ID"
  cgpt_get_ok "/manage/workspaces/${CHATGPT_WORKSPACE_ID}/groups/${GID}"
  jq -e '.source | IN("manual", "scim")' "${CGPT_BODY}" >/dev/null 2>&1 \
    || cgpt_die "Get Group ${GID} returned HTTP 200 without the documented source field"
  G_NAME="$(jq -r '.name // "(unnamed)"' "${CGPT_BODY}")"
  G_SOURCE="$(jq -r '.source' "${CGPT_BODY}")"
  ROSTER="${CGPT_TMPDIR}/roster-${GID}.jsonl"
  cgpt_paginate_cursor "/manage/workspaces/${CHATGPT_WORKSPACE_ID}/groups/${GID}/users" "${ROSTER}"
  MATCHES="$(jq -r --argjson t "${TARGETS_JSON}" --arg gid "${GID}" --arg gname "${G_NAME}" '
      select(((.id | ascii_downcase) as $i | $t | any(.[]; . == $i))
             or (((.email // "") | ascii_downcase) as $e | $e != "" and ($t | any(.[]; . == $e))))
      | [$gid, $gname, .id, (.email // "(no email)")] | @tsv' "${ROSTER}")"
  [ -n "${MATCHES}" ] || continue
  if [ "${G_SOURCE}" = "scim" ]; then
    while IFS=$'\t' read -r _ _ UID_ EMAIL; do
      echo "IdP ACTION REQUIRED: ${EMAIL} (${UID_}) is in SCIM-managed group ${G_NAME} — remove them in the IdP (TRAP 3)"
      FAILED=$((FAILED + 1))
    done <<<"${MATCHES}"
    continue
  fi
  printf '%s\n' "${MATCHES}" >> "${PLAN}"
done
jq -r -R -s --argjson t "${TARGETS_JSON}" '
    [split("\n")[] | select(length > 0) | split("\t") | (.[2] | ascii_downcase), (.[3] | ascii_downcase)] as $hit
    | $t[] | . as $want | select(($hit | any(.[]; . == $want)) | not)
    | "NOT IN ANY LISTED MANUAL GROUP: \(.) — already removed, SCIM-managed, or granted another way (TRAP 1)"' "${PLAN}"

# The write: one literal DELETE per (group, member). Dry-run unless --apply.
# A 429 is retried after Retry-After (TRAP 10); -D captures THIS response's headers.
CGPT_DELETE_RETRIES=5
delete_group_user() { # <path>
  local attempt=0 rc
  CGPT_RETRIES=0
  while :; do
    set +e
    CGPT_CODE="$(_cgpt_auth | curl -sS --path-as-is -K - -X DELETE -D "${CGPT_HDRS}" -o "${CGPT_BODY}" \
      -w '%{http_code}' "${CHATGPT_ADMIN_BASE}$1" 2>/dev/null)"
    rc=$?
    set -e
    [ "${rc}" -eq 0 ] || CGPT_CODE="000"
    if [ "${CGPT_CODE}" = "429" ] && [ "${attempt}" -lt "${CGPT_DELETE_RETRIES}" ]; then
      sleep "$(_cgpt_retry_after)"; attempt=$((attempt + 1)); CGPT_RETRIES="${attempt}"; continue
    fi
    return 0
  done
}

WRITES_DONE=0
while IFS=$'\t' read -r GID G_NAME UID_ EMAIL; do
  [ -n "${GID}" ] || continue
  cgpt_safe_id "${UID_}" "user ID"
  P="/manage/workspaces/${CHATGPT_WORKSPACE_ID}/groups/${GID}/users/${UID_}"
  if [ "${APPLY}" -eq 0 ]; then
    echo "DRY-RUN: would DELETE ${P}   (${EMAIL} from ${G_NAME})"
    continue
  fi
  delete_group_user "${P}"
  case "${CGPT_CODE}" in
    # The spec requires only workspace_id, group_id and user_id on a 200 body, so
    # a 200 echoing the IDs counts; the List User Groups verify below is the real check.
    200) if jq -e --arg u "${UID_}" --arg g "${GID}" \
             '.deleted == true or (.user_id == $u and .group_id == $g)' "${CGPT_BODY}" >/dev/null 2>&1; then
           echo "REMOVED: ${EMAIL} (${UID_}) from ${G_NAME}"; WRITES_DONE=$((WRITES_DONE + 1))
         else
           echo "FAIL: ${EMAIL} — HTTP 200 without deleted: true or the documented IDs"; FAILED=$((FAILED + 1))
         fi ;;
    409) echo "FAIL: ${EMAIL} — 409 conflict with directory state (SCIM-managed?): $(head -c 300 "${CGPT_BODY}")"
         FAILED=$((FAILED + 1)) ;;
    404) echo "FAIL: ${EMAIL} — not found (the workspace, user or group; possibly already removed — see verify)"
         FAILED=$((FAILED + 1)) ;;
    400) echo "FAIL: ${EMAIL} — HTTP 400 invalid request input: $(head -c 300 "${CGPT_BODY}")"; FAILED=$((FAILED + 1)) ;;
    401|403|429|000)
         if [ "${WRITES_DONE}" -eq 0 ] && [ "${CGPT_CODE}" != "000" ]; then
           cgpt_fail_http DELETE "${P}"            # nothing removed yet: a true precondition
         fi
         echo "FAIL: ${EMAIL} — HTTP ${CGPT_CODE} after ${CGPT_RETRIES} retr(y/ies)$([ "${CGPT_CODE}" = "000" ] && echo ' (no response; state unknown — see verify)')"
         FAILED=$((FAILED + 1))
         if [ "${CGPT_CODE}" != "429" ]; then
           echo "  stopping writes (TRAP 10); ${WRITES_DONE} removal(s) already landed above"
           break
         fi ;;
    *)   echo "FAIL: ${EMAIL} — HTTP ${CGPT_CODE}: $(head -c 300 "${CGPT_BODY}" 2>/dev/null | tr '\n' ' ')"
         FAILED=$((FAILED + 1)) ;;
  esac
done < "${PLAN}"

# Read-only proof: every group each member is still in. After --apply, the
# group just removed must be gone; any other group listed may still grant dots.
while IFS= read -r UID_; do
  [ -n "${UID_}" ] || continue
  cgpt_safe_id "${UID_}" "user ID"
  UG="${CGPT_TMPDIR}/user-groups-${UID_}.jsonl"
  cgpt_paginate_cursor "/manage/workspaces/${CHATGPT_WORKSPACE_ID}/users/${UID_}/groups" "${UG}"
  echo "=== ${UID_} is still in $(wc -l < "${UG}" | tr -d ' ') group(s) ==="
  jq -r '"  \(.name // "(unnamed)") (\(.id))  source=\(.source)"' "${UG}"
  [ "${APPLY}" -eq 1 ] || continue
  while IFS= read -r GID; do
    if jq -e --arg g "${GID}" 'select(.id == $g)' "${UG}" >/dev/null 2>&1; then
      echo "  FAIL: still listed in ${GID} after removal"; FAILED=$((FAILED + 1))
    fi
  done < <(awk -F'\t' -v u="${UID_}" '$3 == u {print $1}' "${PLAN}")
done < <(cut -f3 "${PLAN}" | sort -u)

echo ""
echo "FINISH THE SEQUENCE (no API exists for these — TRAPS 1, 4, 5, 9):"
echo "  Workspace owner: Workspace settings > Permissions & roles — Use dots (Beta) granted by no other"
echo "    custom role, direct role, or the Workspace default. Allow up to 5 minutes to propagate."
echo "  Dot owner, dot profile: ••• > Pause; stop delegated tasks in Activity; disable or delete"
echo "    Scheduled entries; Computers > Your computer > Revoke access. On Path A these steps belong"
echo "    BEFORE this pack runs; on Path B record whether they were still reachable (TRAP 9)."
echo "  Disconnect apps at the source systems, sign out of websites, then Reset (delete) the dot (control 7.2)."
echo "  Evidence: AUDIT_LOG DELETE_WORKSPACE_DIRECTORY_GROUP_USER for this pack's removals (GROUP_REMOVE_USER for"
echo "    console removals), via pack 6.01 HTH_CLP_EVENT_TYPES=AUDIT_LOG (p99 under 30 minutes) — TRAP 7."
[ "${APPLY}" -eq 1 ] || echo "DRY-RUN complete — nothing written. Re-run with --apply to execute."
[ "${FAILED}" -eq 0 ] || exit 1
exit 0

What the pack does: it removes the member from the dots group (DELETE /manage/workspaces/{workspace_id}/groups/{group_id}/users/{user_id}, chatgpt.enterprise.directory write scope) and confirms through GET /manage/workspaces/{workspace_id}/users/{user_id}/groups.
Limits: that is effective only when dots is granted solely through a manually managed group’s role (1.1). It returns 409 on SCIM groups, and its read confirms only that the member left the named group, not that no other grant remains.
Owner-side steps: Pause, stopping Activity tasks, disabling Scheduled entries and Revoke access are ClickOps only: OpenAI documents no admin or API interface for them (Admin API reference, 2026-10-08). On Path A they belong before the pack runs; on Path B they are unverified after it.
Audit records:
- A removal made by this pack (Admin API, actor.type API_KEY) is recorded in AUDIT_LOG as DELETE_WORKSPACE_DIRECTORY_GROUP_USER (workspace_id, group_id, user_id). A console removal is recorded as GROUP_REMOVE_USER (removed_user_id). ROLE_UNASSIGN or ROLE_UPDATE cover role-side revocation.
- Pull them with the 6.1 pack (HTH_CLP_EVENT_TYPES=AUDIT_LOG); 6.2’s governance filter deliberately leaves removals out.
- The API Platform feed may show tenant.group.member.removed, tenant.role_assignment.deleted or tenant.custom_role.updated, but no doc maps a workspace group removal to them.
- The spec does not say whether a single API removal also emits GROUP_REMOVE_USER.

Validation & Testing

Drill quarterly on a test member, on Path A
Time the sequence from the first owner-side step to the last grant removed
Confirm a DELETE_WORKSPACE_DIRECTORY_GROUP_USER (pack removal) or GROUP_REMOVE_USER (console removal) AUDIT_LOG record arrives, or tenant.group.member.removed in the API Platform feed
After the final revocation, confirm the dot is unavailable and no Scheduled entry remains
Once, on a test member with one Scheduled task and one running delegated task, run Path B and record:
- whether the member can still open the dot profile, Activity and Scheduled (including “the Scheduled section in ChatGPT”, help 20001530)
- whether the scheduled run still fires
- whether the delegated task keeps running

Expected result: A rehearsed, timed sequence that leaves no grant, no running task and no schedule.

Compliance Mappings

Framework	Control ID	Control Description
CIS Controls v8	17.4	Establish and Maintain an Incident Response Process
CIS Controls v8	6.2	Establish an Access Revoking Process
NIST 800-53	IR-4	Incident Handling
NIST 800-53	AC-2	Account Management (modify or remove access authorizations)
NIST 800-53	CM-3	Configuration Change Control
SOC 2	CC7.4	Response to identified security incidents
Benchmark	None	No benchmark equivalent yet

7.2 Reset (delete) the dot at offboarding or after sensitive exposure

Profile Level: L2 (Walk)

Framework	Control
CIS Controls v8	3.5, 6.2
NIST 800-53	PS-4, MP-6, SI-12

Description

Make Reset an owner step in offboarding and after any sensitive-data exposure; it deletes the dot and is the only way to clear its own context. Remove dot-derived ChatGPT memories first, so a replacement dot is not re-seeded with the same data.

What Reset deletes:

“Reset deletes your dot, including its conversations, saved memories, and scheduled tasks” (Getting started with your dot), and “the action cannot be undone” (Controls).
“Files, Codex threads, and ChatGPT conversations your dot created are stored separately. Deleting your dot does not delete them” (Dots FAQs).
Deleting “doesn’t undo changes already made in connected apps or recall messages already delivered to other people” (Controls).

What survives in ChatGPT Memory: deleting the dot does not clear what the dot shared into ChatGPT Memory.

Conversations with a dot “can contribute to memory in ChatGPT”, and “Any information that your dot has shared with ChatGPT Memory can be separately managed in ChatGPT Memory settings” (Dots FAQs). Separately, “Memories from your other ChatGPT conversations remain in place” (Dots FAQs).
A new dot “starts with context from ChatGPT memory” (Getting started), so delete-and-recreate can re-seed the new dot.
On Enterprise, admins can delete individual memory entries through the Compliance API. Do not use memory/delete_and_disable for this, because it “does not delete saved memories”.

Memory-off is not a purge: turning Memory off “does not delete information that your dot has already received”.

No admin path:

No admin path deletes a dot or its own context: the admin guide lists only grant and revoke, and the Admin API has no dot endpoint.
Dot-created artifacts stored elsewhere (conversations, Library files, Codex tasks) are admin-deletable on Enterprise through the Compliance API.
The learn.chatgpt.com user lifecycle guidance has no dots content. The dots admin guide recommends this step itself: “Review saved memories and reset options when handling sensitive data or offboarding.”

Doc conflicts.

learn.chatgpt.com calls the action Delete (“Use Delete to delete your dot”) without a menu location, and its section anchor is still #reset-your-dot; the Help Center calls it Reset.

The admin guide’s “Review saved memories” also sits oddly beside the FAQ’s “You currently cannot view, delete or directly modify individual dot memories”.

Rationale

Why This Matters:

Dot memory cannot be purged item by item (“You currently cannot view, delete or directly modify individual dot memories”), and it outlives app disconnection.
There is no admin path to delete a dot or its own context, so the step must be in the owner’s offboarding runbook.

Attack Prevented: Residual sensitive context in a departed or compromised member’s agent, and re-seeding of that context into a replacement dot.

ClickOps Implementation

Step 1: Offboarding checklist (the dot’s owner, before deprovisioning)

Export any results the business needs
Remove dot-derived entries from ChatGPT Memory
Disconnect the dot’s apps, and sign the cloud browser out of websites: open the dot’s profile, open its cloud computer under Computers, select Take over, sign out of each site, then select Return control
- Do this before Reset, because the cloud computer is reached only through the dot’s profile, and after Reset “you return to a new ChatGPT chat” (Getting started with your dot; Computers and apps)
Navigate to: Dot profile > ••• menu > Reset, review what will be deleted, then select Reset to confirm

Website sessions: Reset’s documented scope is conversations, saved memories and scheduled tasks. Neither it nor the FAQ (“This deletes your dot’s own context”) says what happens to the cloud browser’s sessions, which otherwise last “until you sign out or the website expires it” (Computers and apps).

Where a site lets you end sessions from its own account settings, do that as well.
That is this guide’s defense-in-depth advice; OpenAI documents only “Review app accounts and website sessions separately” (dots admin guide).

Step 2: After a sensitive-data exposure

Repeat Step 1, then recreate the dot only after the dot-derived ChatGPT memories are gone

Step 3: Clean up artifacts stored elsewhere (Enterprise)

Review dot-created conversations, Library files and Codex tasks, and retain or remove them under your retention policy

Code Implementation

Code Pack: API Script

hth-chatgpt-dots-7.02-offboarding-artifact-inventory.sh View source on GitHub ↗

# 1. ChatGPT memory entries (TRAPS 1, 4, 5). Read-only.
cgpt_get_ok "/compliance/workspaces/${CHATGPT_WORKSPACE_ID}/users/${TARGET}/memories"
jq -e '.data | type == "array"' "${CGPT_BODY}" >/dev/null 2>&1 \
  || cgpt_die "List User Memories returned HTTP 200 without the documented data[] list"
echo "=== ChatGPT memory entries for ${TARGET} ==="
jq -r --argjson show "${SHOW}" '
  [ .data[] | (.memory_contexts // [])[] as $c | ($c.memory_entries // [])[]
    | "  context=\($c.id)  entry=\(.id)  updated_at=\(.updated_at // "?")"
      + (if $show == 1 then "  content=\(.content // "" | tostring | .[0:200])" else "" end) ]
  | if length == 0 then "  (none)" else .[] end' "${CGPT_BODY}"
jq -r 'if .has_more == true then "  NOTE: has_more is true — the count above is a lower bound (TRAP 4)" else empty end' "${CGPT_BODY}"

# 2. Library files the member owns (TRAP 1). Read-only.
LIB="${CGPT_TMPDIR}/library.jsonl"
cgpt_paginate_cursor "/compliance/workspaces/${CHATGPT_WORKSPACE_ID}/users/${TARGET}/library_files" "${LIB}"
echo "=== Library files owned by ${TARGET}: $(wc -l < "${LIB}" | tr -d ' ') ==="
jq -r '"  \(.id)  \(.name // "(unnamed)")  mime=\(.mime_type // "?")  state=\(.state // "?")"
       + "  created_at=\(.created_at // "?")  trashed_at=\(.trashed_at // "-")  is_project=\(.is_project // "-")"' "${LIB}"

# 3. Codex tasks the member created (TRAP 3). The route is workspace-wide and
#    takes limit <= 30, so it is paged here and filtered on created_by_id.
TASKS="${CGPT_TMPDIR}/codex-tasks.jsonl"
: > "${TASKS}"
CURSOR=""; PAGES=0
while :; do
  if [ -n "${CURSOR}" ]; then
    cgpt_get_ok "/compliance/workspaces/${CHATGPT_WORKSPACE_ID}/codex_tasks" \
      --data-urlencode "limit=30" --data-urlencode "cursor=${CURSOR}"
  else
    cgpt_get_ok "/compliance/workspaces/${CHATGPT_WORKSPACE_ID}/codex_tasks" --data-urlencode "limit=30"
  fi
  jq -e '(.data | type == "array") and (.has_more | type == "boolean")' "${CGPT_BODY}" >/dev/null 2>&1 \
    || cgpt_die "List Codex Tasks returned HTTP 200 without the documented {data[], has_more} shape"
  jq -c --arg u "${TARGET}" '.data[] | select(.created_by_id == $u)' "${CGPT_BODY}" >> "${TASKS}"
  PAGES=$((PAGES + 1))
  [ "$(jq -r '.has_more' "${CGPT_BODY}")" = "true" ] || break
  CURSOR="$(jq -r '.cursor // ""' "${CGPT_BODY}")"
  [ -n "${CURSOR}" ] || cgpt_die "List Codex Tasks: has_more is true but no cursor was returned — refusing to report a partial list"
  [ "${PAGES}" -lt 2000 ] || cgpt_die "List Codex Tasks: more than 2000 pages — runaway guard"
done
echo "=== Codex tasks created by ${TARGET}: $(wc -l < "${TASKS}" | tr -d ' ') (from ${PAGES} workspace page(s)) ==="
jq -r '"  \(.id)  \(.title // "(untitled)")  created_at=\(.created_at // "?")  updated_at=\(.updated_at // "?")"' "${TASKS}"

echo ""
echo "NOT LISTED (TRAP 2): conversations — review CONVERSATION_MESSAGE records from pack 6.01."
echo "Nothing above is marked dot-created (TRAP 1): decide what is dot-derived by reviewing content,"
echo "then retain or delete named items under your retention policy (TRAP 6)."
exit 0

What the pack lists: for one departing member, their ChatGPT memory entries (List User Memories), the Library files they own (List User Library Files) and the Codex tasks they created (List Codex Tasks, filtered on created_by_id, because that route has no user parameter). The pack is read-only and uses a chatgpt.enterprise.compliance_export read key.
No dot attribution: no returned field marks an item as dot-created, so decide what is dot-derived by reviewing content. The pack never claims dot attribution.
No conversation list: there is no conversation list route. Conversation records come only as Compliance Logs Platform CONVERSATION_MESSAGE files (6.1).
Deletes not called: the matching delete routes (Delete Memory Entry, Delete Library File, Delete Codex Task, Delete User Conversation) need compliance_export delete and are deliberately not called.

Automation: ClickOps only for the Reset itself — OpenAI exposes no endpoint to delete a dot (Admin API reference, 2026-10-09). Workspace Agents have a delete endpoint; dots do not, and no audit event records a dot’s deletion.

Validation & Testing

Confirm the dot no longer appears for the departing member
Confirm dot-derived entries were removed from ChatGPT Memory before any replacement dot was created
On Enterprise, run the 7.2 pack to list the member’s memory entries, Library files and Codex tasks
- There is no conversation list route; review conversation records as CONVERSATION_MESSAGE files from the Compliance Logs Platform (pack 6.1)
- Nothing in those records identifies dot authorship, so decide what is dot-derived by reviewing content, then retain or remove items under the retention policy
Confirm the owner signed the cloud browser out of websites before Reset

Expected result: No departed or exposed member’s dot, or its context, survives offboarding.

Compliance Mappings

Framework	Control ID	Control Description
CIS Controls v8	3.5	Securely Dispose of Data
CIS Controls v8	6.2	Establish an Access Revoking Process
NIST 800-53	PS-4	Personnel Termination
NIST 800-53	MP-6	Media Sanitization
NIST 800-53	SI-12	Information Management and Retention
SOC 2	CC6.2, CC6.5	User registration, authorization and removal; disposal of protected assets
Benchmark	None	No benchmark equivalent yet

8. Known Gaps and Member Guidance

This section is reference material, not controls. It records member-level settings and documented gaps that matter for risk but have no admin control, so nothing here appears on the cheat sheet.

8.1 Documentation conflicts to resolve in a live tenant

OpenAI’s own pages disagree on the following. This guide does not pick a side silently; each conflict is flagged in the control it affects.

#	Topic	One source says	Another source says	Affects
a	Slack permission label	“Add dots to Slack” (learn.chatgpt.com)	“Add dots to Slack and Microsoft Teams” (help 20001554)	2.2
b	What blocks local access	`enforce_residency` in any cloud policy (learn.chatgpt.com)	Codex or Work policies that target a specific operating system (help 20001554)	3.4, 5.1
c	Rule and reset labels	“Take action when you say so”; “Delete” (learn.chatgpt.com)	“Take action if pre-approved”; “Reset” (help 20001530)	4.1, 4.4, 7.2
d	Parent permission label	“Use dots” (dots admin guide permission list and Slack checklist); “Use Dots” (cloud-local-access)	“Use dots (Beta)” (dots admin guide setup step 2; help 20001554). No console checked	1.1, 3.4 and every ClickOps path that names it
e	Website sign-in on Enterprise	“Website sign-in isn’t available for Enterprise or Edu workspaces” (learn browser page)	Dots use the Work sign-in flow, offer Save to Passwords, and have a Use password manager permission	3.3
f	How roles combine	Additive (roles page, help 20001554, help 11750701, the `ROLE_CREATE` / `ROLE_UPDATE` schema)	“an explicit Off in any role denies that permission” (groups-and-provisioning)	1.1, 5.1, 6.2, 7.1 and every permission control
g	App permissions labels	Always ask, Any changes, Important actions, Never ask (Work Cloud security)	Always ask, Allow read actions, Allow low-risk actions, Allow all actions (help 11509118, 20001495)	2.1
h	Pause scope	Stops only the current main task (learn controls)	Stops the dot until resumed (help 20001530)	7.1
i	Inspecting dot memories	“Review saved memories” (dots admin guide)	“You currently cannot view, delete or directly modify individual dot memories” (FAQ)	5.2, 7.2
j	Profile section names	“Activity” (learn controls)	“In progress, Scheduled, and Completed” (Help Center)	7.1
k	Workspace MFA	“SAML SSO, MFA, and workspace user management” is a Business/Enterprise-only workspace feature (pricing matrix)	“MFA cannot currently be enforced at the ChatGPT workspace or API Platform organization level” (help 7967234)	1.2
l	Scope of Agent Security `apps`/`plugins` requirements	Global orchestrator controls that reach dots (Agent Security, Config reference)	“apply to local executors” (Plugin controls; Managed configuration precedence table)	2.1, 4.2
m	Policy write interface	“Use the policy API to manage Global settings”; “Test your scripts and Terraform integrations” (Agent Security, Managed configuration)	Admin API v2.5.37 publishes no policy route and no PUT operation, yet its `WORKSPACE_SET_POLICY` text cites a “public API PUT” for Codex policy-stack saves	4.2, 4.3, 5.1, 8.3
n	Dots usage reporting	“For dots, use the Analytics API for usage” (cloud-local-access); “Use the Analytics API for available adoption metrics” (dots admin guide)	Admin API v2.5.37 Get Daily Usage “Returns daily ChatGPT and Codex usage” with no dots field and an un-enumerated `client_id`	8.5
o	Texting	“Texting is coming soon.” (learn dots/channels)	A “limited beta” “limited to Pro users in the US and … not available in Business or Enterprise workspaces” (help 20001530)	8.7, Appendix A
p	A dot’s own email	A dot can have “its own email or Slack account” (Dots FAQs)	“At launch, you cannot give your dot its own standalone email address.” (help 20001530); the Slack identity is consistent	2.2
q	Usage terms	“Conversations with your dot don’t count toward your ChatGPT usage limits”, with no end date (Meet dots)	“For the next month, dots usage won’t count toward eligible Pro, Business, and Enterprise users’ plan allowances. After this period, we’ll share usage terms for each plan.” (ChatGPT release notes, 2026-09-29)	8.9
r	Saved memories when workspace Memory is turned off	Deleted (help 9295112, Business owner toggle)	“does not delete saved memories” (Admin API Delete and Disable Workspace Memory)	5.2

8.2 No admin kill switch, inventory or delete for an individual dot

No admin controls on a dot: admins cannot list which members have created dots, inspect a dot, or pause, reset or delete a member’s dot, or purge its context. They can only revoke Use dots (Beta) (dots admin guide; Manage dots in ChatGPT workspaces).
Revocation’s effect is unknown: whether revocation stops scheduled or in-flight cloud tasks is undocumented.
A possible lever, untested: the Admin API’s Delete User Automation endpoint “stop[s] future scheduled runs”, and help 20001530 says scheduled tasks can be managed in “the Scheduled section in ChatGPT”. But no document says dot schedules are Compliance API automations, so live-test it before relying on it.
Until then: 7.1’s owner-side steps are the only documented way to stop a dot’s work, and they are known to be reachable only before revocation. 7.1’s Path B drill is where that gap gets measured.

8.3 No write interface for any dots permission

None of the eight permissions that shape dots has a write interface: Use dots (Beta), Add dots to Slack and Microsoft Teams, Allow local computer access, Use custom rules for dots, Cloud browser use, Cloud network access, Cloud computer use and Use password manager.

Admin API: v2.5.37 has no custom-role, permission, role-assignment or workspace-default route (Update Workspace User changes only a member’s built-in role and seat type). Automation is limited to membership of manually managed groups, and SCIM groups return 409 scim_managed_resource.
Policy API: at least eleven learn.chatgpt.com pages say “Use the policy API to manage Global settings” and mention “Terraform integrations”, but no public route is published and no provider resource exists (Admin API reference; Terraform registry).
A possible unpublished path: the Admin API spec’s own WORKSPACE_SET_POLICY text refers to Codex policy-stack saves “from the UI and public API PUT”, so an unpublished write path may exist (8.1 row m).

This is why 6.2’s detection matters.

8.4 Agent Security Global policy may not bind a cloud-only dot

The docs scope Global policy to “Work with local access and dots … when managed policy is enabled” (Agent Security).
The approval values are Codex vocabulary.
The dots admin guide never mentions Agent Security.

Live-test 4.2, 4.3 and the 2.1 apps requirement against a cloud-only dot before relying on them.

8.5 Audit attribution and plan coverage

No dots identity in the records: there is no dots event type, mode or actor type, and conversation.mode is only chat or work. CONVERSATION_MESSAGE author.type and CODEX_LOG’s optional agent object may help but are not enumerated for dots.
Undocumented identifiers: the dots and cloud-capability identifier strings, and which of ROLE_UPDATE, WORKSPACE_TOGGLE_FEATURE or tenant.custom_role.* carries them, are undocumented. tenant.* events have no documented payload schema, so Sigma rules can match only the action.
No OpenTelemetry: cloud orchestration events never reach OpenTelemetry.
Usage reporting: OpenAI directs admins to the Analytics API for dots usage (Cloud and local access; dots admin guide), but that page defers metrics to the Admin API reference. Its Get Daily Usage (v2.5.37) “Returns daily ChatGPT and Codex usage” with no dots field and an un-enumerated client_id (“Normalized ChatGPT or Codex client identifier”), so dots activity cannot be isolated from documented fields (8.1 row n). It requires a workspace-scoped Admin key with enterprise.analytics.usage read.
Plans: the Compliance API and audit logs are unavailable on Business (pricing) and on Pro, so Business Premium and Pro dots have no exportable admin audit record or SIEM feed.

8.6 Business Premium and Pro: what the owner must do

Business Premium is a Premium seat in ChatGPT Business (Billing and seats in ChatGPT Business) that includes dots. Pro has only owner-level controls.

What Business admins control: app availability, per-app action controls and the Plugin permissions default workspace-wide, but no custom roles (apps are enabled by default on Business, help 11509118), and the workspace-wide Memory toggle.
What is not documented: no dots toggle, capability control, local-access control or custom-rules permission is documented. Business has no custom RBAC, Compliance API or Analytics API.

On Business Premium, the Business admin should apply the 2.1 baseline workspace-wide: Actions read-only, New actions restricted, and Workspace settings > General > Settings > Plugin permissions set to Always ask. No dots-specific page confirms that these workspace controls bind a Business Premium dot; the inference rests on “Plugin permissions are shared across dots, ChatGPT, ChatGPT Work, and Codex” (Dots FAQs).

On both plans, the owner carries the controls below; on Business Premium the admin also holds workspace-wide app availability and Plugin permissions:

Turn on MFA and log out of all devices (1.2, Step 1)
Set app permissions to Always ask:
- Pro: set Settings > Plugins > Permissions to Always ask (2.1, Step 4)
- Business Premium: that selector is documented only for “an eligible personal account”, and managed-workspace members “may instead see approval prompts governed by workspace policy” (help 20001495). Ask the Business admin to set Workspace settings > General > Settings > Plugin permissions to Always ask and to restrict each app’s Actions to read (help 11509118)
Connect your dot to a work Slack only where that Slack’s owners allow the app (2.2, Step 3)
Keep the dot off your own computer, or revoke it at dot profile > Computers > Your computer > Revoke access when done (3.4)
Add custom rules that hand off purchases and ask before external sends (4.4)
Turn off Memory where you handle sensitive data, and on Pro turn off Improve the model for everyone (5.2)
Know where Pause, Activity, Scheduled and Reset are before you need them (7.1, 7.2)

8.7 Member-level surfaces with no admin control

Proactive research, self-scheduling and event monitoring. A dot can research connected information on its own, decide when to wake up, and act on a time or supported event (Tasks and memory). No admin control exists for any of these.
@dot in Space pages. A dot can be invoked inline or in a page comment on a shared Space page (Work with agents in Space); no admin control is documented.
Lockdown Mode. Its effect on dots is undocumented; the Lockdown Mode article never mentions dots.
Cloud browser website permissions. Settings > Cloud browser offers Always ask, Auto approve and Always allow, but the cloud browser article covers ChatGPT Work and never mentions dots. Whether they govern a dot’s browser is undocumented, so they were not made a dots control. If they do apply, Always ask is the cautious choice; OpenAI itself says Always allow “is not recommended”.
Work network access. Settings > Data controls > Work network access > Allow public internet access exists for ChatGPT Work code and shell (Sandboxing); whether it applies to dots is undocumented (3.2).
Messaging channels. Help 20001530 describes texting as a “limited beta” “limited to Pro users in the US and … not available in Business or Enterprise workspaces” (Getting started with your dot), while learn.chatgpt.com says “Texting is coming soon” (Channels); 8.1 row o. Phone messaging through iMessage, RCS or WhatsApp is unavailable for Enterprise at launch (help 20001554).

8.8 Egress, retention, memory and offboarding unknowns

Egress: no admin-configurable egress allowlist exists for dots cloud computers. Cloud network access is on or off, and with it off OpenAI’s managed allowlist of required hostnames stays reachable. Dot-created Codex cloud environment tasks follow Codex Cloud networking, not this switch (3.2).
Retention: whether workspace conversation-retention settings apply to dot conversations is undocumented. Dot context is retained for as long as the dot exists, there is no zero data retention, and human review can occur even with model improvement off. The residency opt-in acknowledgment flow has no documented console path.
Memory: these are undocumented:
- whether the Enterprise delete_and_disable endpoints stop dot-to-ChatGPT memory sharing, or touch dot notes
- whether the memories endpoints cover dot notes
- whether the API’s workspace disable deletes saved memories the way the Business owner toggle does (8.1 row r)
- a console path for the Business workspace-wide Memory toggle (5.2)
Offboarding: the user lifecycle guidance never mentions dots. What happens to a deprovisioned member’s dot, its schedules, cloud-browser sessions, saved passwords and Slack identity is undocumented (7.2).
enforce_residency: it is not a neutral local-access kill switch (5.1).
- Besides blocking dots local access workspace-wide, it requires Codex service traffic to use US data residency.
- It does not set workspace residency or disable dots.
- The docs name only an Agent Security cloud policy as the trigger.
- No published API route can apply it. OpenAI says to “Use the policy API to manage Global settings” but documents no endpoint, the public Admin API (v2.5.37, 106 paths) has no policy route, and the Config reference warns that “Support for a requirements.toml field does not by itself establish API compatibility” (8.3).

8.9 Spend, specialist dots and Agent 365

No spend control: no dots spend or usage control is documented. The Admin API’s per-feature spend cap names only team automations.
Conflicting usage terms (8.1 row q):
- Meet dots says dot conversations don’t count toward ChatGPT usage limits, while Work or Codex tasks a dot starts do count toward those products’ limits.
- The ChatGPT release notes (2026-09-29) say dots usage won’t count toward plan allowances “For the next month” and that “After this period, we’ll share usage terms for each plan”.
- The dots admin guide says “Review current usage terms before rollout”.
- Treat the current terms as subject to change after about late October 2026.
Out of scope for this version: specialist dots, with their own identity and credentials, are enterprise pilots only, and a Microsoft Agent 365 integration is a stated goal (Introducing dots). Neither has admin documentation.

8.10 Benchmarks, incidents and dropped sources

No CIS Benchmark and no CISA SCuBA ChatGPT baseline exist, and DISA STIG coverage is unverifiable (DoD authentication wall), not absent. Every control is “no benchmark equivalent yet”.
No public dots-specific vulnerability or incident exists as of 2026-10-08. Every Real-World Incident cited in this guide concerns a sibling or predecessor surface (Workspace Agents, connectors, Deep Research, Operator, Codex, ChatGPT Memory, internal models) and is labeled as an analog.
The Five Eyes guidance on careful adoption of agentic AI services could not be fetch-verified on 2026-10-08 and is not cited.

8.11 What live validation must settle

Before this guide can claim more than AI-drafted status, a live run needs to:

transcribe the real console labels and resolve the conflicts in 8.1
capture the dots permission identifier strings and payloads in AUDIT_LOG and tenant.* events
run the 6.1 coverage test with an attribution objective
test whether the Global approval policy and MCP hooks bind a cloud-only dot (4.2, 4.3)
confirm whether Use password manager governs Save to Passwords (3.3)
test what the memory delete_and_disable endpoints do to dots and whether their audit actions arrive (5.2)
confirm whether a standalone Business workspace offers a Required SSO sign-in policy, and transcribe its label and path (1.2 Step 3)
locate Allow External Domain Invites in the Business and Enterprise/Edu consoles and confirm which role can change it (1.2 Step 4)
confirm whether hooks have a UI control in Agent Security or must be entered as TOML (4.3)
capture the console path that enables API Platform audit logs (6.2)
test what revoking Use dots (Beta) does to an existing dot: whether the member can still reach Pause, Activity and Scheduled, and whether scheduled runs and in-flight cloud or delegated tasks stop (7.1, 8.2)

9. Compliance Quick Reference

Every mapping below is at the control-family level; no benchmark covers dots yet.

SOC 2 Trust Services Criteria Mapping

Control ID	Dots Control	Guide Section
CC6.1	Pilot-only dots grant; SSO or MFA on owner accounts; read-only app actions; Slack permission; cloud capabilities; password manager; local access; custom-rules permission; orchestrator approvals; owner custom rules	1.1, 1.2, 2.1, 2.2, 3.1, 3.3, 3.4, 4.1, 4.2, 4.4
CC6.2	Reset the dot at offboarding	7.2
CC6.3	Pilot-only dots grant	1.1
CC6.5	Reset the dot at offboarding	7.2
CC6.6	Read-only app actions; cloud browser and computer use; cloud network access	2.1, 3.1, 3.2
CC6.8	Local computer access off	3.4
CC7.2	MCP hooks as telemetry; Compliance Logs Platform ingestion; governance-change alerts	4.3, 6.1, 6.2
CC7.4	Kill sequence	7.1
CC8.1	Custom-rules permission; orchestrator approvals; governance-change alerts	4.1, 4.2, 6.2
C1.1, P4.1	Residency and retention boundary; memory limits	5.1, 5.2

NIST 800-53 Rev 5 Mapping

Control	Dots Control	Guide Section
AC-3	Pilot-only grant; read-only app actions; Slack permission; residency boundary	1.1, 2.1, 2.2, 5.1
AC-4	Slack permission; cloud network access; web-search limits; memory limits	2.2, 3.2, 4.2, 5.2
AC-6	Pilot-only grant; read-only app actions; cloud capabilities; password manager; local access; custom-rules permission; owner custom rules	1.1, 2.1, 3.1, 3.3, 3.4, 4.1, 4.4
AC-17	Local computer access off	3.4
AC-21	Slack permission and Slack-side approval	2.2
AC-2, IR-4	Kill sequence	7.1
AC-2(4)	Governance-change alerts	6.2
CM-3	Governance-change alerts; kill sequence	6.2, 7.1
AU-2, AU-11	Compliance Logs Platform ingestion	6.1
AU-6	Compliance Logs Platform ingestion; governance-change alerts	6.1, 6.2
AU-12	MCP hooks as telemetry; Compliance Logs Platform ingestion	4.3, 6.1
CM-6	Custom-rules permission; orchestrator approvals	4.1, 4.2
CM-7	Pilot-only grant; read-only app actions; cloud capabilities; orchestrator approvals; local access	1.1, 2.1, 3.1, 3.4, 4.2
IA-2(2)	SSO or MFA on owner accounts	1.2
IA-5	Password manager off	3.3
PL-4	Owner custom rules	4.4
PS-4, MP-6	Reset the dot at offboarding	7.2
PT-2	Memory limits	5.2
SA-9(5)	Residency and retention boundary	5.1
SC-7	Cloud capabilities; cloud network access	3.1, 3.2
SC-7(5)	Cloud network access off	3.2
SI-4	MCP hooks as telemetry; governance-change alerts	4.3, 6.2
SI-12	Residency and retention boundary; memory limits; Reset at offboarding	5.1, 5.2, 7.2

CIS Controls v8 Mapping

Safeguard	Dots Control	Guide Section
2.5	Read-only app actions	2.1
2.7	Local computer access off	3.4
3.1, 3.7	Residency and retention boundary	5.1
3.1, 3.4	Memory limits	5.2
3.3	Read-only app actions; Slack permission	2.1, 2.2
3.5	Reset at offboarding	7.2
4.1	Custom-rules permission; orchestrator approvals	4.1, 4.2
4.8	Pilot-only grant; cloud capabilities; network access; local access	1.1, 3.1, 3.2, 3.4
6.2	Kill sequence; Reset at offboarding	7.1, 7.2
6.3	SSO or MFA on owner accounts	1.2
6.8	Pilot-only grant; Slack permission; cloud capabilities; custom-rules permission; governance-change alerts	1.1, 2.2, 3.1, 4.1, 6.2
8.2	MCP hooks as telemetry; Compliance Logs Platform ingestion	4.3, 6.1
8.9	Compliance Logs Platform ingestion	6.1
8.11	Compliance Logs Platform ingestion; governance-change alerts	6.1, 6.2
13.4	Cloud network access off	3.2
17.4	Kill sequence	7.1

Other Frameworks

Framework	Mapping	Guide Section
CISA SCuBA (source-system consent)	MS.AAD.5.2v1, MS.AAD.5.3v1, GWS.COMMONCONTROLS.10.1v1, 10.2v1, 10.4v1	2.1
OWASP Top 10 for Agentic Applications 2026	ASI01 Agent Goal Hijack, ASI03 Identity and Privilege Abuse	4.1
GDPR	Art. 44	5.1

Appendix A: Edition and Plan Availability

How to read the table:

“Admin” means a workspace admin can set the control
“Owner” means only the dot’s owner can
“Slack-side” means a Slack Workspace Owner or app manager sets it in Slack, not a ChatGPT admin
“None documented” means OpenAI documents no equivalent on that plan
“❌” means the capability itself is unavailable on that plan (no Compliance API, no Agent Security, or “not available for personal accounts”)
“Not applicable” means the control’s subject does not arise on that plan

Control	Pro 100/200/500	Business Premium	Enterprise (incl. Edu, Healthcare)
1.1 Use dots (Beta) gate	None documented	Premium seat assignment only (treating it as a dots gate is an inference)	✅ Admin (custom roles)
1.2 SSO or MFA on owner accounts	Owner (personal MFA)	✅ Admin (Business SSO setup; a require-SSO control is unconfirmed on standalone Business)	✅ Admin (Enterprise/Edu SSO)
2.1 Read-only app actions	Owner (Settings > Plugins > Permissions)	Admin: workspace-wide app availability, per-app Actions/New actions and the workspace Plugin permissions default (help 11509118); no role access; binding on dots unconfirmed. The member-level selector is not documented for managed workspaces (help 20001495)	✅ Admin (Plugin controls, role access)
2.2 Add dots to Slack and Microsoft Teams	Owner (choose whether to connect Slack) · Slack-side app approval	Owner (choose whether to connect Slack) · Slack-side app approval	✅ Admin (Teams is invite-only alpha) · Slack-side app approval
3.1 Cloud browser and computer use	None documented	None documented	✅ Admin
3.2 Cloud network access	None documented	None documented	✅ Admin
3.3 Use password manager	None documented	None documented	✅ Admin
3.4 Allow local computer access	Owner (connect or revoke a computer)	Owner (connect or revoke a computer)	✅ Admin, plus owner revoke
4.1 Use custom rules for dots	Not applicable	None documented	✅ Admin
4.2 Agent Security Global baseline	❌	None documented	✅ Admin
4.3 Managed MCP hooks	❌ (not available for personal accounts)	None documented	✅ Admin
4.4 Owner custom rules	Owner	Owner	Owner, where 4.1 permits
5.1 Residency boundary	Not applicable	Not applicable	✅ Admin (dots unavailable in FedRAMP, EKM and AE workspaces)
5.2 Memory limits	Owner (Memory; Improve the model for everyone)	Owner, plus admin workspace-wide Memory toggle	✅ Admin (supported memory settings and role permissions, e.g. Use improved memory in Regulated Workspace, help 8590148), plus Admin API memory list, per-entry delete and delete-and-disable endpoints; effect on dot notes undocumented
6.1 Compliance Logs Platform	❌	❌	✅ Admin (Enterprise, Edu and Healthcare)
6.2 Governance-change alerts	❌	❌	✅ Admin (Enterprise and Edu)
7.1 Kill sequence	Owner steps only	Owner steps only	✅ Admin revoke, plus owner steps
7.2 Reset at offboarding	Owner	Owner	Owner (no admin delete)

Availability notes:

Pro is for users 18 and older outside the EEA, the UK and Switzerland (Meet dots; ChatGPT release notes).
Dots are not available to users under 18 (Dots FAQs).
Dots are unavailable in FedRAMP workspaces, workspaces with EKM, and workspaces with inference residency set to AE (UAE). HIPAA workspaces can participate if they meet the other eligibility requirements (Cloud and local access).
Texting conflicts across sources: help 20001530 describes a limited beta for Pro in the US only, while learn.chatgpt.com says texting “is coming soon” (8.1 row o).
Specialist dots are enterprise pilots only.

Appendix B: References

OpenAI dots documentation (Help Center):

Manage dots in ChatGPT workspaces (help 20001554)
Dots privacy, security, and safety FAQs (help 20001529)
Getting started with your dot (help 20001530)
ChatGPT release notes — 2026-09-29 “Meet your dot” entry

OpenAI dots documentation (learn.chatgpt.com):

OpenAI workspace administration:

API, CLI, SDK and Terraform references:

ChatGPT Admin API reference — public; spec v2.5.37, 106 paths, server https://api.chatgpt.com/v1
API Platform audit logs: list
Compliance API download script
openai CLI
openai-python and its audit-log list parameters
openai-node
developers.openai.com/llms.txt
Terraform registry: openai/openai
Slack: Manage app requests for your workspace

OpenAI announcements and first-party evaluations:

Benchmarks and frameworks:

CIS AI Benchmarks — no ChatGPT, OpenAI or dots benchmark
CISA ScubaGear Entra ID baseline (MS.AAD)
CISA ScubaGoggles Common Controls baseline (GWS.COMMONCONTROLS)
NIST CAISI: insights from a large-scale AI agent red-teaming competition
OWASP Top 10 for Agentic Applications for 2026

Security research (analogs; no dots-specific incident exists as of 2026-10-08):

Related HTH guide:

ChatGPT Enterprise Hardening Guide — org-wide identity, SSO/SCIM, retention, EKM, Plugin controls and Compliance API ingestion

Changelog

Date	Version	Maturity	Changes	Author
2026-10-09	0.1.0	ai-drafted	Initial guide for ChatGPT dots (launched 2026-09-29): 18 controls in 7 sections (access and enablement, connected apps and channels, cloud computer and local access, autonomy and approvals, data and memory, monitoring, lifecycle), a Known Gaps and Member Guidance reference section recording eighteen OpenAI documentation conflicts and the controls OpenAI does not offer, and Code Pack includes for 11 controls (api, siem/sigma, config, cli). Written from OpenAI documentation with no live tenant validation, then corrected after an adversarial review whose facts were re-checked on 2026-10-09 (help.openai.com, chatgpt.com/public/admin/api-reference and www.beyondtrust.com return 403 to automated fetchers, so those pages were read in a real browser)	Claude Code (Opus 5.5)

Contributing

Found an issue or want to improve this guide?

Report outdated information: Open an issue with tag content-outdated
Propose new controls: Open an issue with tag new-control
Submit improvements: See Contributing Guide

ChatGPT Dots Hardening Guide

Overview

Intended Audience

How to Use This Guide

Scope

Where Dots Touch the ChatGPT Enterprise Guide

Automation Surfaces at a Glance

Table of Contents

1. Access & Enablement

1.1 Keep Use dots (Beta) off by default and grant it only through a pilot custom role

Description

Rationale

Prerequisites

ClickOps Implementation

Code Implementation

Validation & Testing

Compliance Mappings

1.2 Require SSO or personal MFA on every account that owns a dot

Description

Rationale

Prerequisites

ClickOps Implementation

Code Implementation

Validation & Testing

Compliance Mappings

2. Connected Apps & Channels

2.1 Restrict the app connections and actions dots inherit to read-only by default

Description

Rationale

Prerequisites

ClickOps Implementation

Code Implementation

Validation & Testing

Compliance Mappings

2.2 Restrict Add dots to Slack and Microsoft Teams to a narrow role and keep Slack-side app approval on

Description

Rationale

Prerequisites

ClickOps Implementation

Validation & Testing

Compliance Mappings

3. Cloud Computer, Browser & Local Access

3.1 Re-baseline Cloud browser use and Cloud computer use before enabling dots

Description

Rationale

ClickOps Implementation

Validation & Testing

Compliance Mappings

3.2 Turn off Cloud network access for dots

Description

Rationale

ClickOps Implementation

Validation & Testing

Compliance Mappings

3.3 Keep Use password manager off for dots populations

Description

Rationale

ClickOps Implementation

Validation & Testing

Compliance Mappings

3.4 Keep Allow local computer access off for dots

Description

Rationale

ClickOps Implementation

Validation & Testing

Compliance Mappings

4. Autonomy & Approvals

4.1 Keep Use custom rules for dots off outside a narrow role

Description

Rationale

ClickOps Implementation

Validation & Testing

Compliance Mappings

4.2 Enforce orchestrator approval and web-search limits in the Agent Security Global baseline

Description

Rationale

Prerequisites

ClickOps Implementation

Code Implementation

Validation & Testing