ChatGPT Enterprise Security: Admin, Data, Connectors

A ChatGPT Enterprise workspace becomes a store of sensitive conversations, files and connected-app access, and its default settings, role model and connectors decide who can reach that data and what the assistant can do with it. Buying the enterprise tier removes some consumer-tool risks, such as staff pasting code into personal accounts, but it adds an administrative surface that needs the same discipline as any SaaS platform holding company data. This guide covers identity and provisioning, admin roles, apps and connectors, custom GPTs and agent features, data controls, logging and a hardening baseline. Product behaviour is described as set out in OpenAI's documentation (checked October 2026); OpenAI renames and changes features often, so confirm each setting in your own admin console. It is written for identity, SaaS security and AI governance teams administering or assessing a workspace.

Key takeaways

Identity is the first control. Verify domains, enforce SAML SSO, provision through SCIM groups and turn off automatic account creation, or users will exist outside your identity provider's control.
Roles combine permissively. When a user holds several roles, access granted by any one of them survives another role setting it to Off, so restrictive roles only work if no broader role is also assigned.
Apps and agents are the new blast radius. Each connector extends what a prompt can read or change; keep apps off by default, enable write actions deliberately and require confirmation before actions.
Logs expire unless you collect them. The Compliance Logs Platform keeps data for 30 days, and OpenAI documents that individual agent actions are not in the Compliance API logs.
Data residency and retention have edges. Data that flows through external apps, MCP servers and web search is not covered by at-rest residency, and retention settings do not reach copies held by connected services.

How identity and access work in ChatGPT Enterprise

OpenAI's documentation describes a chain of controls: domain verification, then SAML SSO, then provisioning. Each step has a behaviour that surprises administrators.

Domain verification: proves the organisation controls an email domain and is required before SSO. OpenAI advises contacting support before removing a verified domain, because removal can break access.
SSO is domain-wide: each ChatGPT workspace maps to an OpenAI Platform organisation with the same organisation ID, sharing domain and SAML settings, with one identity provider per organisation ID. Enforcing SSO (a Global Admin action) stops password and social login for users on the verified domain, and because Platform login is domain-based, SSO changes can also affect API Platform users on that domain.
SCIM provisioning: available for eligible Enterprise and Edu workspaces; the help article lists Okta, Microsoft Entra ID, Google Workspace, PingFederate, OneLogin and Rippling, and states that a standalone Business plan does not include SCIM. Groups sync from the identity provider, and assigning a synchronised group under Product access is what grants access: syncing alone does not.
No role mapping from the IdP: new SCIM invitations get the Member role; the Product access editor does not assign the owner role or custom roles, which are set inside the workspace.
Automatic account creation is separate: it adds eligible users who sign in with a verified-domain email, does not require SSO, and those users may not be SCIM-managed, so removing them in the identity provider may not remove their access. OpenAI recommends turning it off when managing access through SCIM.
Deprovisioning limits: OpenAI warns that disabling a user in the identity provider does not always remove the application assignment, and that deprovisioning a workspace member does not delete the person's OpenAI account or personal workspace. A user can also hold a seat while SSO blocks their sign-in.
IP allowlisting: available for Enterprise and Edu, off by default, with separate lists for workspace access and the Compliance API; requests from unlisted addresses are refused even with valid credentials, and changes take 5 to 15 minutes to apply.

Choosing a provisioning model

Approach	Fits	Trade-off
SSO enforced, SCIM groups, automatic account creation off	Most enterprises; anyone with joiner-mover-leaver controls in the IdP	Requires group design up front; owner and custom roles still assigned in the workspace
SSO enforced, automatic account creation on	Organisation-wide rollout where every domain user may use ChatGPT	Users can appear outside SCIM; leavers rely on SSO blocking sign-in and seats are not reclaimed automatically
Manual invitations, SSO enforced	Small pilots	Offboarding depends on an admin remembering; does not scale

See the SCIM Provisioning Guide and the Identity Provider and SSO Security Guide.

Admin roles and privileged access

Role	What it can do (per OpenAI documentation)	Hardening note
Owner	Workspace settings, membership, custom roles; the only role that can grant broad Compliance API access or the Conversation messages permission	Two or three named owners, phishing-resistant MFA at the IdP, reviewed quarterly
Admin	Members, groups and admin settings; cannot create, delete or assign custom roles	Treat as privileged; separate admin accounts where your IdP supports it
Analytics viewer	Usage analytics	Useful for governance teams who need no settings access
Member	Product use, as permitted by roles	Default for SCIM invitations
Custom roles	Created by owners; each permission set to Default, On or Off	Access granted by one role remains even if another sets it Off: design roles as additive
Group managers	Delegated group tasks, not billing, identity, seats or defaults	Useful delegation that avoids handing out Admin

