OpenAI Codex Security Benchmark v1.0: a CIS-style hardening standard

This benchmark defines a prescriptive security baseline for OpenAI Codex when it runs locally through the ChatGPT desktop app, Codex CLI or IDE extension, and when work is delegated to Codex cloud. It is written for security engineering, platform engineering, endpoint management, internal audit and development teams that need measurable controls around an agent that can read code, execute commands, use networks and invoke external tools.

Independent publication: this is a CIS-style benchmark, not an official CIS Benchmark and not an OpenAI certification. Product behaviour, CLI flags and configuration keys were checked against official OpenAI documentation and Codex CLI 0.147.0 on 15 August 2026.

How this benchmark uses CIS guidance

CIS Controls v8.1 remains the governing structure: inventory, data protection, secure configuration, identity, access control, vulnerability management, audit logging, network defence, supplier management, application security and incident response. The latest CIS Controls v8.1.2 AI Security Guidance Workbook, alongside the earlier AI and LLM, AI Agent and MCP Companion Guides, extends that structure to context integrity, prompt injection, tool misuse, excessive autonomy, non-human identities, agent supply chains and auditable actions. This benchmark turns those outcomes into Codex-specific settings and evidence.

The CIS implementation groups and this benchmark’s profiles are related but not identical. Level 1 is the minimum Codex configuration for ordinary development. Level 2 adds centrally enforced requirements for sensitive code, production access, regulated data, privileged repositories and managed fleets. Level 2 includes every Level 1 control. Automated means the pass or fail result can be determined from configuration and machine evidence without assessor judgment. A control is marked Manual when approval, provenance, appropriateness or an operator exercise must be assessed, even if automation supplies part of the evidence.

Traceability is outcome-based rather than a claim of one-to-one CIS conformance. Primary mappings include Safeguards 1.1 and 2.1 for asset and software inventory; 3.3 for data access; 4.1 for secure configuration; 5.1 and 6.1 for account inventory and access granting; 8.1 for audit-log management; 12.2 for secure network architecture; 15.1 for service-provider inventory; 16.1 for secure development; and 17.1 for incident handling. Each organisation must map these controls to its applicable Implementation Group, assets, legal obligations and accepted risk.

• Pass: every audit step is satisfied and the evidence identifies the client, version, device or cloud environment, user or service identity, policy source and assessment time.
• Fail: any required step is not satisfied, a security-sensitive value is merely recommended rather than enforced, or a lower-precedence setting cannot be proven effective.
• Not applicable: use only when the capability is technically disabled—for example MCP, plugins or Codex cloud. Record the disabling control and compensating boundary.
• Exception: record the owner, business justification, affected assets, expiry, compensating controls and explicit security approval.

Reference architecture

Level 1 — minimum baseline

approval_policy = "on-request"
sandbox_mode = "workspace-write"
web_search = "cached"

[sandbox_workspace_write]
network_access = false
exclude_slash_tmp = true
exclude_tmpdir_env_var = true

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"GOOGLE_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"

This is the core local sandbox excerpt, not evidence that every Level 1 control is satisfied: command rules, MCP and extension inventory, project trust and transcript retention require separate configuration or assessment. The stable sandbox configuration above is intentionally separate from the beta permission-profile configuration later in this benchmark. OpenAI states that default_permissions/[permissions] and sandbox_mode/sandbox_workspace_write do not compose. Do not put both approaches in the same effective configuration.

Level 2 — managed and sensitive environments

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
allowed_web_search_modes = ["cached"]
default_permissions = "org_workspace"
check_for_update_on_startup = true
allow_login_shell = false
allow_managed_hooks_only = true
allow_remote_control = false
allow_appshots = false

[allowed_permission_profiles]
":read-only" = true
org_workspace = true
# :danger-full-access is omitted and therefore denied.

[permissions.org_workspace]
description = "Workspace-only access; no general filesystem read."
extends = ":workspace"

[permissions.org_workspace.filesystem]
":root" = "deny"
":minimal" = "read"
":tmpdir" = "deny"
":slash_tmp" = "deny"
glob_scan_max_depth = 4

[permissions.org_workspace.filesystem.":workspace_roots"]
"**/*.env" = "deny"
"**/.env.*" = "deny"
"**/secrets/**" = "deny"

# An explicitly empty allowlist disables every MCP server.
[mcp_servers]

# Permit marketplace operations only from this administrator-owned directory.
[marketplaces]
restrict_to_allowed_sources = true

[marketplaces.allowed_sources.company_plugins]
source = "local"
path = "/opt/company/codex-plugins"

[features]
apps = false
browser_use = false
browser_use_external = false
browser_use_full_cdp_access = false
computer_use = false
in_app_browser = false
memories = false
multi_agent = false
plugin_sharing = false
plugins = false
remote_plugin = false
workspace_dependencies = false

This Level 2 example deliberately disables all MCP servers and permits user-configured marketplace operations only from the example administrator-owned local directory, which must be replaced with a real protected source or removed with marketplace functionality. Where MCP is required, replace the empty mcp_servers table with an administrator-approved entry that matches both the configured name and exact command identity or URL. OpenAI documents marketplace restriction with one or more allowed sources; this benchmark does not assume that restrict_to_allowed_sources with no allowed_sources table is a supported deny-all pattern. OpenAI-managed marketplaces may remain available where the product recognises their reserved source and name, so retain features.plugins = false when the requirement is no plugin execution at all.

Validation and reassessment requirements

A secure-looking TOML file is not evidence that Codex enforced it. First parse TOML with an independent parser, then run codex doctor --json so the deployed client loads its configuration and emits a redacted diagnostic report. Neither step proves enforcement: inspect /status and effective permissions and run positive and negative tests against filesystem, network, command-rule, MCP and feature boundaries. Test every supported operating system and client because platform enforcement and feature coverage differ. For permission profiles, prove the active profile and blocked behaviour on Codex 0.138.0 or later. Codex 0.147.0 accepts --strict-config with some commands, but codex --strict-config --version can exit successfully without loading or rejecting an unknown configuration key and shall not be used as validation evidence.

codex --version
codex doctor --json > codex-doctor-redacted.json
codex features list
codex mcp list

# Repeat --rules for every active managed, user and trusted-project rule file.
# Record the expected decision; process success or matchedRules=[] is not a pass.
codex execpolicy check --pretty --rules <active.rules> -- git status
codex execpolicy check --pretty --rules <active.rules> -- git push --force

# In an interactive test workspace also capture and verify:
# /status
# /permissions
# /mcp
# a harmless write outside the workspace (must be blocked or require approval)
# an unapproved network request (must be blocked)
# selection of a non-allowlisted profile, MCP server and feature (must fail)

Reassess after every Codex update, managed-policy change, new MCP server, plugin, hook, skill, app or browser capability, authentication change, cloud-environment change and at least quarterly. Beta controls—including permission profiles and the managed network proxy—require explicit version and platform regression tests. Do not suppress unstable-feature warnings as a substitute for governance.

Minimum evidence package

Retain: Codex client and version; operating system; local or cloud surface; workspace identity; user or service identity; effective config layers and requirements sources; /status, /permissions and /mcp output; permission-profile or sandbox negative tests; command-rule test output; extension inventory; CI or cloud environment definition; telemetry delivery and alert tests; open exceptions; assessor; control owner; and assessment timestamp.

The standard in one sentence

Give Codex the smallest trusted workspace, filesystem, network, identity and tool surface required for the task; enforce those boundaries outside the model; assume every external instruction can be hostile; and retain evidence that prohibited actions really fail.