封じ込めと承認設計

不十分です。Anthropicの報告によれば、Claude Codeの許可プロンプトは約93%が承認されており、承認を求める回数が増えるほど1件あたりの判断は薄くなります。人間の監督は決定論的な環境境界の代替になりません。まず既定でゼロアクセスとし、隔離された実行環境と、必要な能力だけを与える許可設計を先に敷いたうえで、人の承認は金銭・削除・外部送信・公開といった不可逆な操作に絞ります。

「機密データに触れる」「信頼できない入力にさらされる」「外部へ送信できる」の3つが同時に揃ったときです。外部から混入した指示が、機密を外へ運ぶ経路になり得ます。すべてを安全にしようとするより、この3つを同時に揃わせない設計のほうが現実的です。たとえば外部の文書を読ませる作業では、その間だけ外部送信の手段を渡さない、といった切り方をします。

「宛先のフィルタ」ではなく「能力の付与」として捉える必要があります。あるサービスへの接続を許すことは、そのサービスでできること全部——ファイルのアップロード、任意の相手への共有、既存ファイルの削除など——を許すことに等しくなります。判断は「どこへつなぐか」ではなく「何ができるようになるか」で行い、許可の単位をリソースと操作まで絞ります。

利用者の専門性に合わせます。開発者は実行される内容を読んで危険かどうか判断できるため、精査に耐える範囲で弱めの隔離も選べます。一方、業務の現場が使う場合は実行内容の精査を期待できないため、精査ではなく絶対的な境界が必要になります。また、自作の許可プロキシで代用しようとすると抜け道を塞ぎきれないことが多く、成熟した隔離の仕組みを使うのが定石です。

渡さない構成が推奨されます。資格情報は外側の仲介役に持たせ、エージェントは「仲介役に依頼する」ことしかできないようにします。仲介役がポリシーを適用し、何を読んだかを記録し、操作を仲介します。この構成なら、エージェントが乗っ取られても鍵そのものは渡っていません。逆にサンドボックスの中に鍵を置くと、隔離の強度がそのまま鍵の防御力になってしまいます。

回数を減らすことが、そのまま質を上げます。1件ずつ止めて聞くのではなく、エージェントは進めておいて、同じターンで承認待ちになった操作をまとめて判断させる方式が有効です。適用後にどう見えるかを一緒に提示できると、判断の材料が揃います。「今後も承認する」を作る場合は、作り手が自動承認可と宣言していること、かつ利用者がその種別を許可していること——2つのゲートを両方通す設計にします。