ハーネスの内側: ターン単位の権限がエージェントランタイムの基本要素になりつつある

OpenAI CodexリポジトリのあるIssueは7月中旬に出されたものですが、多くのローンチ記事よりエージェントランタイムの行き先をよく教えてくれます。報告者が気づいたのは、Codexのターン実行中に権限モードを変えても、そのターンは変更を無視することでした。開始時の権限を持ったまま動き、新しい設定が効くのは次のターンからです。途中でアクセスを広げてもエージェントはブロックされたまま。途中で狭めると、もっと厄介です。UIには制限済みと表示されるのに、エージェントは元の権限を数分間持ち続けます。

この挙動は、分かりやすい意味でのバグではありません。エージェントランタイムで静かに標準になりつつある設計判断の、目に見える端です。権限はターンにスコープされ、ターン開始時にスナップショットされ、ユーザー、マシン、セッションではなく、その作業単位の属性として扱われます。ここでは、この基本要素が何なのか、どんな脅威モデルに答えるのか、そして現時点の参照実装といえるCodexが実際にどうつないでいるのかを見ます。

要点 - ターン単位の権限とは、ランタイムがターン開始時に承認ポリシー、サンドボックスポリシー、権限プロファイルをスナップショットし、そのターン内のすべてのツール呼び出しをそのスナップショットに対して実行することです。 - 脅威モデルの中心は悪意あるユーザーではありません。敵対的な指示、つまりプロンプトインジェクションに従ったり、作業から逸脱したりする能力の高いエージェントが、あなたの認証情報を使ってあなたのマシン上で動くことです。 - Codexは境界を3つの独立した調整軸で実装します。承認ポリシー（確認するか）、サンドボックスモード（コマンドが何に触れられるか）、権限プロファイル（ファイルシステムとネットワークの細かなルール）です。強制するのはモデルではなくOSです。 - 強制層はモデルより下にあります。macOSではSeatbelt、Linuxではbubblewrapとseccomp、Windowsでは専用サンドボックスを使います。ポリシーを強制できない場合、Codexはコマンドの実行自体を拒否します。 - 未解決なのはターン途中の変更です。今はターンが終わるまでスナップショットが不変です。安全ですが、ときどきかなり腹立たしい仕様でもあります。

何が起きたのか

7月下旬から8月初旬にかけて、Codexの権限面は2つの大ざっぱな設定から、かなりポリシーエンジンらしいものへ厚くなり、ドキュメントも追いつきました。旧モデルはconfig.toml内の2つの調整軸でした。sandbox_mode（read-only、workspace-write、danger-full-access）とapproval_policy（untrusted、on-request、never）です。新しいモデルには、現在ベータの権限プロファイルが加わります。名前付きで組み合わせ可能なポリシーで、ファイルシステム規則（パスごとのread、write、deny。拒否が優先）と、ローカルプロキシを通じて強制するネットワーク規則（ドメイン許可リスト）をまとめます。ランタイムには:read-only、:workspace、:danger-full-accessの3つが組み込まれており、ゼロから作るのではなく、それを拡張します。

設定面と並行して、操作モデルもターン中心になりました。/permissionsで実行中のセッション内からモードを切り替えられます。細かな承認ポリシーでは、一部の確認カテゴリ、たとえばサンドボックス権限昇格やMCPの入力要求は対話的に残しつつ、別のカテゴリは自動拒否できます。そこには、タスク途中でエージェント自身が追加アクセスを求めるrequest_permissionsも独立したカテゴリとしてあります。さらにOpenAIの承認とセキュリティ文書によれば、承認要求を自動レビュー用エージェントへ回し、情報持ち出し、認証情報探索、破壊的操作をふるいにかけてから人へ見せることもできます。

これは一つの発表で起きたことではありません。現実にぶつかった結果、ランタイムが権限層を育てています。OSがユーザーアカウントを育てたのと似ています。喜んでというより、必要に迫られてです。

OpenAI Codexは、サンドボックスモードと承認ポリシーという2つの大ざっぱな設定から、パスごとのファイルシステム規則とプロキシ経由のネットワークドメイン規則を組み合わせる名前付き権限プロファイルへ進化しました。セッション途中の切り替え、細かな承認カテゴリ、任意の自動レビューエージェントもあります。公式の権限ドキュメントと承認ドキュメントで確認できます。