Additive role design: because roles combine as a union, build a narrow default role for everyone and add capability roles (agent use, GPT publishing, specific apps) for named groups. A "restricted" role applied on top of a broad one restricts nothing.
Lockdown roles: OpenAI documents roles that can restrict web search, deep research and agent mode for high-risk groups, such as staff handling regulated data. Role changes can take up to five minutes to apply.
Workspace permissions to review: model access, GPT creation and sharing, Canvas, Projects, memory and link sharing are set under Permissions and roles. Event-triggered scheduled tasks are off by default for Enterprise.
Compliance access is the most sensitive grant: a key with conversation-message access can read the workspace's conversations. Limit it to an owner-approved integration identity, store the key in a vault and pin it with IP allowlisting. See the API Key Management Guide.

Integrations, API tokens and service accounts

Apps (connectors, including custom MCP apps), custom GPTs with actions and agent features let ChatGPT read from and act in other systems. Each one is a delegated, non-human access path that needs an owner and a scope.

Apps and connectors

Default off: for Enterprise and Edu, OpenAI states that new plugins and apps are disabled by default (Business workspaces default to enabled). Keep that default and enable apps per role.
Three separate controls: role access (who may use an app), actions (what it can do, with write actions toggled separately from read) and permissions (when ChatGPT asks first: Always ask, Allow read actions, Allow low-risk actions or Allow all actions). OpenAI flags Allow all actions as elevated risk.
Provider scopes are not ChatGPT permissions: approving OAuth scopes at the provider does not enable the matching actions in ChatGPT, so review both sides. See the SaaS and OAuth App Governance Guide.
Custom apps are unverified: OpenAI states custom apps are not verified by OpenAI. Custom MCP apps can be added by owners, admins or members explicitly granted the right; restrict that right and review each server. See the MCP Security Guide.

Custom GPTs

Sharing scope: GPTs can be shared with specific people, the workspace, by link or (where permitted) the GPT Store. Admins can limit which sharing methods appear and which GPTs users can access, including third-party GPTs.
Action domains: admins can set an approved domain list for GPT actions, so a GPT cannot call an arbitrary external API with user data.
Knowledge files are data stores: anyone who can use a GPT can ask it about its uploaded files, so a GPT shared by link is effectively a file share. Apply the same classification rules.

Agent features

Off until enabled: OpenAI documents agent mode as off by default for Enterprise, switched on by an owner and assignable through roles; it uses only the apps the owner has enabled, and owners can request domain blocklists. OpenAI's documentation was renaming agent products when checked, so match these controls to the current console labels.
Telemetry gap: agent conversations appear in Compliance API logs, but individual agent actions do not. Monitor the connected systems' own audit logs for agent-initiated changes.
Prompt injection is not solved: OpenAI wrote in December 2025 that prompt injection remains an open challenge for agent security and is unlikely ever to be fully solved, and its agent documentation states the safeguards do not remove all risk. Content an agent reads (web pages, emails, documents) can steer it (ATT&CK T1698 Indirect Prompt Injection; MITRE ATLAS AML.T0051). See the Prompt Injection Guide.

Data controls: retention, residency and keys

Control	What OpenAI documents	Limit to plan around
Training	Business data is not used to train models by default (enterprise privacy page, updated January 2026)	Contractual commitment: confirm it in your agreement and DPA
Retention	Admins set retention for Enterprise; deleted conversations are scheduled for permanent deletion within 30 days unless legal or security obligations apply; temporary chats may be kept up to 30 days	Does not reach copies in connected apps, exports or your own Compliance API store; set a matching retention rule there
Encryption	AES-256 at rest and TLS 1.2 or later in transit	Provider-managed keys unless EKM is in place
Enterprise Key Management (EKM)	Customer key-encryption key held in AWS KMS, Google Cloud or Azure Key Vault; limited to Enterprise and Edu workspaces with a named OpenAI account representative	Beta and alpha features are unavailable when EKM is enabled; test key-loss procedures with OpenAI before relying on revocation
Data residency	At-rest storage in regions including Europe, the UK, the US, Japan and India for eligible new Enterprise and Edu customers; conversations, files, custom GPTs and memory are stored in region	Data sent through apps and MCP, web search, transient processing, workspace metadata and logins are not guaranteed in region; third-party GPTs are not eligible
Assurance	OpenAI's trust portal lists SOC 2 Type 2, ISO/IEC 27001:2022, 27017, 27018, 27701 and 42001 among its attestations	These are OpenAI's claims: obtain the reports and check scope against the products you use

For classification, prompt inspection and blocking of sensitive uploads, see the Generative AI Data Loss Prevention Guide.

Logging and detection

The Compliance API, launched in July 2024, exposes conversations, uploaded files, GPT configurations, memories and workspace users. In December 2025 OpenAI moved it into the Compliance Logs Platform, which delivers time-windowed JSONL log files and added Admin Audit, User Authentication and Codex Usage logs. The help documentation states that the platform keeps data for 30 days, that deleted data is not recoverable, and advises continuous download. OpenAI lists DLP, CASB, eDiscovery and SIEM partner integrations.

