OpenAI は 2026 年 5 月 8 日、自社で開発・運用するコーディング用 AI エージェント「Codex」を社内で安全に動かすための仕組みを公式ブログで公開しました[1]。技術的境界を作るサンドボックスと、リスクが高い動作で必ず人間に確認させる承認ポリシーを 2 層で組み合わせ、エンタープライズ ChatGPT に紐づけた認証と OpenTelemetry ベースのログ収集を加えることで、開発者の生産性を保ちつつ管理性を担保したと説明しています。

サンドボックスと承認ポリシー、2 層で境界を作る

Codex のセキュリティは、技術的に「何ができるか」を制限する サンドボックスモード と、実行直前に「どの操作で必ず人間へ確認を取るか」を決める 承認ポリシー の 2 層で構成されています[1][2]。サンドボックス側は OS レベルの隔離機構を使い、macOS では Apple 標準の Seatbelt(sandbox-exec)、Linux(および Windows 上の WSL2)では bubblewrap を使ってファイルシステムやネットワークへの到達範囲を絞ります[3]。

ローカル実行時の標準は workspace-write モードで、ファイル読み書きをカレントの作業ディレクトリ内に閉じ込め、外部ディレクトリへの書き込みやネットワーク利用が必要になった時点で承認プロンプトを表示します[2][3]。読むだけの計画フェーズに切り替える read-only モードや、保護を意図的に外す danger-full-access モードも用意されており、用途に応じて許容するリスクを段階的に切り替えられる構成です[3]。

承認ポリシー側には untrusted のような厳格な設定も存在し、Git の破壊的操作や設定上書き(--config 系)など状態を変える可能性があるコマンドは必ず人間の判断を挟む扱いになります[2]。OpenAI は「低リスクの日常的な操作は摩擦なく進め、高リスクの操作は明示的に止める」というバランスを設計方針として挙げています[1]。

ネットワーク既定オフ、クラウド版は許可ドメインで運用

ネットワーク利用にも踏み込んだ制御が入っています。OpenAI のマネージド構成では、ローカル Codex のネットワークアクセスが 既定でオフ に設定されており、許可済みの宛先だけ通し、未知のドメインは承認待ちにする運用です[1]。意図しない外部送信や、LLM が指示に巻き込まれて勝手に外部 API を呼び出してしまうケースを抑える狙いがあります。

クラウド実行環境「Codex cloud」は HTTP/HTTPS プロキシ経由で動作し、ドメイン名やワイルドカードを使った allow/deny ルールを管理者が宣言的に設定できます[4]。ビルドや依存ダウンロードでよく使われるドメインを集めたプリセット allowlist も用意され、DNS リバインディングを念頭に TTL を意識したリフレッシュや DNS-aware ファイアウォールの併用が推奨されています[4]。

OpenAI はクラウド版エージェントについて、実行時に既定でインターネットアクセスを持たないことで、プロンプトインジェクションのような攻撃面を縮小できると説明しています[4]。エージェントが意図せず外部に依存する経路を絞り込み、コードを書かせる際のサプライチェーンリスクを減らす設計です。

認証はワークスペース固定、SIEM 連携で監査ログを集約

認証まわりは ChatGPT エンタープライズ向けの統合が前提です。Codex CLI と MCP の OAuth 資格情報は OS 標準のキーリング(macOS は Keychain、Linux はディストリビューション依存)に格納され、ログインは ChatGPT 経由に固定、アクセスは特定の ChatGPT エンタープライズ ワークスペースに紐づけられます[1][2]。設定したワークスペース ID と現在の認証情報が一致しない場合、Codex は自動でログアウトして終了する挙動になっています[2]。

監査側では OpenTelemetry ログのエクスポート が用意され、ユーザープロンプト、ツール承認の可否、ツール実行結果、MCP サーバーの利用状況、ネットワークプロキシの allow/deny 判定などエージェントの主要イベントを otlp-http または otlp-grpc で外部の SIEM やコンプライアンス基盤に送れます[2]。既定では無効で、組織側が必要なログ範囲を選んでオプトインする形です。

エンタープライズ運用面では、Codex の管理権限を絞った「Codex Admin」グループを別建てで作る、SSO 利用時は MFA を強制する、ワークスペース設定の Settings and Permissions から RBAC で利用範囲を絞る、といった推奨事項が整理されています[5]。Codex local は新規ワークスペースで既定有効、Codex cloud はオプトインという初期値で、組織側が段階的にロールアウトを進めやすい構成です[5]。

まとめ

OpenAI が公開した今回のドキュメントは、社内で先行して回している Codex 運用ノウハウを、企業の AI エージェント導入の参考フレームとして外に出したかたちです。サンドボックスと承認ポリシーで技術的な境界を作り、ネットワークと認証で外部依存と権限を絞り、最後に OpenTelemetry でログの可観測性を確保するという流れは、既存のソフトウェアサプライチェーン管理の延長で読み解けます。エージェント型 AI を本格導入する企業にとって、最低限の守備位置を確認するためのチェックリストとして実用的です。

出典:https://openai.com/index/running-codex-safely/

出典:https://developers.openai.com/codex/agent-approvals-security

出典:https://developers.openai.com/codex/concepts/sandboxing

出典:https://developers.openai.com/codex/cloud/internet-access

出典:https://developers.openai.com/codex/enterprise/admin-setup