CodexのWindowsサンドボックスから学ぶ、AIエージェントに渡す権限設計

OpenAIがCodexをWindows上で動かすために作ったサンドボックスの記事を読んだ。
ざっくり言うと、AIコーディングエージェントが安全に動くよう、ファイルアクセスとネットワークを厳しく制限した実行環境を一から設計した話だ。
読み終わって最初に思ったのは「これ、自分がLLMにツール渡すときと同じ問題だな」ということだった。

OpenAIの設計で特徴的なのは、ネットワークアクセスをデフォルトでブロックしている点だ。
Codexが動く環境では、許可リストに入っていないエンドポイントへの通信は基本的に遮断される。
さらにファイルシステムも「書き込み可能な領域」を明示的に区切っていて、エージェントが勝手にシステムファイルを触れない構造になっている。

LLMにツールを渡すときの「権限の粒度」問題

自分も最近、社内の小さなエージェントをLangChainで組んでいる。
そのとき悩んだのが、ツールにどこまでの権限を持たせるかだった。
ファイル読み書きのツールを渡したとき、最初は「まあ読むだけだし」と思って広めのパスを渡してしまった。
でも実際にエージェントが動くと、意図しないディレクトリを走査しようとする動きが出てきて焦った。

OpenAIがやったことは、その「権限の粒度」を実装レベルで強制する仕組みを作ることだ。
自分のように「まあ大丈夫だろう」でゆるく渡すのではなく、アクセス可能なパスを明示的に列挙する設計にしている。
これ、エージェントが複雑になるほど絶対に必要になる考え方だと思った。

自分のエージェント実装に引きつけると

今の自分のコードを振り返ると、ツール定義がかなり甘い。
例えばファイル操作ツールは、パスのバリデーションがほぼない状態で動いている。

# 今の自分のコード（これが問題）
def read_file(path: str) -> str:
    with open(path, "r") as f:
        return f.read()

OpenAIの設計思想を参考にするなら、少なくともallowed_pathsのリストを持って、そこ以外のアクセスはエラーを返す構造にすべきだ。
ネットワーク系のツールも同様で、叩けるエンドポイントをホワイトリスト管理するのが正しい方向だと思う。

CodexのサンドボックスはWindowsのセキュリティ機能を活用しているが、自分がLambdaやCloud Runでエージェントを動かすときも発想は一緒だ。
IAMロールで最小権限、VPCで通信先を絞る。
これをサボると、LLMが予期しない動きをしたときに影響範囲が読めなくなる。

エージェントの話をすると「精度が大事」みたいな話になりがちだけど、実は権限設計のほうが先に考えるべきことだと思う。
どんなに賢いモデルでも、触れる範囲を絞らないと本番には出せない。
OpenAIがCodexのために一から専用サンドボックスを作ったのは、そこを本気でやらないとエージェントは使い物にならないという判断だろう。

自分は来週、社内エージェントのツール定義を見直してallowed_pathsの仕組みを入れてみるつもりだ。
どこまで権限を絞れるか、実際に試しながら確認していく。