「ターン単位」とは実際にどういう意味か

私なりの一番すっきりした定義はこうです。エージェントがしてよいことの集合を、1回のターンの寿命へ結び付け、ターン開始時に確定し、原則としてターン終了時に解放できるようにする。1時間離席している間もエージェントが働くかもしれないので、ユーザー単位ではありません。リスクのまったく違う多数のターンを同じマシンで動かすので、マシン単位でもありません。午前中にコードレビューをし、昼食後に依存関係を入れるかもしれないので、セッション単位ですらありません。

冒頭のCodex Issueは、スナップショットが本当に存在する証拠です。報告者の表現では、実行中のターンは「ターン開始時に作られた権限またはサンドボックスのスナップショットを保持」します。提案されている修正は、新しい承認ポリシー、サンドボックスポリシー、権限プロファイルをアクティブなターンへ伝播する仕組みです。それができないなら、内部的に一時停止して再開し、ユーザーがもう一度プロンプトを送らなくても新しい権限でターンを再始動する案です。受け入れ条件を読むと、ターン単位の権限を第一級のランタイム概念として扱う仕様そのものに見えます。ターン途中で権限を下げたら、新しい違反操作を止めなければならない。上げたらエージェントのブロックを解除しなければならない。再開、委任、コンパクションされたターンでも更新後の文脈を維持しなければならない。

そもそも、なぜスナップショットするのでしょう。代替案のほうが悪いからです。権限が変更可能なグローバル状態なら、その状態へ影響できるものは何でも、エージェントが次に何をしてよいかを動かすレバーになります。エージェントが読むコンテンツも含みます。ターンごとに不変なスナップショットなら、権限判断は明確な意図がある瞬間に、人かポリシーによって一度だけ行われ、エージェントが実行途中に言葉で境界を越えることはできません。ターンが最小の信頼単位になります。実際のエージェント仕事の分解にも合います。「この差分をレビュー」と「mainへpush」は、同じセッションであっても同じ権限文脈を共有すべきではありません。

Codexは権限をターン開始時のスナップショットに結び付けます。2026年7月のIssueには、ターン途中でアクセスモードを変更しても実行中のターンには影響しないことが記録され、新しい承認ポリシー、サンドボックスポリシー、権限プロファイルをアクティブなターンへ伝播し、再開・委任されたターンでも新しい文脈を保つ仕組みが提案されています。

どの脅威モデルに答えるのか

ここは正確にしたいところです。「エージェントセキュリティ」は曖昧な不安を何でも入れられる言葉になりがちだからです。ターン単位の権限が想定する脅威には3つの主体がありますが、どれもパーカーを着たハッカーではありません。

見出しになる脅威はプロンプトインジェクションです。 エージェントは一日中、信頼できないコンテンツを読みます。リポジトリ、Webページ、Issueチケット、ツール出力。どれにもエージェントへ向けた指示を埋め込めます。OpenAI自身の文書は影響をかなり率直に書いています。既定のWeb検索がライブではなくキャッシュ方式なのは、インジェクションへの露出を減らすためです。またネットワークアクセスを有効にすると、注入された指示を受けたエージェントが外部から信頼できない指示を取得して従えると警告しています。ターン単位で、既定ではネットワークを切ったサンドボックスなら、インジェクションが成功してもそのターンで届く範囲を抑えられます。

静かな脅威は逸脱とやり過ぎです。 正当な仕事をしている能力の高いエージェントでも、寄り道します。何かをインストールし、依存関係を取りに行き、「ついでに」ディレクトリを片付ける。サンドボックスはエージェントに悪意がなくてもこれに答えます。だから境界はモデルの善良な判断ではなく、OSによって強制されます。macOSではSeatbelt、Linuxではbubblewrapとseccomp、Windowsではネイティブサンドボックスです。要求されたポリシーをプラットフォーム側で強制できないなら、Codexはサンドボックスなしで走らせるのではなく、コマンド実行を拒否します。希望的に開けるのではなく、安全側に閉じます。

