Codex Security Assessment

The question it answers

For every place Codex runs: if injected text hijacked the agent right now, what could it reach, and would you know? Everything below is a way of answering that question with evidence rather than assumptions.

Developer assessment (1 hour)

1. Run the audit (about a minute). The Codex Security Audit container checks your config, rules, hooks, MCP servers and a project of your choice, offline and read-only. Save the HTML report.
2. Work through the checklist. Items marked "manual" are the ones the audit cannot see: your sign-in, Codex cloud settings, working habits and endpoint protection.
3. Compare against the common misconfigurations and fix every Critical one first.
4. Prove the controls work with the ten-minute self-test below.
5. Keep the evidence: the audit report, the completed checklist and the test results. Re-run after each Codex upgrade and at least monthly.

The ten-minute self-test

Configuration you haven't tested may not do what you think. Make a throwaway project containing a fake .env, start Codex in it with the baseline config and rules, and ask for each of the following. Every one should be refused or stopped for your approval.

Then run codex execpolicy check on a few commands, and /hooks to confirm only the hooks you expect are trusted. The config and rules it tests are in the audit's fix section. Re-run it after every Codex upgrade.

Team assessment method

For a team or organisation, allow two to four weeks across 6 phases:

1. Scope and inventory. List the surfaces in use (CLI, IDE extension, desktop app, Codex cloud, GitHub, Slack, Linear, non-interactive runs, SDK harnesses), sign-in methods, versions, MCP servers, plugins, skills, hooks, rules and repositories. Useful sources: EDR process inventory, workspace analytics, and a code search for .codex/ and AGENTS.md.
2. Threat model. For each place Codex runs (laptop, container, CI runner, Codex cloud), write down the identities and credentials it holds and the data and systems it can reach. That list is your blast radius.
3. Configuration review. Compare each developer's effective config.toml, rules and hooks, the managed requirements.toml, and cloud environment settings with the checklist. On each developer machine, the audit container does the local part in about a minute.
4. Technical testing. Try to break it, safely, in a test project: read a planted fake secret, reach a host that is not allowed, write to .codex/config.toml, open a crafted repository with a project MCP server and an AGENTS.md injection, and file a crafted issue against a staging repository Codex reviews. Each attempt should be both blocked and detected.
5. Detection and response review. Confirm telemetry is on and arriving; check that your alerts fire on the test activity from phase 4; run a tabletop for "the agent leaked a key" and "a cloud task pushed malicious code".
6. Report and roadmap. Record findings with their misconfiguration IDs, score each domain with the maturity model below, and write a plan that fixes them in order of risk, following the fix order.

Enterprise checklist

Use these as the evidence behind each maturity score.

Governance

• An approved policy for AI-assisted development, published and acknowledged.
• Named owners for managed requirements, MCP, plugin and skill intake, detections and incident response.
• Controls mapped to the frameworks you report against (OWASP Top 10 for Agentic Applications, NIST AI RMF, ISO/IEC 42001, SOC 2 change management).

Identity and access

• SSO with phishing-resistant MFA; allowed_login_methods and allowed_chatgpt_workspaces pinned from the local requirements file or MDM.
• Seats and workspace roles reviewed quarterly; leavers removed through SCIM.
• CI and automation use project-scoped service identities, not personal keys.

Policy enforcement

• Managed requirements.toml delivered from Agent Security, MDM or an admin-owned file, and verified on a sample of macOS, Windows and Linux devices.
• Full access excluded (allowed_permission_profiles or allowed_sandbox_modes), approvals limited to on-request, web search limited to cached.
• [permissions.filesystem] deny_read covers .env files and credential folders.
• MCP servers limited to an approved list; hooks limited with allow_managed_hooks_only; Browser Use and Computer Use pinned off where not needed.
• On Windows, C:\ProgramData\OpenAI\Codex created and locked to administrators before rollout.

Data protection

• Data retention and training settings reviewed; data classes allowed in prompts defined.
• Secret scanning with push protection on every repository; DLP on the gateway or proxy where required.

Endpoint and network

• EDR on every developer host, and inside WSL and dev containers where required.
• Corporate proxy and CA configured; an egress allowlist for model endpoints and package registries.
• A standard container or Codex cloud environment for untrusted code.

CI/CD, cloud and production

• Every Codex cloud environment inventoried, with agent internet access off or limited to named domains, and only task secrets.
• The GitHub connection limited to needed repositories; branch protection stops Codex merging; CODEOWNERS covers .codex/, AGENTS.md and workflows.
• Non-interactive jobs run in per-job containers with no deploy or publishing secrets.
• No agent has standing write access to production; a break-glass procedure is documented.

Observability and response

• OpenTelemetry export configured in managed requirements, with prompts excluded unless approved.
• Compliance and audit logs retained according to policy.
• Detections for agent activity deployed and tested, including denied reads and repeated approval requests.
• Runbooks for a leaked key, an injected agent action, a malicious MCP server or skill, and a compromised cloud task; a tabletop run in the last 12 months.

Threat intelligence and testing

• OpenAI Codex advisories and security research followed, with a regular summary for the team.
• The phase 4 tests re-run after each upgrade and policy change.
• Codex in the scope of the annual penetration test or red team.

Maturity model

Score each domain from 0 to 4 and track it quarterly.

A sensible first target for most organisations is level 2 everywhere, and level 3 for policy enforcement, isolation and CI/CD, because those three domains carry most of the critical risks.

Score it

Pick a level for each domain. The weighted score updates as you go; nothing is sent anywhere.

Weighted score: 0.0 of 4 · Unmanaged

Sources

• OpenAI Codex documentation: Configuration reference, Agent approvals and security, Permission profiles, Rules, Hooks, Managed configuration.
• Why each control matters, with incident sources: Common Codex Misconfigurations.
• Frameworks: OWASP GenAI Security Project, NIST AI RMF, ISO/IEC 42001.

The domain weights and maturity levels are AISecurityLabs.org guidance, not a standard; adjust them to your risk profile. Informational only, with no guarantee of a vulnerability-free setup, so test every configuration in your own environment. AISecurityLabs.org is independent and not affiliated with OpenAI.