OpenAI this week released an internal deployment report that pulls back the curtain on how its security team runs Codex in production. The core strategy: sandboxes that define execution boundaries, auto-approval for low-risk actions, and an AI-powered safety classifier to triage alerts—all designed to let developers move fast without breaching enterprise security.
Sandbox Boundaries and a Stop-Or-Go Approval System
The guiding principle, OpenAI says, is simple: let the agent stay efficient within clear technical limits, interrupt users only for high-risk actions, and let low-risk actions pass without friction. This is enforced through two complementary mechanisms: a sandbox and an approval strategy.
The sandbox dictates where Codex can write files, whether it can reach external networks, and which system directories are off-limits. Actions outside the sandbox require human approval. Users can greenlight a specific action once, or approve an entire class of actions for the duration of a session.
For routine operations, OpenAI turned on auto-review mode: a sub-agent receives the planned action along with recent context, decides if it's low-risk, and if so, lets it through without interrupting the user. Only actions flagged as high-risk or potentially unintended are escalated for manual review.
Network access is similarly gated. Codex relies on an allowlist of domains it needs for normal workflows. Anything outside that list is blocked by default; hitting an unknown domain triggers the approval flow.
Authentication is also locked down. CLI and MCP OAuth credentials live in the OS keychain, and login is forced through the ChatGPT enterprise workspace. That way, every Codex action lands in the ChatGPT enterprise compliance log, giving security teams a single pane of glass.
Tiered Command Rules: What Passes and What Gets Blocked
Not all shell commands are treated equal. OpenAI built a layered rule system: harmless commands commonly used in daily development can run outside the sandbox without approval; specific high-risk commands are either blocked outright or forced through approval.
The rules stack through three levels: cloud-managed requirements (enforced by admins, users can't override), macOS managed preferences, and local configuration files. This lets OpenAI maintain a company-wide baseline while testing different configurations per team, group, or environment. The same rules apply to Codex's desktop app, CLI, and IDE extensions.
The move comes amid research showing AI-generated code introduces 57% more security vulnerabilities than human-written code. GitHub Copilot also recently disclosed a critical CVSS 9.6 bug (CVE-2025-53773) that allowed remote code execution via prompt injection. The message: without layered controls, AI coding agents can widen the attack surface faster than expected. OpenAI's approach bakes control logic into the configuration layer, not the AI itself.
An AI Safety Classifier to Explain What Codex Did
Controls alone aren't enough—visibility is key. Traditional security logs say what happened (a process started, a file changed, a connection attempted). Security teams need to know why Codex did it and whether it was the user's intent.
To answer that, OpenAI made Codex emit OpenTelemetry logs that capture: user prompts, tool approval decisions, tool execution results, MCP server usage, and network proxy allow/deny events. Enterprise and education customers can access these logs through the OpenAI compliance platform.
More crucially, OpenAI feeds those logs into an AI safety classifier agent. When an endpoint detection tool spots suspicious Codex behavior and fires an alert, this classifier automatically pulls the relevant Codex logs, reconstructs the original request, tool activity, approval decision, results, and network policy records, then compiles an analysis for the security team. The goal: decide if the event is normal agent behavior, a harmless mistake, or a real incident.
The same telemetry also powers internal analytics—tracking adoption trends, identifying which tools and MCP servers are used most, monitoring sandbox block rates, and finding configuration gaps. All OpenTelemetry logs can be fed into SIEM and compliance systems.