AIエージェントの権限を作り直した話

5体のAIエージェントを動かしている。全体を管理する者、相談を受ける者、設計し制作する者、文章を書く者、外部サービスと接続する者。役割を分ければ責任も分かれる。責任が分かれれば権限も細くできる。そう考えるのは自然だし、実際そのために権限プロファイルを割り当てていた。

ところが設定を見直したとき、形だけの檻が見えた。シェル実行を禁じたはずの役がコマンドを打てる。作業フォルダの内側しか触れないはずの役が、外のディレクトリへ手を伸ばせる。最小権限という言葉が、紙の上だけで痩せていた。嫌な音がする。安全設計は破れた瞬間より、破れていないふりをしている時間のほうが怖い。

原因はエージェントの性格ではない。モデルの賢さでも悪意でもない。もっと退屈で、もっと厄介な層にあった。エージェントを動かすハーネスが、OpenClaw側の権限設定の外側にネイティブのシェルを持っていたのだ。権限ポリシーが届く前から、実行の刃物が手元に置かれていた。

OpenClawはモデルごとにハーネスを選ぶ。そこで認証方式が効いてくる。OpenAI系モデルをCodex認証で使うと、エージェントはOpenClaw本来のハーネスではなくCodexのハーネスで動く。そしてそのハーネスにはネイティブのシェルがある。誰も「許可する」と言っていないのに、経路の選択だけでコマンド実行が可能になる。権限設計でいちばん醜いのは、許可の文言がないまま許可が成立している状態だ。

最初の対処は単純だった。各エージェントのハーネスを、権限が実際に効くOpenClaw本来のものへ明示的に乗せ替える。そうすればシェルは管理下の実行ツールになり、禁止も許可も設定どおりに通る。面白いのは、そこへ辿り着くための道がGUIには見えなかったことだ。説明もない。ソースを読むしかない。実にOpenClawらしい。褒めてはいないが、嫌いでもない。

だがシェルを奪えば、それまで動いていた処理が止まる。ネットへの自動投稿、成果物のプレビュー、カレンダーや表計算の読み取り、広告レポートの生成。どれも内部でシェルに触れていた。だから機能からシェルを剥がした。処理をMCP化し、エージェントには決まった引数のツールだけを渡す。厨房へ入らせるのではなく、メニューを注文させる。料理は出る。包丁と火には触れない。ここでようやく、便利さが少しだけ礼儀を覚えた。

それでも問題は残った。シェルを持たないエージェントは、自分の作業フォルダの一覧すら取れない。安全のために刃物を取り上げたら、紙を切ることもできなくなった。こういう安全は正しいが、長くは続かない。人間が面倒になって穴を開けるからだ。制度は現実に負ける。だから現実のほうを小さくした。

エージェントをサンドボックス化し、自分の作業フォルダだけが見える箱の中へ入れる。その箱の中ではネイティブのシェルを自由に使える。ファイルを並べ、生成物を作り、足元を確認できる。だが箱の外、ホスト側の設定や秘密には届かない。存在しないものとして返る。これは美しい。世界を禁止で埋めるのではなく、見える世界の大きさを調整する。ただし投稿やメッセージ送信のような外向きの行動は箱の外へ影響する。そこだけは窓を細く保つ。箱の中は自由、箱の外へは最小権限。ようやく言葉が締まった。