{
  "issue": "2026-09-19",
  "generated_at": "2026-09-19T07:00:00+09:00",
  "theme": {
    "title": "エージェントの権限設計は「毎回確認」から「境界を先に固定する」へ移った",
    "category": "agent-security",
    "lede": "エージェントがファイル操作やコマンド実行を任される場面が増えるほど、行為ごとに確認を求めるダイアログは形骸化する。ユーザーは10回目の確認では中身を読まずに許可を押すようになり、承認は安全装置ではなく儀式になる。この『承認疲れ』への対処として、2026年に入り複数のベンダーが同じ結論にたどり着いた——確認の頻度を運用で調整するのではなく、ファイルシステムとネットワークの到達範囲を実行前に構造的に固定し、その範囲内では確認を求めない設計への転換だ。ただし境界が及ぶ範囲はツールごとに異なり、抜け穴も残る。",
    "tldr": [
      "OpenAI CodexとAnthropicのClaude Codeは、サンドボックスの制限強度と確認ダイアログの要否を別軸にし、境界内の行為は原則自動承認する設計にそろえた。",
      "CursorとGitHub Copilot coding agentは、ネットワーク到達範囲をsandbox.jsonや組織設定で宣言的に固定し、SSRF対策のプライベートアドレス遮断をデフォルト装備した。",
      "いずれのサンドボックスもBash・ターミナル経由の子プロセスしか保護せずMCPサーバー通信は対象外——Microsoftはこの抜け穴を埋めるネットワーク層のMCP Firewallを別立てで投入した。"
    ],
    "sections": [
      {
        "heading": "「毎回確認」の限界 — 境界の強さと確認頻度を分離する",
        "body_html": "<p>エージェントに任せる操作が増えるほど、行為のたびに『実行していいですか』と確認を求めるUIは機能しなくなる。最初の数回は内容を読んで判断できても、10回、20回と続くうちに承認は反射的なクリックに変わり、本当に危険な操作が紛れ込んでも気づけなくなる。これは個々のプロンプト設計の問題ではなく、確認頻度をサンドボックスの緩さで決めている限り避けられない構造的な限界だ。</p><p>OpenAI CodexとAnthropicのClaude Codeは、この2つを分離する設計にそろえた。Codexは<code>read-only</code>/<code>workspace-write</code>/<code>danger-full-access</code>のサンドボックス段階と、<code>untrusted</code>/<code>on-request</code>/<code>never</code>の承認ポリシーを独立した軸として組み合わせる。Claude Codeもサンドボックス自体が課すファイルシステム・ネットワーク制限を2つのモードで共通にした上で、自動承認するか確認を挟むかだけを切り替える。境界の強さと確認の頻度を別々のノブにしたことで、境界内の行為はまとめて自動承認しても安全性は落ちない。</p>",
        "examples": [
          {
            "product": "OpenAI Codex",
            "approach": "サンドボックス段階と承認ポリシーを独立変数にし、境界内の操作はauto-reviewモードで自動承認する",
            "detail": "3段階サンドボックス×3段階承認ポリシーの組み合わせにより、危険度の高い操作だけを確認対象に絞り込める設計",
            "source_url": "https://developers.openai.com/codex/agent-approvals-security"
          },
          {
            "product": "Claude Code（Anthropic）",
            "approach": "2つのサンドボックスモードで同一のファイルシステム/ネットワーク制限を強制し、自動承認か確認要求かのみを切り替える",
            "detail": "制限の強さを揺らさずに確認頻度だけを調整できるため、緩い設定にするほど危険になるトレードオフを避けられる",
            "source_url": "https://code.claude.com/docs/en/sandboxing"
          }
        ],
        "takeaway": "自作のエージェントに承認フローを組むなら、『確認するかどうか』と『何ができる範囲か』を同じ設定値で決めないこと。境界を先に固定し、その内側は自動化する方が、確認疲れによる誤許可を構造的に防げる。"
      },
      {
        "heading": "境界を宣言的に固定する — ネットワーク許可リストの標準化",
        "body_html": "<p>ファイルシステムの制限だけでなく、到達可能なネットワーク範囲を実行前に宣言しておく動きも標準化しつつある。エージェントが外部と通信できる範囲を都度の確認任せにせず、設定ファイルや組織ポリシーとして固定しておけば、確認ダイアログを増やさなくても攻撃対象を絞り込める。</p><p>Cursorはサンドボックスのネットワークアクセスを<code>sandbox.json</code>で3段階（許可リストのみ/許可リスト+既定値/全許可）に分け、<code>169.254.169.254</code>のようなクラウドメタデータエンドポイントやRFC1918プライベートアドレスをデフォルトで遮断してSSRFを防ぐ。GitHub Copilot coding agentも同様に、組織管理者がfirewallの有効/無効/リポジトリ委任を一元設定でき、OSパッケージリポジトリやコンテナレジストリなどの推奨許可リストをリポジトリ横断で強制できる。個別の確認ではなく境界そのものを組織のポリシーとして先に決める点で、両社は同じ方向を向いている。</p>",
        "examples": [
          {
            "product": "Cursor",
            "approach": "sandbox.jsonでネットワークアクセスを3段階に分け、プライベートアドレスとクラウドメタデータエンドポイントをデフォルト遮断する",
            "detail": "SSRF対策をサンドボックスの既定動作に組み込み、許可リストの設定漏れがあっても内部ネットワークへの到達を防ぐ",
            "source_url": "https://cursor.com/blog/agent-sandboxing"
          },
          {
            "product": "GitHub Copilot coding agent",
            "approach": "組織管理者がfirewallの有効/無効/委任をEnabled・Disabled・Let repositories decideの3択で一元設定し、推奨許可リストをリポジトリ横断で強制できる",
            "detail": "個々のリポジトリ設定に依存せず、組織ポリシーとして境界を先に決める設計",
            "source_url": "https://docs.github.com/en/copilot/how-tos/use-copilot-agents/coding-agent/customize-the-agent-firewall"
          }
        ],
        "takeaway": "ネットワーク境界は個々のエージェント実行時の設定ではなく、リポジトリや組織単位で宣言的に管理する前提で設計するのが安全。後からallowlistを足す運用にすると、抜け漏れの検出が属人的になる。"
      },
      {
        "heading": "境界の抜け穴 — サンドボックスが及ばないMCP経路",
        "body_html": "<p>こうしたサンドボックスの多くは、エージェントのBash・ターミナルツールとその子プロセスだけを対象にしている。だが実際のエージェントはMCP（Model Context Protocol）サーバー経由で外部サービスに接続する場面が増えており、この経路はBashサンドボックスの外側にある。ファイルシステムやネットワークの境界をどれだけ厳しく固定しても、MCP接続自体が別経路で外部と通信していれば境界は素通りされる。</p><p>Claude Codeの公式ドキュメントも、サンドボックスが保護するのはBash・PowerShell・Monitorとその子プロセスに限られることを明記しており、MCPサーバー通信はスコープ外だと認めている。この抜け穴に対しMicrosoftは、エージェント側のサンドボックスを強化するのではなく、ネットワークのエッジ側でMCPトラフィックを検査・許可判定する専用ファイアウォールを別レイヤーとして投入した。サンドボックス設計が『ツールごとの境界』の集合である以上、抜けているツールをどう塞ぐかは各社まだ足並みが揃っていない。</p>",
        "examples": [
          {
            "product": "Claude Code（Anthropic）",
            "approach": "サンドボックスの保護範囲をBash・PowerShell・Monitorとその子プロセスに限定し、MCPサーバー通信はスコープ外と公式に明記する",
            "detail": "境界がツール単位でしか及ばないことを示す一次情報",
            "source_url": "https://code.claude.com/docs/en/sandboxing"
          },
          {
            "product": "Microsoft Entra Agent ID（MCP Firewall）",
            "approach": "MCPクライアント/サーバーを改変せずに、ネットワークのエッジでMCPトラフィックを検査しAllow/Blockを強制する専用ファイアウォールをプレビュー投入した",
            "detail": "エージェント側のサンドボックスでは塞げない経路を、ネットワーク層の別コントロールで補う設計",
            "source_url": "https://techcommunity.microsoft.com/blog/microsoft-entra-blog/microsoft-entra-what%E2%80%99s-new-in-secure-access-on-the-ai-frontier/4468732"
          }
        ],
        "takeaway": "MCPサーバーを組み込む場合、ホストアプリのサンドボックスがその通信も守ってくれると仮定しないこと。MCP接続用に独立したネットワークポリシー（プロキシ/ファイアウォール）を別途用意する前提で設計する。"
      }
    ]
  },
  "editorial": "3社が『承認疲れ』への答えとして境界の事前固定にそろったのは、UXの問題を権限モデルの問題として解き直した結果だ。ただし境界の粒度はまだツール単位でバラバラで、MCPのような新しい実行経路が増えるたびに抜け穴も増える。境界設計は一度作って終わりではなく、エージェントが使うツールが増えるたびに棚卸しする運用が要る。",
  "quick_picks": [
    {
      "title": "Cursor sandbox.json Reference",
      "summary": "sandbox.jsonの設定項目とネットワークアクセス3段階の詳細仕様をまとめた公式リファレンス。本文のCursorのSSRF対策設定の一次情報。",
      "url": "https://cursor.com/docs/reference/sandbox"
    },
    {
      "title": "Running Codex safely at OpenAI",
      "summary": "OpenAIがCodexの実行環境設計の背景を解説する公式記事。本文のサンドボックス×承認ポリシー分離という設計思想を補足する。",
      "url": "https://openai.com/index/running-codex-safely/"
    },
    {
      "title": "GitHub Copilot allowlist reference",
      "summary": "推奨allowlistが許可する具体的なホスト一覧をまとめた公式リファレンス。本文の組織単位でのネットワーク境界固定の対象範囲を補足する。",
      "url": "https://docs.github.com/en/copilot/reference/copilot-allowlist-reference"
    }
  ]
}