認証情報の露出は被害を増幅します。 ドキュメントのdevcontainerガイドは明確です。コンテナ内でCodexへフルアクセスを与えると、悪意あるプロジェクトはコンテナ内の何でも外へ持ち出せます。Codexの認証情報も含みます。だから新しいプリミティブは秘密情報について具体的です。"**/*.env" = "deny"のglobパターンで、書き込み可能なワークスペースから認証情報ファイルだけを切り抜きます。.git、.codex、.agentsは書き込み可能なルート内でも読み取り専用で保護されます。ネットワークプロキシはDNSリバインディング対策として、ローカルとプライベート宛てを既定でブロックします。これはエージェント型AIアーキテクチャで扱う大きな構造と同じです。モデルが提案し、ハーネスが可否を決め、秘密情報はハーネス側が持つべきです。

Codexが文書化する脅威モデルの中心は、プロンプトインジェクション（ネットワークは既定で無効、敵対的なライブコンテンツへの露出を減らすためWeb検索はキャッシュ方式）、エージェントの逸脱（強制できないコマンドを拒否するOSサンドボックス）、認証情報露出（.env向け拒否用globパターン、読み取り専用の.gitと.codex、ローカルネットワークのブロック）です。OpenAIのセキュリティ文書で確認できます。

実装は実際にどう組み合わさるのか

自分のランタイム設計に持ち帰る価値がある実装上の細部は3つです。

同じ具体度なら拒否が書き込みに勝ち、書き込みが読み取りに勝つ。 権限プロファイルでは、まず広いアクセスを与え、そこから例外を切り抜けます。ワークスペースは書き込み可、**/*.envは拒否、.devcontainerは読み取り専用、といった形です。より具体的なパスが広い規則を上書きし、書き込み可能な親の内側でも拒否されたサブパスは拒否されたままです。広い拒否の中で狭いサブツリーを開き直すこともできます。たとえば~/Documentsは拒否し、~/Documents/codexだけ書き込み可にする。この優先順位は正しいと思います。最小権限を「全部覚えてから差し引く」ものではなく、書き込み許可に例外を足して作れるからです。

ネットワーク接続の有効化と、ネットワークの絞り込みは別スイッチです。 network.enabled = trueでコマンドはネットワークへ出られます。features.network_proxy = trueを有効にして初めて、ローカルプロキシ経由でドメイン規則が強制されます。前者だけなら、統制できている気分のまま無制限の外向き通信を渡すことになります。ドメイン規則は許可リスト優先で拒否が勝ち、localhostなども明示的に許可しない限りブロックされます。ローカルのデーモンへ自由に触れるサンドボックス化エージェントは、実質的には十分サンドボックス化されていません。

旧システムと新システムは合成されません。 プロファイルと旧sandbox_mode設定は排他的です。読み込まれたいずれかの設定にsandbox_modeがあると、プロファイルは無視されます。企業管理者は管理対象のallowed_permission_profiles許可リストで新モデルを強制でき、省略された組み込みプロファイルも拒否できます。この設計全体から運用上の教訓を一つ取るなら、こうです。「両方効く」権限システムを2つ重ねると、拒否したと思っていたものが拒否されていない事故が起きます。一つ選び、/permissionsと/statusで検証し、それから広げてください。

CLIの外でエージェントを動かすチームにも、この型は一般化できます。タスクごとに権限文脈をスナップショットし、認証情報はモデルのコンテキストではなくツール実行層に置き、モデルより下で強制し、タスク終了時にすべて失効させます。それをベンダーランタイムから得るか、自作ハーネスで持つかは自作か購入かの問題です。自分で運用するなら、セルフホスト型エージェントのトレードオフがさらに増えます。

Codexの権限プロファイルは、同じ具体度では拒否、書き込み、読み取りの順に優先し、具体的なパスによる上書きを許します。ネットワーク接続の有効化と、プロキシ経由のドメイン強制を別にし、曖昧さを避けるため旧サンドボックス設定との合成を拒否します。管理者は管理対象許可リストでプロファイルを強制できます。権限ドキュメントによるものです。

今、何をすべきか

1. 今日: 次のCodexセッションで/permissionsと/statusを実行し、「効いていると思っている設定」ではなく実際に何が有効か見てください。どこかの設定層にまだsandbox_modeがあるなら、知らないうちに権限プロファイルを外しています。どちらの仕組みを使うか決めてください。

2. 今週: :workspaceを拡張し、**/*.envを拒否し、実際に呼ぶAPIドメインだけ許可する独自プロファイルを一つ作り、network_proxyを有効にします。信頼する前にcodex debug、つまりサンドボックス用コマンドで試してください。第三者コードをレビューするなら、そのプロジェクトの設定で:read-only派生プロファイルに固定します。

