技術要約：コーディングエージェントにおける残留する権限（Lingering Authority）

問題定義：残留する権限

本論文は、コーディングエージェントにおける「残留する権限（lingering authority）」と呼ばれる特定のセキュリティギャップを特定している。コーディングエージェントは、特定のサブゴールに対してのみ必要とされるリソースや効果であっても、タスク全体を通じて広範なツールアクセス権を受け取ることが多い。核心となる問題は時間的なものである。あるサブゴールに対して正当化された権限が、そのサブゴールが終了した後もプランナーのインターフェース上に露出したままとなることである。もし、広範な読み取りオプションがサブゴールの終了後もプランナーに対して表示され続けているならば、モデルはそれを利用して計画を立て続ける可能性があり、これは、一時的な能力がその正当性を失った後も存続するというセキュリティ状態を生み出す。本論文は、露出したインターフェースは、実行時の到達可能性やサンドボックスの境界とは異なる、セキュリティ状態の一部であると主張している。

手法：PORTICO リファレンスモニター

著者らは、コーディングエージェントに対して有界な能力の寿命（bounded capability lifetimes）を強制するように設計されたリファレンスモニターであるPORTICOを導入している。PORTICOは、固定されたホスト隔離モデルの下で動作し、明示的なタスク契約と、型定義された信頼できるツールカタログに依存している。

コアメカニズム

PORTICOは、タスク契約を以下の4つのコンポーネントにコンパイルする：

1. 初期エンベロープ ($E_0$): タスク開始時に公開される能力の集合。
2. 付与ルール ($\Gamma$): 明示的なリクエストを通じて一時的な権限を拡張する方法を定義するルール。
3. 閉鎖ルール ($\Lambda$): 一時的な権限の取り消しをトリガーする述語（例：テスト通過、フェーズ終了、サブゴール完了）。
4. グローバル拒否ルール ($G$): 禁止されたネットワークホストや認証情報ファイルへのアクセスなどの不変条件。

リクエスト–付与–呼び出し（Request–Grant–Invoke）のライフサイクル

PORTICOは、拡張を**不透明でエポック限定のハンドル（opaque, epoch-bound handles）**として具現化する。

• リクエスト（Request）: プランナーは宣言されたルールに基づいて権限をリクエストできるが、新しい権限を自ら作成することはできない。
• 付与（Grant）: ルールが一致する場合、モニターは特定の、リソース／効果／フェーズに対するハンドルを発行する。このハンドルは、次回のプランナー・インターフェースに追加される。
• 呼び出し（Invoke）: 有効かつ生存しているハンドルが存在する場合にのみ、実行が許可される。
• 閉鎖（Closure）: 閉鎖イベント（例：信頼されたテスト結果）が発生すると、モニターはプランナー・インターフェースから対応するハンドルを削除する。その後の無効になったハンドルへの試行は、副作用が発生する前に拒否される。

決定的なのは、取り消しによって「権限」はインターフェースから削除されるが、「コンテキスト」（例：会話内のファイル名）はそのまま維持される点である。プランナーは、新たな付与がない限り、そのリソースに対するツールを選択できなくなる。

主な貢献

本論文の主な貢献は以下の3点である：

1. 「無効な使用（No-Stale-Use）」の定義: 付与された権限が終了した後は、後のプランナー・インターフェースから消失し、実行時においても無効でなければならないという要件を定義した。
2. 定式化と実装: リクエスト–付与–呼び出しプロトコルの周囲に、露出の最小化（exposure minimality）、正当化された拡張（justified expansion）、および**権限の閉鎖（authority closure）**を定式化した。これらは、エポック限定ハンドルを用いてPORTICO内で実装されている。
3. 実証的評価: 制御されたフィクスチャおよび固定された実際のレポジトリを用いて、有界な寿命の効果を検証し、非取り消し型の設計と比較して、閉鎖後の古い能力の可用性が減少することを実証した。

実験結果

