エージェントハーネスはサンドボックスの外に出すべき理由

エージェントハーネス（実行環境）をサンドボックス内に閉じ込めてはいけません。セキュリティと運用の観点から、サンドボックスの外側に配置するのが正解です。

確かに、実験的でエージェントが生成したコードはサンドボックスでテストすべきだね。コード実行がうまくいかなかったときに、その影響を閉じ込めるために。でも、エージェントがツールを呼び出すときのためのサンドボックスも必要じゃない？そうしないとツール実行が失敗したときのリスクを抑えられないから。それに、エージェントのハーネス（制御プログラム）自体にも、第3のサンドボックスを用意するか、実装すべきだ。エージェントが不適切なリクエストを作成した際のリスクを抑えるために、ツールリクエストを制限するファイアウォール層も必要だよ。あと、エージェントに認証情報を持たせるのもNGだね。LLMに漏れて、他の隠れたチャネル経由で流出させられるリスクがあるから。

そのアーキテクチャを推す明確な根拠が示されていないし、正直あまり納得できていないな。exe.devだと、エージェント（Shelley）はLinux VM上で動いていて、そこがセキュリティ境界になってる。会話ログは全部sqliteに保存されるから、過去のやり取りを参照することもできる。sudoも使えるから、AIにちょっとしたシステム管理のタスクを投げるのも便利だよね。難点は、VM内でインジェクション攻撃を受けるとシークレット情報が流出しかねないこと。でも、ローカルにシークレットを置かずにHTTPプロキシサーバーへ流すような「インテグレーション」もあるしね。それに、そもそもAIを使わずにVMを普通のVMとして使うって選択肢もある。

新しい技術が出るたびに、みんなが必死になって標準を定義したり自分たちのものにしようと競い合うのを見るのは面白いよね。Manusは6ヶ月でハーネスを5回も作り直してる。モデルは同じなのに、アーキテクチャは5回も変更された。LangChainだってDeep Researchの設計を1年で4回もやり直してる。AnthropicもClaude Codeのハーネスをモデルが進化するたびに作り変えてきたし。Mitchell Hashimotoが2月に「ハーネス」という言葉を使って以来、みんながその概念の主導権を握ろうとしてる。そのうち誰かが『ハーネスエンジニアリング』なんて本を出すんだろうね。もちろん買うよ。で、それを読んだ感想をブログに書くんだ。でも誰にも読まれず、HNに投稿した瞬間に「ShowDead」行きになるのがオチだろうけど。その頃にはIT企業がこんなこと言い出すはずさ。「君、新卒だよね？ハーネスエンジニアリングはできるよね？」って。

この記事は、僕がハーネスをサンドボックスで動かしたい本当の理由を逃してる気がする。今の時点では、ハーネスそのものすらLLMと同じくらい信用できていないんだ。ハーネスは基盤モデルと一緒に急速に進化してるから、安全性という制約を任せるにはまだ無理がある。もっと正確に言うと、もしハーネスに「LLMにはできないこと」をさせる機能があって、その機能をLLMが呼び出せる条件が揃っているなら、LLMはいずれその条件を学習して悪用してくるものと考えなきゃいけない。つまり、危険な三位一体が完成しちゃってるわけで、そうじゃないと振る舞うのは危険なだけだ。とはいえ、サンドボックスの外側にいなきゃいけないコンポーネントがあるのも事実（じゃないと、誰がサンドボックスを作るの？）。長期的には、ハーネスの一部ではなく、独立したセキュリティ層が必要だと思う。これはまだ発展途上だけど、ハイパーバイザーみたいに外側にいて、コンテキストやユーザー権限に基づいてアクセスを許可し、人間による判断が必要なときは介入できるような仕組みが必要だろうね。

2つポイントがある。

• エージェントが、どのコンテキストで、どのリソースに、どれくらいの期間アクセスすべきか、という問題が未解決のまま。
• 人間が書くコードより遥かに速く動く「確率論的コード」に対して、私たちはまだ優れたモデルを持っていない。ここに注力すべきだよ。

ファイルシステムのリソースに制限をかけるのは、ファイアウォールや許可/拒否リストの背後にエージェントを置くのと何ら変わらない。だからといって、セキュリティ向上のためにサンドボックスの中にサンドボックスを入れるというアプローチが無意味なわけじゃない。

エージェントのタスクの多くはサンドボックスを必要としない：思考、API呼び出し、要約、CI待ちなど。

いや、理解できないな。API呼び出しはほとんどの場合サンドボックスが必要だよ。他のタスクだって、APIにアクセスできるサンドボックス化されていないエージェントに悪用される可能性がある。ハーネスがサンドボックスの外にあるなら、セキュリティモデルとしても境界としても曖昧で混乱を招くだけだよ。

3人のエンジニアが同じインシデントでエージェントを動かすと、セッションが終わるまで古い状態を見続けることになる。競合解消、結果整合性、キャッシュ無効化の問題だ。

それはバグじゃなくて仕様と言えるんじゃないかな。競合解消が必要になることで、共通の正解（ソース・オブ・トゥルース）に同意するためのプロセスが必要になるわけで、ほとんどのGitリポジトリがmainブランチへの直接プッシュを禁止しているのと同じ理由だよ。ユーザー数が増えたときに、共有メモリデータベースへ直接書き込むようなやり方をしたら、カオスと無数の副作用が生まれるだけだと思う。

別のモデルもあるはずだよ。サンドボックスなんてやめて、エージェントにコンピュータをまるごと与えて、ただしそのコンピュータを機密リソースからは隔離しておくっていう方法。トークンの問題は解決済みだし、トークナイズ[1]したりプロキシを通したりすればいい。シークレットも同じだね。この記事の主張の多くは、偽の二分法に基づいている。「サンドボックスは一時的であるべき」という前提があるけど、なぜ？そうする理由も、そうしない理由もそれぞれあるはず。ネットワークIDと完全な接続性を持った「永続的なコンピュータ」を持たせつつ、使わないときはシャットダウンして課金を止めることだってできる。これらの問題を解決する方法は山ほどあるのに、みんなが現状に執着して視野が狭くなっているようで落ち着かないよ。それだと、せっかくの有益な選択肢を見逃してしまう。

aluzzardiさん、記事のシェアをありがとう！読み込み専用メモリと専用の読み込みインターフェースについての指摘はすごく興味深かった。ハーネス設計における成功率の大きな要因になり得るね。どうやってその結論に至ったの？評価のプロセスや、その判断を検証するために収集したデータやエピソードがあれば教えてほしい。あと、質問の切り口自体も気になっているんだけど、エージェントに「場所（where）」は必要なのかな？エージェントを「状態」と「遷移」の集合としてモデル化することもできるはず。「現状の『1プロセス・1クロード』的なハーネス」は単に便利だから使われているだけで、必然性はないんじゃないかと思う。関数とテーブルに基づいた「完全分散型ハーネス」がもっと広まらないのはなぜだろう？

ツールや命令を定義するWasmモジュールを開発者が作って、ハーネスがそれをロードする仕組みを考えたことがある。MCPに似てるけど、サンドボックス環境の保証がついているようなやつ。そういう動作をパッケージマネージャーみたいに管理できればいいなと思ったんだ。今でも悪くないアイデアだと思うけど、MCPと競合する割にはデメリットもあって、普及させるのはMCPより難しいかな。ユーザーがセキュリティを気にしないなら、セキュアなサンドボックスという機能面で勝負するのは難しいからね。