OpenAI details how it secures Codex: sandboxes, approvals, and agent activity audits

On May 8, 2026, OpenAI explained exactly how it constrains Codex in its own internal workflows. The idea is simple: a coding agent should speed up development, but it should not get unchecked access to files, the network, or infrastructure.

Boundaries for Codex

The first layer of defense is the sandbox. It sets the technical limits: where Codex can write, which directories are writable, whether network access is allowed, and which paths stay protected.

An approval policy sits on top of that. If the agent needs to do something outside the permitted environment, it must ask for confirmation. The user can approve a single action or grant permission for that type of action for the rest of the session. This reduces the risk of accidental or opaque operations.

OpenAI also uses a separate Auto-review mode. When Codex is about to cross the sandbox boundary, it hands its planned action and recent context to a dedicated auto-approval subagent. That subagent can automatically approve low-risk requests and, in some cases, more sensitive ones if the user already has sufficient authorization. As a result, routine tasks don't slow work down, while potentially dangerous actions still get stopped for review.

"Keep the agent within clear technical boundaries, speed up low-risk actions, and explicitly flag risky ones" — that is how

OpenAI describes the goal of this setup.

Network, access, rules

The second layer is access control. OpenAI does not give Codex unrestricted outbound internet access: the network policy allows expected destinations, blocks unwanted ones, and requires approval for unfamiliar domains. Even search and web fetch can be restricted to cached responses.

CLI and MCP OAuth credentials are stored in the system keyring, sign-in is forced through ChatGPT, and access is bound to a specific enterprise workspace. This keeps the agent's activity inside the company's control perimeter.

• The only permitted sandbox modes are read-only and workspace-write
• Only known, predefined working directories are automatically opened for writing
• For networking, admins can enable a proxy, allow localhost, and block specific domains
• Known addresses such as *.openai.com can pass without manual approval
• Administrative requirements cannot be disabled on the user side

Shell commands get their own rules. Codex does not treat all commands as equally safe: ordinary read-only operations can run without confirmation even outside the sandbox, while dangerous patterns can be blocked or sent for review. In OpenAI's example, reading pull requests via gh pr view and list, as well as Kubernetes diagnostics via kubectl get, describe, and logs, are allowed without extra prompts.

The company rolls out the baseline policy through managed configs and requirements, so the same controls apply in the desktop app, the CLI, and the IDE extension.

Logs that explain

OpenAI stresses that restrictions alone are not enough. Standard security logs are good at showing what happened: a process started, a file changed, a network connection was attempted. But they make it hard to reconstruct what the agent and the user intended.

That's why Codex can export OpenTelemetry logs with richer agent context: the user's original prompts, approval decisions, tool call results, MCP server usage, and network proxy events — what was allowed and what was blocked. For Enterprise and Edu customers, this activity is also available through the Compliance Logs Platform, and the logs can be centralized in SIEM and compliance systems.

Inside OpenAI, an AI agent uses this data for security triage. When endpoint protection flags unusual Codex activity, the security team looks beyond the alert itself to the surrounding logs: what the original prompt was, which tools ran, what the agent tried to do, what decisions the network layer made, and where approval was required.

This helps the team quickly separate expected behavior from a harmless mistake and from a case that genuinely needs escalation. The same logs are also used operationally — to understand how internal Codex usage is growing, which tools are in demand, and where the policy still needs tuning.

What it means

OpenAI is effectively presenting an enterprise template for coding agents: not a smart model instead of controls, but a model inside a tightly configured environment with auditing and rules. For companies that want to deploy these assistants, it's a signal that the key product question is no longer only model quality, but also how well the model fits into security, compliance, and internal processes.