評価では、3つの制御されたフィクスチャ・スイート（A–C）と1つの実際のレポジトリ・スイート（D）を使用し、PORTICOを、ベースライン（Full Access、Static Allowlist、Coarse Sandbox）および特定の比較対象（Non-Revoking、All-Visible Same-Policy）と比較している。

主な知見

• 最小化 (RQ1): PORTICOのバリアントは、Suite Aにおいてポリシー違反および「ブラスト半径（到達した機密リソース）」を 0.00 に抑えるが、Full AccessおよびStatic Allowlistは、それぞれ顕著な違反率（1.00および0.82）を示した。
• 正当化された拡張 (RQ2): PORTICO Core（初期エンベロープのみ）は安全ではあるが脆弱であり、境界拡張を必要とする多くのタスクに失敗した（Suite Bでの成功率 0.21）。PORTICO Full は、境界作業を回復し、Suite Bにおいて 0.87 の成功率を達成しながら、1.00 のスコープ遵守と 0.00 の違反を維持した。
• 閉鎖 (RQ3): これが本論文の主要な差別化要因である。Non-Revoking Comparator（同じタイミングで同じ付与を受けるが、決して削除しないもの）は、タスクの成功と閉鎖前の決定においてPORTICOと同等の結果を示す。しかし、閉鎖後の再読み取りにおいて：
  • PORTICO Full: 閉鎖後の再利用の試行を 10/10 回拒否した。
  • Non-Revoking Comparator: 閉鎖後の再利用の試行を 10/10 回許可した。
  • 残留効果の監査（Stale-Effect Audit）: ファイル書き込み、gitによる変更、ネットワークへのエグレスを含む決定論的なテストにおいて、PORTICOは禁止された効果を 0/6 回実行したが、non-revoking comparatorは 6/6 回実行した。
• インターフェースの幅 (RQ3): All-Visible Same-Policy Comparator（広範なインターフェース、同一の実行ポリシー）は、実行される禁止された効果についてはPORTICOと同等（0/20）であったが、より多くの ブロックされた提案（proposed actions） を生成した（84 vs 67）。これは、実行が最終的に拒否されるとしても、インターフェースが広いほどプランニングへの圧力が強まることを示している。
• 実際のレポジトリ (RQ4): 固定された実際のPythonレポジトリ（Flask, Requestsなど）において、PORTICO Fullは一時的な付与を正常に具現化し、閉鎖を強制し、14の契約にわたってスコープ遵守とゼロの違反を維持した。

重要性と主張

本論文は、PORTICOが権限の「寿命（lifetime）」を独立したセキュリティ変数として隔離することに成功したと主張している。重要な知見は、取り消しが実行されない場合、実行ポリシーや付与のタイミングが非取り消し型のシステムと同一であっても、閉鎖前のタスク成功とスコープ遵守を維持しつつ、閉鎖後に一時的な能力が利用可能な状態になり得るということである。

著者らは、PORTICOをサンドボックスやコンテンツ防御の代替物としてではなく、一時的な能力を明示的、有界、かつ監査可能にするための補完的なレイヤーとして位置づけている。その重要性は、取り消しが実行されない限り、残留する権限を防ぐためには、単なる実行ポリシーの制御だけでは不十分であるということを示した点にある。

本論文の範囲については、以下のように控えめに記述されている：

• 信頼できる型定義されたツールカタログおよび媒介された実行を前提としており、媒介されていないシェルコマンドやサンドボックスのバイパスに対する保護を主張するものではない。
• 契約の質がデプロイメントの入力であることを認めている。不適切な契約は、過小な付与（作業の阻害）または過剰な付与（リスクの露出）につながる可能性がある。
• ユーティリティのコストについても言及している。PORTICO Fullは、厳格なスコープ制御のために、生の完了率を一部犠牲にしており、隠れた過剰な成功ではなく、目に見える「安全な不完全性（safe incompleteness）」をもたらす。

結局のところ、本研究は、コーディングエージェントにとって、プランナー・インターフェース自体が動的であるべきであると主張している。すなわち、正当性が失われるにつれて縮小していくインターフェースであるべきであり、静的で広範な、許容されるツールのメニューであり続けるべきではない。