3. 今月: エージェントランタイムを作っている、または既存ランタイムを包んでいるなら、ターンを権限単位にしてください。ターン開始時にスナップショット、終了時に失効、秘密情報はモデルのコンテキスト外に置き、強制失敗時は安全側へ閉じる。そしてCodex自身もまだ答え切っていない問いへの自分たちの答えを書いてください。ターン途中で権限が変わったら何をすべきか。「次のターンまで何もしない」は安全ですが、ユーザーはUIに表示された内容がその場で真実になると期待します。

FAQ

ターン単位の権限とは何ですか

エージェントのターン開始時に、ランタイムが承認ポリシー、サンドボックス境界、ファイルシステムとネットワーク規則を確定し、そのスナップショットをターン内のすべてのツール呼び出しに適用する権限モデルです。権限はユーザー、マシン、セッションではなく作業単位の属性になります。原則としてターン終了時に解放されるため、昇格したアクセスが既定で残りません。

制限されたOSユーザーとしてエージェントを動かすのと何が違いますか

OSユーザーはマシン単位で静的です。エージェントが実行するすべてのタスクが同じ包括的な権限を継承します。ターン単位なら、同じセッション内でも「このリポジトリをレビュー」は読み取り専用、「依存関係を入れてテスト」はワークスペース書き込みとドメイン許可リスト付き、と分けられます。アカウントを変える必要はありません。またアクセスを自然に失効させる場所ができます。OSユーザーだけではそこがありません。

プロンプトインジェクションでCodexの権限を変えられますか

設計上、ターンの途中では変えられません。実行中のターンは開始時に取得したスナップショットに対して動き、設定を途中で変えても伝播しません。Issue #32612に記録された挙動です。残るリスクは次のターンと、プロファイルがすでに許可している範囲です。だからネットワークアクセスは既定で無効で、機密パスは拒否または読み取り専用になります。

権限プロファイルは構築の前提にできるほど安定していますか

明示的にベータで、旧sandbox_mode設定とも合成されません。完成したAPIではなく、今後の方向として扱うべきです。現時点の安定した基準は旧モードです。チーム展開では、クライアントバージョンごとに一つのモデルを選び、/statusで挙動を確認し、プロファイル項目はしばらく動くと見込んでください。

結論

エージェント権限はUnix権限が育ったのと似た道を進んでいます。「rootか何もなし」から、細粒度、最小権限、監査可能な境界へ。ただし単位はプロセスでもユーザーでもなく、ターンです。今この設計を学ぶならCodexが最も分かりやすい実装です。そして一番粗いところ、ターン途中では変えられない不変スナップショットこそ、最も学びがあります。参照実装ですら、権限をどこまで動的にすると「権限」という意味そのものが薄れるのかをまだ調整中です。エージェントを作る、あるいは運用するなら、この基本要素の形を今のうちに理解しておくといい。1年以内に本気のランタイムならどこも持つようになり、スナップショットの意味づけを間違えたものは人前で学ぶことになるでしょう。

自分たちのエージェント向け権限層を設計していて、もう一組の目で見てほしいなら、これは私がクライアントチームと行っている仕事です。お問い合わせください。

情報源

• OpenAI Developers「Codexの権限」: https://developers.openai.com/codex/permissions （2026-08-29参照）

• OpenAI Developers「エージェントの承認とセキュリティ」: https://developers.openai.com/codex/agent-approvals-security （2026-08-29参照）

• GitHub、openai/codex Issue #32612「現在実行中のターンへアクセス制御変更を適用する」: https://github.com/openai/codex/issues/32612 （2026-07-12登録、2026-08-29参照）

• GitHub、openai/codex Issue #23626「Codex CLIの/permissionsはWSL2で「Read-only」を表示しないがWindows PowerShellでは表示する」: https://github.com/openai/codex/issues/23626 （2026-05-20登録、2026-08-29参照）

• OpenAI Codexリポジトリ: https://github.com/openai/codex （2026-08-29参照）