Securing ChatGPT and Codex with AiriaNewEnterprise

OpenAI ships more than one desktop app, and they do not behave the same way. The current ChatGPT app has three surfaces: Chat, Work, and Codex. Its Codex and Work surfaces can be pointed at your Airia AI Gateway, along with the Codex CLI and IDE extension, and once they are, agent turns, tool calls, and computer use all travel through Airia. Chat inside the app talks to chatgpt.com directly and has no endpoint setting, so you govern it the same way as chatgpt.com in a browser.

This guide covers which surface is which, how to route the ones that can be routed, what governance you get once they are, and how to cover the rest.

Start here: which app and surface

The app name doesn't tell you whether it routes. The bundle ID and the surface do.

The app labeled simply ChatGPT is the Codex app that absorbed ChatGPT, which is why its bundle ID is com.openai.codex and why its Codex and Work surfaces read Codex's configuration file.

1 · Route Codex through the AI Gateway

The ChatGPT app's Codex and Work surfaces, the Codex CLI, and the Codex IDE extension all read the same configuration file and honor a custom model provider. Point that provider at your Airia AI Gateway and every model call from those surfaces travels through Airia.

ChatGPT app (Codex · Work) · Codex CLI · IDE  →  Airia AI Gateway  →  OpenAI
                                                ↓  DLP · Guardrails · Agent constraints · Budgets · Audit

A · Build the gateway

Full configuration reference: AI Gateway.

B · Point Codex at the gateway

Codex has no settings screen for this. The configuration file is the interface, and every Codex surface reads the same one:

Set the CODEX_HOME environment variable to use a different directory.

Find your base URL. In Secure → Gateway → AI Gateway, click Gateway URL to copy your tenant's gateway endpoint, then append /openai/v1.

Let Airia write the file. On the gateway configuration, choose Integrate, then Automate Codex Setup to download a setup script for the user's operating system. The script adds the Airia provider to the user's existing config.toml and supplies the key for the model access choice you made. To write the file by hand instead, use the tab that matches that choice:

model_provider = "airia"

[model_providers.airia]
name = "Airia Gateway"
base_url = "https://<your-gateway-url>/openai/v1"
wire_api = "responses"
env_key = "AIRIA_GATEWAY_KEY"

AIRIA_GATEWAY_KEY=agk-your-gateway-key

A few details decide whether this works:

• model_provider is a top-level key. Keep it above every [table] in the file, and keep exactly one. A second or misplaced model_provider makes the whole file invalid, and Codex silently ignores it.
• Add to the file, don't replace it. It likely already holds marketplace, plugin, MCP, and project sections that the app wrote. The setup script merges for you.
• wire_api = "responses" is required. Codex speaks the OpenAI Responses API, not Chat Completions.
• Environment variables alone don't route. Codex does not redirect traffic based on OPENAI_BASE_URL. The config.toml provider is the routing path; the environment variable carries only the key.

C · Confirm it is actually routing

Send one turn from each surface you care about, then open Gateway → Analytics → Gateway Monitoring. Every routed call appears with the user, the model, the token count, and a userAgent that tells you which surface produced it.

To roll back, remove the model_provider = "airia" line from config.toml (the [model_providers.airia] table can stay) and restart the app.

D · Push it to the fleet

A configuration file each developer edits by hand is a pilot, not a rollout. Two ways to make it stick:

2 · What you get once it's routed

Everything attached to that gateway configuration now applies to every routed Codex and Work session:

Lock down local behavior

The gateway sees model traffic. Codex's local actions (file edits, shell commands, sandbox mode) are governed by OpenAI's own admin enforcement: a requirements.toml file that users cannot override. Deploy it with your MDM, or manage the same settings from the Codex Policies page if you have ChatGPT Business or Enterprise.

A typical enterprise baseline:

• Pin the Airia provider. Set model_provider = "airia" and the same [model_providers.airia] table you use in config.toml. The admin file takes precedence, so every Codex surface stays routed through the gateway.
• Block the unsandboxed mode (danger-full-access) so Codex always runs sandboxed.
• Disallow the "never ask" approval policy so destructive actions always require review.
• Allowlist MCP servers to your Airia MCP Gateway entry so unsanctioned local tools can't be added.
• Deny known-dangerous commands, for example unencrypted curl http:// calls.

When a user's own configuration conflicts with the admin file, the most restrictive setting wins and Codex tells the user. See OpenAI's Codex documentation for the full requirements.toml reference.

3 · Govern the tool side with the MCP Gateway

Routing inference does not govern the tools the model calls. Point Codex at the Airia MCP Gateway and every downstream credential is managed centrally, behind one authenticated URL, instead of scattered across local configurations in plaintext.

On your MCP gateway, open Client Setup → ChatGPT & Codex for the steps for each client: the desktop app, the IDE extension, the Codex CLI (codex mcp add), or config.toml directly. All of them write the same Codex MCP configuration on the device, so connecting once covers every Codex surface. Users authenticate through OAuth on first connect.

Setup and credential management: MCP Gateway.

4 · Cover the surfaces that don't route

Four surfaces sit outside the gateway's reach. Cover each one with a different control.

The browser and shadow-AI answer

The Airia Browser Extension is the control point for chatgpt.com. It is domain-scoped, offering Block, Warn, Monitor, or Redirect at the AI-service domain, with optional request-body capture so your DLP detectors can run against what was actually typed. Redirect is the useful one here: send chatgpt.com to your sanctioned Airia deployment instead, so people keep working on a governed surface.

Configure under Secure → Runtime Security → Browser Extension Policies, and force-install it through your MDM so users can't remove it. Deployment steps: Browser Extension MDM Deployment.

For traffic you can see on the network but not on the endpoint, chain your secure web gateway into an Airia AI Gateway rather than blocking it outright. The user keeps working and the call picks up your policies. See SASE Integration.

Close the direct path

The gateway enforces on the traffic it receives, so close the direct paths from managed devices at the firewall or SASE layer. Codex uses a different OpenAI endpoint depending on how the user signs in:

Block both. A block on api.openai.com alone covers API-key use only. The gateway calls OpenAI from Airia's side, not from the device, so gateway-routed traffic, including OAuth Passthrough, keeps working with both blocks in place.

Recommended build

1. One AI Gateway configuration for OpenAI, with your DLP policies, guardrails, agent constraints, and a budget attached.
2. Per-user gateway keys, so the audit trail names people.
3. config.toml pushed by MDM with requirements.toml alongside it, then the endpoint agent in enforce mode to make it stick.
4. Agent constraints scoped to Gateway.
5. The MCP Gateway for the tool side, replacing local server entries.
6. Browser extension policy on chatgpt.com, force-installed.
7. Egress blocks on api.openai.com and chatgpt.com/backend-api/codex.
8. A weekly look at the gateway feed. An active developer with no gateway traffic for a week is worth a follow-up to confirm their client still routes through the gateway.

For the Anthropic equivalent of this build, see Securing Claude with Airia.