Does ChatGPT Enterprise cover our API traffic?

Not directly. The 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 the API key, 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. The shadow AI detection piece covers the detection layers.

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

The ChatGPT Enterprise audit log covers the workspace activity. For SOC 2 CC7.2 and ISO 27001 Annex A 8.15, the auditor asks 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.

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 key the developer wired in. The ChatGPT Enterprise workspace's SCIM does not apply. The ai agent tool scoping piece covers the authorization pattern that extends across agent frameworks.

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.

The controls ChatGPT Enterprise ships

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

SSO and SCIM. SAML SSO through the enterprise identity provider (Okta, Azure AD, Google Workspace). SCIM 2.0 for 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.

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 the API key, not the natural person behind the calling application. Zscaler's ThreatLabz 2026 AI Threat Report documented a 93% year-over-year jump in employees moving enterprise data into 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. Extensions that inject ChatGPT into other tools (Slack, Notion, Google Docs, Salesforce) call the OpenAI API through the extension's credential, which frequently is the extension vendor's service account, not the employee's. The employee's activity in the third-party tool now generates AI traffic OpenAI's audit log labels with a third party'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 key.
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; the HIPAA BAA for AI vendors piece covers the deployer safeguards the BAA does not discharge.

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 still take 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.