Does ChatGPT Enterprise cover our API traffic?

Not directly, because API traffic runs against API keys, which are separate from the ChatGPT Enterprise workspace. The API side has its own admin controls and audit surface, but the audit records identify that credential, not the natural person behind the calling application.

Can OpenAI train on our ChatGPT Enterprise data?

No. The training exclusion is in the enterprise agreement and the API terms for equivalent tiers. The exclusion covers the API tier the enterprise agreement references; it does not cover consumer tiers your employees might use on personal accounts.

How do we prevent employees from using consumer ChatGPT?

DNS blocking on the consumer domain, network-level policy in the enterprise proxy, and endpoint detection for browser sessions to consumer AI URLs cover the three detection layers, walked through in the shadow AI detection piece linked above.

Does the audit log satisfy SOC 2 or ISO 27001 audit requirements?

The ChatGPT Enterprise audit log covers the workspace activity, which is a narrower scope than what SOC 2 control CC7.2 and ISO 27001 Annex A 8.15 test. Those controls ask for records of AI decisions made on behalf of specific identities across the deployer's environment. That question requires records at the AI request boundary in the deployer's environment, not just at the vendor boundary.

Can we bring our own encryption keys for SOC 2 control?

Yes, through OpenAI's EKM (Enterprise Key Management), available for ChatGPT Enterprise and Edu workspaces with a named OpenAI account representative. EKM lets the customer hold the encryption material in their own AWS, Google Cloud, or Azure account, so OpenAI cannot decrypt stored conversations without the customer's material being available. That satisfies the custody question a SOC 2 auditor asks. It does not satisfy the traceability question: EKM has no concept of which natural person made a given request, what data classification applied, or what policy decision followed. Those records still have to come from the request boundary, not the storage layer.

What is the SCIM boundary?

SCIM provisions and deprovisions ChatGPT Enterprise workspace access. It does not manage API keys, custom GPT authorship, or third-party extensions that call the OpenAI API. When an employee leaves, SCIM revokes their workspace access; API keys they created, custom GPTs they authored, and extensions they installed continue to hold access unless separately revoked.

How does ChatGPT Enterprise interact with the OpenAI Agents SDK?

The Agents SDK is a framework for building autonomous agents on top of the OpenAI API. Its authorization surface is the API credential the developer wired in. The ChatGPT Enterprise workspace's SCIM does not apply, and the same tool-scoping gap shows up across other agent frameworks that authorize by static credential rather than by the identity of the person or process the agent is acting for.

ChatGPT Enterprise Controls: What OpenAI Ships, What Deployers Still Own

OpenAI ships ChatGPT Enterprise with a set of enterprise controls the sales conversation covers in a single slide: SSO, SCIM for user provisioning, data-retention controls with configurable windows, audit log export, an admin API, no training on business data. The controls satisfy the direct-use surface where employees log into ChatGPT and interact with the model through the web app or the mobile client. What the controls do not cover is the traffic that flows around the direct-use surface: employees copying ChatGPT output into other tools, internal applications calling the OpenAI API with a shared service credential, custom GPTs pulling data from company systems, and browser extensions that inject ChatGPT into workflows OpenAI never sees. I want to walk through the boundary map, the ownership split, and the controls the deployer still owns after ChatGPT Enterprise is deployed.

The Enterprise tier draws a line at the ChatGPT product's edge. Enterprise AI usage crosses that line at multiple points.

TL;DR

ChatGPT Enterprise ships SSO, SCIM, data retention controls, audit log export, admin and Compliance APIs, data residency, a June 2026 usage-analytics and spend-limit dashboard, GPT action domain allowlisting, and EKM for customer-held encryption at rest. None of that reaches API traffic under a shared credential, consumer ChatGPT use on the same browser, custom GPTs pulling from external APIs, browser extensions and copilots calling the API under a vendor's service account, or what an employee does with the output after it leaves ChatGPT. EKM answers who can decrypt stored data; it does not answer which person triggered a given request. That gap is what the deployer still owns.

The controls ChatGPT Enterprise ships

The ChatGPT Enterprise page lists the controls in the current offering.

SSO and SCIM. SAML SSO runs through the enterprise identity provider (Okta, Azure AD, Google Workspace), and the SCIM protocol handles user provisioning and deprovisioning. Deprovisioning removes access to the workspace but does not, on its own, retrieve any output the user already copied out of ChatGPT.

Data retention controls. Workspace admins configure the retention window for conversations. The default is unlimited retention on the enterprise plan; admins can shorten to a specific window. Conversations older than the window are deleted from OpenAI's active systems, with the standard security-review retention window for legal and abuse investigation.

Training data exclusion. OpenAI does not train on ChatGPT Enterprise conversations. The clause is in the enterprise agreement and in the API terms for the equivalent API tiers.

Audit log export. Admins export audit logs of workspace activity: user login, GPT creation, file uploads, admin changes. The export lands in JSON or CSV for ingestion into the SIEM.

Admin API and Compliance API. Programmatic access to workspace metadata for automation. The Compliance API extends the audit log export with additional fields for regulated deployments.

