OpenAI has revealed how to safely deploy its AI code agent Codex. The core strategy is "sandboxing execution boundaries + automatic approval of low-risk actions + AI safety classification agent handling alerts," allowing development efficiency to run in sync with enterprise security management. (Background: Major upgrade to OpenAI Codex: backend control of Mac, built-in browser, image generation, and the launch of 111 new plugins) (Additional context: OpenAI's newly launched engineer agent Codex! AI can write functions, fix bugs, and run tests) OpenAI this week released an internal deployment report detailing how its security team executes Codex in production environments. This is a practical operational record, revealing what security management needs to cover when AI agents are adopted by large organizations, from sandbox configuration to alert classification. Sandbox defines boundaries, and the approval mechanism determines when to pause. OpenAI stated in its official announcement that the core principle for deploying Codex is simple: keep the agent efficient within clear technical boundaries, allowing low-risk behavior to proceed without interrupting users, while high-risk behavior must pause for human review. This principle is implemented through two complementary mechanisms: sandboxing and approval strategies. The sandbox defines the execution space for Codex, including which paths can be written to, whether external internet access is allowed, and which system directories are protected. Actions outside the sandbox must enter the approval process. Users can approve a specific action in one go or allow that type of action to auto-pass throughout the entire work session. For routine operations, OpenAI has enabled an "auto-review mode." This feature synchronizes the actions Codex plans to execute with recent operational context to an "automatic approval sub-agent." If the sub-agent determines the action is low-risk, it is approved directly without interrupting the user's workflow; if deemed high-risk or potentially having unintended consequences, it escalates to human confirmation. The logic for network control works the same way. Codex does not allow open external access; OpenAI maintains a whitelist listing target domains that Codex needs to access during its normal workflow. Domains outside this list are blocked by default, and unfamiliar domains trigger the approval process. Authentication is also included in the control scope. CLI and MCP OAuth credentials are stored within the operating system's secure keyring, and login must go through the ChatGPT enterprise workspace, thus integrating Codex's operations into the ChatGPT enterprise compliance log platform, which the security team can review. Which commands are exempt from approval and which are blocked outright? OpenAI does not treat all Shell commands as equal risk but has established a layered set of rules. Common harmless commands used by engineers during development are allowed to execute directly outside the sandbox without approval. Specific high-risk commands are either blocked outright or require mandatory approval. This set of rules operates through three levels: Cloud management requirements (enforced by admins, users cannot override), managed macOS preferences, and local requirement profiles. This structure allows OpenAI to test different configuration combinations while maintaining a unified baseline across the company, tailored to team, user group, or environmental needs. The same settings apply to Codex desktop applications, CLI, and IDE plugins across all local interfaces. This stands in direct contrast to external research findings: studies show that AI-generated code has a 57% higher rate of security vulnerabilities than human-written code. GitHub Copilot was also revealed to have a severe vulnerability with a CVSS score of 9.6 (CVE-2025-53773), allowing remote code execution via prompt injection. These data suggest that when enterprises adopt AI code agents, without corresponding layered controls, exposure can exceed expectations. OpenAI's approach is to embed control logic within the configuration layer, rather than relying on the AI agent's own judgment, making rule enforcement a technical fact rather than an operational habit. AI security classification agent OpenAI emphasizes in its official announcement that no matter how well security controls are implemented, visibility is still required after deployment. Traditional security logs can answer "what happened," such as a program starting, a file being modified, or a network connection attempt being made. However, what security personnel really need to know is "why did Codex do that" and "was this the user's original intent?" OpenAI enables Codex to support OpenTelemetry log output, with a scope including: user prompts, tool approval decisions, tool execution results, MCP server usage, and events of network proxy allowance or denial. Enterprise and educational clients can also access these logs via the OpenAI compliance platform. More crucially, OpenAI has integrated these logs into an "AI security classification agent." When endpoint detection tools identify suspicious behavior from Codex and trigger alerts, this AI classification agent will automatically pull relevant Codex logs, reconstructing the original requests, tool activities, approval decisions, tool results, and related records of network policies to generate an analysis report for the security team to review, assisting in determining whether this is normal agent behavior, a harmless mistake, or an event that truly requires escalation. The same telemetry data is also used for internal operational analysis: tracking internal adoption trends, understanding which tools and MCP servers are used most frequently, assessing the blocking and triggering frequency of the network sandbox, and determining which deployment configurations still need adjustment. These OpenTelemetry logs can be aggregated into SIEM and compliance log systems. For organizations still on the fence about AI agent security, this report serves as a reference checklist: if your deployment plan hasn’t covered these four layers, risks may be lurking there.