OpenAI Enterprise Security: The Admin Controls and the Layer Above Them

OpenAI presents an enterprise with two surfaces that need securing separately: ChatGPT Enterprise, where people type prompts into an application, and the OpenAI API at https://api.openai.com/v1/chat/completions, where applications and agents send prompts programmatically with a bearer token. Both come with a real admin control set. Neither evaluates whether the authenticated caller is permitted to send this particular prompt to a model. I want to walk the controls on both surfaces, mark where they stop, and show the authorization pattern for the part that stays with you.

What ChatGPT Enterprise secures

ChatGPT Enterprise is the sanctioned application surface, and its controls are aimed at replacing the personal accounts employees were already using.

Identity. SAML single sign-on and SCIM provisioning connect the workspace to your identity provider, so accounts follow your joiner-mover-leaver process rather than personal email addresses. Admin roles and workspace settings gate configuration.

Data handling. Business and enterprise traffic is not used to train OpenAI's models by default, and the workspace offers retention controls and encryption of data at rest and in transit.

Compliance surface. Enterprise plans expose a compliance and audit API and admin logs that record workspace activity, plus controls for data residency on qualifying agreements.

What the OpenAI API secures

The API surface is where agents and applications live, and its controls are structured differently.

Projects and scoped keys. The platform organizes usage into organizations and projects, with API keys scoped to a project and per-project rate and spend limits, so a leaked key has a bounded reach.

Usage and audit records. The organization exposes usage and audit-log endpoints that report which key made calls and when, from OpenAI's vantage point.

Where those controls stop

Both surfaces authenticate and account for the caller, and neither reads the request against your policy. SSO confirms the employee and does not evaluate the prompt content. The no-training default protects OpenAI's handling of your data and says nothing about which employee may send that data. Project-scoped API keys bound blast radius by project, not by the person delegating a task to an agent that holds the key. The compliance and audit logs record activity from OpenAI's vantage point, so they lack your policy state at the moment a specific prompt was sent. And the biggest exposure sits outside the enterprise surfaces entirely: an employee who never joined the ChatGPT Enterprise workspace and pastes source code into a personal account is shadow AI the admin console cannot see.

The post-authentication gap on OpenAI traffic

After authentication, a question remains unanswered. SSO and a valid API key confirm who is calling. They do not answer whether this caller, in this role, may send this prompt, carrying this data classification, to this model right now. A provisioned engineer with a valid session can paste a customer database export into a completion request, and every OpenAI control passes it: the SAML assertion is valid, the project key is authorized, the data is not used for training, and the audit endpoint logs the call. This is the post-authentication gap, an authorization problem at the request layer that account controls do not reach.

Identity-aware authorization on OpenAI API calls

Closing the gap means evaluating the request on the path to the model, against the caller's identity and the prompt's data. That is a policy decision point in front of api.openai.com. A raw call looks like this:

An identity-aware enforcement layer intercepts the request, resolves the caller identity, classifies the prompt, evaluates policy, and either forwards the call or returns a decision before the model is reached:

The evaluation is deterministic and fail-closed, and it commits that record independently of the calling application before any response returns. The same enforcement point also catches traffic to personal accounts routed through the corporate network, which is where shadow AI usage becomes visible for the first time.

Compliance framing

For regulated OpenAI workloads, the vendor audit endpoint is not the record a regulator expects. EU AI Act Article 12 requires automatic, traceable event logging for high-risk systems, including inputs and the natural persons involved, applying from August 2, 2026 per the European Commission. A log written from the vendor's vantage point is weaker evidence than an identity-bound record produced independently of the application under review.

DeepInspect

This is exactly what DeepInspect does. DeepInspect is a stateless proxy that sits inline in front of the OpenAI API, and because it is model-agnostic, the same layer governs OpenAI alongside Claude, Bedrock, Azure OpenAI, Vertex, and self-hosted models. For every request it evaluates the caller's identity, role, the data classification in the prompt, and organizational policy, then returns a pass or block decision before the traffic reaches the model. Enforcement adds under 50 milliseconds in internal testing, invisible against the model's response time, and defaults to deny on ambiguity.

For every decision it commits an identity-bound audit record before the response returns, written independently of the calling application. That record carries the identity, policy, data classification, and outcome that OpenAI's usage logs never held, and it captures the shadow-AI traffic the admin console never saw. DeepInspect does not replace ChatGPT Enterprise SSO, project keys, or OpenAI's data-handling terms. It adds the authorization-and-audit layer above them, on the request itself. Book a demo today.