Storage and processing region. Data residency options for EU, US, and other regions. OpenAI expanded data residency to more regions for ChatGPT Enterprise, ChatGPT Edu, and the API Platform in 2026, letting eligible customers keep data at rest in-region.

Usage analytics and spend limits. OpenAI added a usage-analytics dashboard and credit controls to the Global Admin Console on June 18, 2026. Admins see ChatGPT and Codex credit consumption by user, product, and model, and set a default spend limit for the whole workspace, with team-level limits and individual overrides for power users. The same release let workspace admins restrict which external domains a custom GPT's actions can call, replacing an open-ended action surface with an approved list. The dashboard answers "who is using what" for cost, not for regulatory audit: a spend record shows credits consumed, not the identity claim, data classification, or policy decision behind a given request.

Enterprise Key Management (EKM). OpenAI ships EKM for ChatGPT Enterprise and Edu workspaces, letting the customer encrypt content at rest with credentials held in their own AWS KMS, Google Cloud KMS, or Azure Key Vault account rather than a credential OpenAI controls. EKM answers the SOC 2 and internal-security question of who can decrypt stored conversations. It does not produce a per-decision audit record: EKM controls the encryption material, not the identity claim, classification outcome, or policy decision attached to any individual request.

Where the controls stop

Five patterns fall outside the ChatGPT Enterprise boundary.

Employees using the consumer ChatGPT. SSO covers the enterprise workspace. Nothing prevents an employee from logging into a personal ChatGPT account on the same browser and pasting company data into it. The shadow AI pillar covers the detection pattern.

API traffic to OpenAI. Applications calling the OpenAI API do so with an API key, not a user SSO session. The audit logs on the API side identify that credential, not the natural person behind the calling application. Zscaler's ThreatLabz 2026 AI Security Report documented a 93% year-over-year jump in enterprise data transfer to AI tools and 410M+ ChatGPT DLP policy violations, most of them on the API side, not the direct-use side.

Custom GPTs pulling data. A custom GPT authored inside the enterprise workspace can call external APIs to pull data. The GPT's calls run against the external API's credentials, which the GPT author configured. The ChatGPT Enterprise audit log shows the GPT was invoked; the external API's log shows the credential was used. Correlating the two requires connecting the identity claim across systems.

Browser extensions and copilots. Tools that inject ChatGPT into Slack, Notion, Google Docs, or Salesforce call the OpenAI API through their own credential, frequently the vendor's service account rather than the employee's. The employee's activity in the third-party app now generates AI traffic that OpenAI's audit log labels with someone else's identity.

The output side. Once a response leaves ChatGPT, whatever the employee does with it (paste into an email, screenshot into a chat, copy into a document) is outside the ChatGPT Enterprise control surface entirely.

The ownership split

The controls the deployer owns after ChatGPT Enterprise is provisioned:

Identity binding on API traffic to OpenAI, so the audit trail identifies the natural person or agent behind the calling application, not the shared API credential.
Data classification at the AI request boundary, so requests carrying PII, PHI, or regulated data hit policy before reaching the model.
Per-decision audit records that survive the auditor's specificity question. The SOC 2 AI controls piece covers the standard.
Detection of consumer ChatGPT use inside enterprise networks. The shadow AI detection piece covers the DNS, proxy, and endpoint patterns.
Policy enforcement across multiple AI vendors, not just OpenAI. Most enterprises are multi-provider by 2026, and the ChatGPT Enterprise controls apply only to OpenAI. The ai-firewall-vs-ai-gateway-vs-ai-proxy piece covers the category.

Regulatory framing

Under HIPAA, ChatGPT Enterprise ships a BAA-eligible tier for covered entities. The BAA covers the vendor relationship; it leaves the deployer safeguards (access control, minimum-necessary enforcement, breach notification on the deployer's own systems) for the deployer to build.

Under the EU AI Act, ChatGPT Enterprise is a foundation-model deployment. When the deployer uses ChatGPT for a high-risk use case (HR screening, clinical decision support, credit adjudication), the Article 26 deployer obligations apply to the deployer regardless of the vendor tier. Article 12 logging applies to the deployer's environment, not just OpenAI's. Article 50 transparency obligations took effect August 2, 2026, unchanged by the Digital Omnibus deferral.

Under SOC 2, ChatGPT Enterprise's own SOC 2 report covers OpenAI's controls. The deployer's SOC 2 with AI in scope tests the deployer's identity binding, audit trail, and policy enforcement on the deployer's side of the boundary.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits inline between the enterprise applications and agents that call the OpenAI API and the API endpoints themselves, and does the same for Anthropic, AWS Bedrock, Azure OpenAI, Google Vertex, and any other provider. Every request binds to a verified identity claim before it reaches the provider. Every response passes back through the same layer. The audit record includes the natural-person identity, the provider, the model, the data classification, and the policy decision.

The controls extend to the browser-extension and copilot surface through egress inspection of the outbound HTTPS traffic to the AI provider endpoints. The ai agent egress control piece covers the pattern.

Book a technical deep dive at deepinspect.ai.