Signal	Source	Why it matters
Role, SSO, domain and app-setting changes	Admin Audit log	Privilege escalation or weakening of controls
Sign-ins not via SSO, from new locations or blocked by IP allowlist	User Authentication log; IdP logs	Account takeover or SSO gaps (ATT&CK T1078.004 Cloud Accounts)
Sensitive content in prompts and files	Compliance API conversation and file data into DLP	Data leakage (MITRE ATLAS AML.T0057 LLM Data Leakage)
New or changed GPTs with actions, link sharing	GPT configuration data	New outbound data paths
Agent-initiated writes in connected systems	The connected SaaS audit logs	Fills the gap left by missing agent-action logs
Compliance key use from unexpected addresses	IP allowlist and key logs	Theft of the most privileged credential

Metrics that show the controls work:

Percentage of active seats provisioned through SCIM groups (target 100%), and seats held by leavers (target zero).
Number of owners and admins, and days since their last access review.
Enabled apps with write actions or Allow all actions, each with a named owner and review date.
Hours of compliance log data missing from your store (target zero inside the 30-day window).
DLP detections per thousand conversations and the share resolved within agreed time.
GPTs shared by link or outside the workspace, trended monthly.

Hardening baseline

Area	Baseline setting	Framework mapping
Identity	Verified domains, SSO enforced, SCIM groups, automatic account creation off, IP allowlisting where egress is predictable	CSF 2.0 PR.AA-01; SP 800-53 AC-2, IA-2; ISO/IEC 27001:2022 A.5.16, A.8.5
Privilege	Two or three owners, additive custom roles, Compliance access limited to one integration identity	CSF 2.0 PR.AA-05; SP 800-53 AC-6; A.8.2
Apps and agents	Apps off by default, enabled per role; write actions only where justified; never Allow all actions for apps reaching sensitive data; agent mode for named groups with domain blocklist	SP 800-53 CM-7, AC-3; OWASP LLM06:2025 Excessive Agency
GPTs	Approved action domains; link and Store sharing restricted; third-party GPTs limited	CSF 2.0 GV.SC-07; A.5.19, A.5.23
Data	Retention period set to policy; EKM and residency decided at contract; DLP on Compliance data	CSF 2.0 PR.DS-01; SP 800-53 SC-28; A.8.12; ASVS V14.2.7
Logging	Continuous export of all log types to SIEM and archive with your own retention	CSF 2.0 PR.PS-04, DE.CM-03; SP 800-53 AU-2, AU-6, AU-11; A.8.15

Rolling out the baseline

Inventory current state: export members, roles, enabled apps, shared GPTs and settings; record which users are not SCIM-managed.
Fix identity first: enforce SSO after confirming break-glass owner access and checking API Platform users on the same domain; move users to SCIM groups, then turn off automatic account creation.
Start log export before tightening anything, so changes are recorded and the 30-day window is never lost.
Pilot role and app changes on one group: because role changes take minutes and IP allowlist changes 5 to 15 minutes, test in a pilot group and keep the previous role assignment to restore if users lose needed access.
Enable apps and agent features per use case, each with an owner, the minimum actions and a review date.
Review quarterly: owners and admins, apps with write access, GPT sharing and seat reconciliation against the identity provider.

Smaller organisations: focus on SSO, apps off by default, a single owner pair and log export to an existing SIEM or archive.
Larger organisations: add custom roles by data sensitivity, DLP on the Compliance data, residency and EKM decisions at contract, and connector approval through the existing SaaS integration process. See the Enterprise AI Copilot Security Guide.

Common misconfigurations

SCIM alongside automatic account creation: users created by auto-join are not SCIM-managed and survive offboarding in the identity provider.
Assuming group sync grants or removes access: access follows Product access assignment, and a disabled IdP user may keep the assignment.
A restrictive role layered on a broad one: union semantics mean the broad role wins.
Allow all actions on a write-capable app: the assistant can change records without asking, and a prompt injection in retrieved content can drive it. The Chevrolet Dealer Chatbot 2023 case, a public dealer bot rather than an enterprise workspace, shows how easily instructions in user input override intent.
Connector tokens treated as low risk: OAuth grants to AI integrations are durable access; the Salesloft Drift Breach 2025 showed stolen tokens from one chatbot integration opening hundreds of Salesforce tenants.
Relying on the 30-day log window: an incident found on day 31 has no workspace evidence unless logs were exported.
Leaving consumer use unmanaged: an enterprise workspace only protects data that goes into it. The Samsung ChatGPT Source Code Leak 2023, in which staff pasted source code and a meeting transcript into the public service, is the reason to pair the workspace with discovery and blocking of personal accounts. See the Shadow AI Discovery Guide.

Practitioner checklist

Verify domains, enforce SAML SSO and keep a tested break-glass owner path.
Provision through SCIM groups and turn off automatic account creation; reconcile seats against the IdP monthly.
Limit owners to two or three named people and design custom roles as additive.
Restrict Compliance API access to one vaulted, IP-allowlisted integration identity.
Keep apps off by default, enable per role, and avoid Allow all actions on apps with write access.
Set approved GPT action domains and restrict link and Store sharing.
Enable agent features only for named groups with domain blocklists, and monitor connected systems for agent writes.
Export every log type continuously to your SIEM and archive.
Set retention to policy and decide residency and EKM at contract stage.
Block or monitor personal AI accounts so sensitive work stays in the managed workspace.

ChatGPT Enterprise Security Guide: Admin Controls, Data and Connectors