Security and Access Auditing

Lesson rewritten November 3, 2026 based on the Agent approvals & security, Rules, Compliance API and audit events pages, and the Codex manual. The previous version described a non-existent .codexignore file, claimed Codex only runs commands listed in AGENTS.md, cited an “Organization Settings → Audit Logs” menu, and mentioned a Codex SOC 2 Type II certification without a source. Sources: Agent approvals & security · Rules · Compliance API · Pricing.

Controlling What Codex Can See and Do

Security becomes critical the moment an AI agent accesses your source code. Codex includes built-in safeguards, but configuring them is your responsibility: the product provides isolation, while you define the perimeter. If you connect a repository for convenience during a late-night rush or leave a secret in a forgotten config file, technical isolation won’t protect you.

The Codex Security Model

Two complementary settings govern what the agent can do: the sandbox, which defines what it can technically touch, and the approval policy, which determines when it must stop and ask for permission—such as when leaving the sandbox, using the network, or running a command outside the allowed set.

• Locally (CLI, extension, desktop app), OS-level mechanisms enforce the sandbox. By default, there is no network access, and write operations are limited to the active workspace. With the common preset --sandbox workspace-write --ask-for-approval on-request, Codex reads, modifies, and executes freely within the working directory but asks before writing elsewhere or using the network. The read-only mode (via the /permissions command) lets you discuss and plan without making changes.
• In the cloud, each Codex Cloud task runs in its own workspace within an OpenAI-managed environment; credentials and network access are configured per environment, with network secrets limited to authorized HTTPS services.

Contrary to what the previous version of this lesson claimed, Codex is not restricted to commands listed in AGENTS.md: it can run commands, bounded by the sandbox/approval pair. To go further, rules govern allowed commands outside the sandbox: a prefix rule can require confirmation or forbid a command entirely.

# .rules file (Starlark syntax)
prefix_rule(
    pattern = ["curl"],
    decision = "prompt",
    justification = "All outgoing network requests must be confirmed.",
)

Enforced by the administrator, these rules can only require confirmation or forbid actions; they cannot grant automatic authorization.

Hiding What Shouldn’t Be Read

There is no .codexignore file. To prevent Codex from reading sensitive files, even if versioned, use a permissions profile with deny rules on exact paths or patterns:

# ~/.codex/config.toml
[permissions.project-edit.filesystem]
glob_scan_max_depth = 3

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

Placed under :workspace_roots, the rule applies to every workspace root: .env files become unreadable there, without blocking normal writes elsewhere. Exact paths work well for stable locations like ~/.ssh; patterns suit files with variable locations. An administrator can enforce these denials across the entire organization (permissions.filesystem.deny_read).

Documentation notes two limitations. On Linux, WSL, and Windows, pattern matches are resolved at the start of each sandbox process: a matching file created afterward remains readable to an already-running process. Also, an unbounded ** pattern requires glob_scan_max_depth. The safest approach remains keeping secrets out of the repository entirely.

Apply the same caution to AGENTS.md, which Codex reads on every run. Never place real secrets there: dummy values suffice to explain the format expected by your test commands.

## Environment Variables
Test commands use dummy variables:
- DATABASE_URL=postgresql://test:test@localhost:5432/test_db
- AUTH_SECRET=test-secret-for-development-only

Tracing and Monitoring

In Enterprise and Edu plans, audit logs and usage tracking go through the Compliance API. It supports security, legal, and investigative uses that require verifiable records: exporting events to a SIEM or data lake, applying your retention periods and legal holds, and correlating Codex activity with your identity data. The Admin API documentation governs covered events, filters, and retention; test ingestion on a non-production system before scheduling continuous collection.

This is not a productivity dashboard: OpenAI advises against using it to judge code quality or individual performance, referring instead to workspace insights and the Analytics API for adoption metrics. Someone must actually use these logs beyond post-incident reviews: keep them outside the agent-controlled environment, and alert on repeated authentication failures, unusual access, and configuration changes.

Compliance and Regulation

If your code handles European personal data, four points fall under your responsibility, not the vendor’s. Ensure your OpenAI contract includes a DPA (Data Processing Agreement); use data retention and residency controls when your plan offers them (Enterprise and Edu); document Codex usage in your record of processing activities; and finally, inform teams that their code is processed by a third-party service. In the Business plan, company data is not used for training by default.

For a SOC 2 or ISO 27001 audit, rely on documents published by OpenAI—including the Codex Security Whitepaper on its trust portal—and verify the scope and date of each attestation: an expired attestation, or one that doesn’t cover the service you use, holds no weight with an auditor. Compliance API exports meet traceability requirements, provided they are collected continuously and produced when requested.

Security Best Practices

Account sharing, the last item in the right column, deserves special mention: it instantly nullifies the entire value of audit logs, since no action can be tied to an identifiable person.

Key Takeaways

• The sandbox bounds what Codex can touch (locally: no network, writes limited to workspace by default); the approval policy sets when it asks
• Rules govern commands outside the sandbox (prompt or forbidden)
• .codexignore does not exist: forbid reading sensitive files via deny rules in a permissions profile
• Audit logs go through the Compliance API (Enterprise and Edu)
• Verify GDPR compliance if handling European data
• Never put real secrets in AGENTS.md