FRELY / BLOG
AI がコンピューター上でコマンドを実行するとき、サンドボックスランタイムは何をするのか
AI にコンピューター上でシェルコマンドを実行させるのは便利です。依存パッケージのインストール、テストの実行、ログの読み取り、ビルドの修復などができます。しかし同時に、あなたが書いていないプログラムが、あなたが確認していないテキストに動かされながら、あなたのユーザーアカウントで動くということでもあります。
デフォルトでは、そのアカウントは SSH キー、クラウドの認証情報、パッケージレジストリのトークン、ブラウザのプロファイルを読み取れます。コマンドは、悪意がなくても損害を引き起こせます。Web ページや issue のコメントに潜むプロンプトインジェクションひとつで、一見まったく普通のコマンドにシークレットを読ませてどこかへ送信させることが十分にあり得ます。
すべてのコマンドの前に「よろしいですか?」と尋ねるやり方は、この問題を解決しません。人は自分が完全には読み解けないものを承認してしまうものです。より良い答えは、危険なことをデフォルトでは不可能にしておき、本当に必要なときにだけ人が狭い扉を開けられるようにすることです。サンドボックスはそのためにあるのです。
srt とは
srt は Anthropic のオープンソースのサンドボックスランタイム(@anthropic-ai/sandbox-runtime)です。Claude Code 向けに作られたもので、コマンドラインツールとしてもライブラリとしても使えます。任意のプロセスと、そのプロセスが起動するすべてのものを、OS が強制するファイルとネットワークの制限で包み込みます。コンテナイメージも仮想マシンも使いません。
プロジェクト自身の README はこれをベータ版のリサーチプレビューと位置づけているため、完成した保証としてではなく、強力な構成要素として扱ってください。
ファイルをどう制限するか
ファイルに関するルールは、シンプルに言えます:
- 読み取りはデフォルトでどこでも許可されています。 隠したい場所を
denyReadで列挙します。たとえば認証情報のフォルダなどです。 - 書き込みはデフォルトでどこでも拒否されています。 コマンドが書き込める場所を
allowWriteで列挙します。通常はプロジェクトフォルダと一時ディレクトリです。denyWriteはallowWriteよりも優先されるため、許可されたフォルダの中から保護したいファイルを除外することもできます。
読み取り側は、許可リストではなく拒否リストです。これは実用的な作りです。ツールは多くのシステムファイルを読む必要があるからです。ただしその分、サンドボックスが隠すのは、誰かが列挙しようと思ったものだけだということでもあります。
ネットワークをどう制限するか
デフォルトでは、ネットワークアクセスはまったく許可されません。コマンドがネットワークに到達できるのは、サンドボックスの外で動くプロキシ経由だけです。どのドメインを許可するかは、そのプロキシが判断します。
- macOS: コマンドは、ローカルのプロキシポートとの通信だけを許可する生成済みの Seatbelt プロファイル(
sandbox-exec)のもとで実行されます。 - Linux: コマンドは、ネットワーク名前空間を取り除いた bubblewrap のもとで実行されます。外に出る唯一の方法は、サンドボックスにマウントされた Unix ソケット経由でプロキシに接続することです。
HTTP と HTTPS は HTTP プロキシを通ります。その他の TCP トラフィックは SOCKS5 プロキシを通ります。どちらもドメインの許可リストと拒否リストを強制します。Unix ソケットはデフォルトでブロックされます。
なぜこれが良いアプローチなのか
制限が存在するのは OS の中であり、AI の行儀の良さの中でも、コマンド名のリストの中でもありません。コマンドは書き換えられたり、スクリプトに包まれたり、難読化されたりするかもしれません。それでも、サンドボックスが隠しているフォルダを読むことや、与えられたフォルダの外へ書き込むことはできません。同じルールがすべての子プロセスに適用されます。
srt にできないこと
サンドボックスは魔法の盾ではありません。正直な限界を知ることが大切です。それが何を信用できるかを決めるからです。
- その強さは設定の締まり具合に限られます。 ネットワークの許可リストが開いていれば、コマンドが読めるものはすべて外部へ送り出せます。シークレットが拒否リストに載っていなければ、サンドボックスはそれを隠しません。
- ベータ版のソフトウェアです。 プロジェクト自身がそう明記しており、オプションは変更される可能性があります。
- プラットフォームによる差があります。 macOS と Linux に対応しています。Linux では bubblewrap、socat、ripgrep が必要です。Windows 対応は srt ではアルファ段階で、Frely CLI は Windows 上ではサンドボックス化されたコマンドを実行しません。
- いくつかのオプションは意図的に隔離を弱めます。 Unix ソケットの許可、ネストしたサンドボックス、Apple Events は、それぞれ隔離を回避する道を開いてしまいます。README はこれらについて警告しています。
- 制限の対象は、1 つのコマンドのプロセスツリーです。 AI にパスワードを教えてしまう人からは守れませんし、あなた自身がサンドボックスの外へファイルを持ち出す場合も守れません。
Frely CLI は srt をどう使っているか
Frely CLI を使うと、AI からコンピューターを操作できます。AI が依頼し、CLI があなたのデバイス上でコマンドを実行する仕組みです。Frely CLI がリモートの AI クライアントのために実行するすべてのコマンドは、まず srt を通ります。以下では、CLI のソースコードに基づいて、実際にどのようになっているかを見ていきます。
デフォルトの動作
- 書き込み: コマンドが書き込めるのは、ワークスペースフォルダの中とシステムの一時ディレクトリだけです。それ以外には書き込めません。
- 認証情報のフォルダは隠されます。 CLI は、SSH キー、AWS、Google Cloud、Kubernetes、GitHub CLI の設定、GnuPG キー、保存済みの git 認証情報、パッケージレジストリのトークンファイル(
.npmrc、.pypirc、Cargo の認証情報)の読み取りを拒否します。Frely 自身のデバイス認証情報は、どんな承認によっても開けられないようになっています。 - 機密性の高い場所は書き込みから守られたままです。
.zshrcや.bashrcといったシェルの起動ファイル、macOS の LaunchAgents、認証情報のフォルダは書き込みから保護されています。「ホームフォルダの下を書き込んでよい」といった広い許可には含まれません。開くには、その正確なパスを指定する必要があります。 .git/hooksはブロックされたままです。 フックはサンドボックスの外でプログラムを実行するため、どの承認でもこれを開けることはありません。- フェイルクローズドで動作します。 デバイス上でサンドボックスを開始できない場合(非対応のプラットフォームや依存関係の欠落)は、理由を示すメッセージとともにコマンドが拒否されます。サンドボックスなしで黙って実行されることは決してありません。
追加の許可を、狭く求める
コマンドにサンドボックスが隠しているものが必要になったとき、AI が勝手に取ることはできません。AI は依頼をし、デバイスの所有者が Frely の Web サイト上で、パスキーか認証コードによって承認します。チャット内のボタンをタップするのではありません。リクエストには理由と正確なコマンドが明記されます。承認の範囲は、1 つの認証情報グループ(たとえば SSH のみで AWS は含まない)、1 つのキャッシュフォルダ、1 つの特定のディレクトリといった具合に、狭くすることもできます。
どうしても狭い範囲で対応できない場合は、所有者がサンドボックスなしでコマンドを実行することを承認できます。これは最後の選択肢であってデフォルトではなく、CLI の拒否メッセージは、AI にまず最も狭いオプションを求めさせるよう促します。
扉を手渡さずに Git を使う
srt はリポジトリの .git/config への書き込みをブロックします。git の設定は、後からサンドボックスの外で git にプログラムを実行させられるからです。そのため、git push -u や git remote add といった日常的なコマンドもブロックされてしまいます。
Frely CLI は通常のコマンドに対してはこれらの書き込みを許可し、その後で検査します。コマンドの実行前にワークスペース内の各 .git/config のコピーを取り、終了後に比較し、追加された設定のうち git にプログラムを実行させ得るもの(fsmonitor、credential helper、カスタム pager、シェルエイリアスなど)を削除します。結果は、何が削除されたかを AI に伝えます。コマンドがバックグラウンドで動かし続けていたプロセスは停止されます。
サンドボックスの中からのネットワーク接続
srt は HTTP・HTTPS・SOCKS のトラフィックしか扱わないため、ssh のようなツールには工夫が必要です。CLI は ssh、scp、sftp をサンドボックスのプロキシ経由で扱います。データベースクライアントやその他の生の TCP を扱うツールには、内蔵の frely tunnel がサンドボックス内にローカルポートを開けます。ローカルプロキシ(たとえば Clash)経由でインターネットに接続している場合は、frely sandbox proxy でサンドボックスにそれを使わせられます。Frely はプロキシ設定を読み取るだけで、変更はしません。
Frely CLI の srt 利用でカバーしきれないこと
私たちは、その際どい部分も知っておいてほしいと考えています:
- 外向きのネットワークはデフォルトで開いています。 CLI は、npm、pip、git、curl が動き続けられるよう、コマンドがどのドメインに到達できるかを制限しません。つまり、あなたのデータを守るのはファイルのルールだということです。サンドボックスが読めるシークレットは、外部へ送り出すこともできます。保護はネットワークを遮断することからではなく、認証情報を手の届かない場所に置くことから生まれます。
- ホームフォルダの大部分は読み取り可能です。 拒否リストがカバーするのは、よく知られた認証情報の場所であって、プライベートなものすべてではありません。別の場所に置いたファイル(別のプロジェクトの
.envファイル、メモ、ドキュメントなど)は、サンドボックス内で動くコマンドに読み取られます。 - 承認したアクセスは本物のアクセスです。 SSH キーへのアクセスを承認すれば、コマンドはキーを読めます。理解できるものだけを承認し、できる限り最も狭いオプションを選んでください。
.git/configのガードは事後の検査です。 コマンドが終了した後に危険な設定を元に戻します。対象は git に知られているプログラム実行系の設定であり、それ自身にも限界があります。コマンドの間にクリーンアップから逃れたプロセスは、即座には捕捉されず、次の検査で捕捉されます。- 閉じ込めるのはコマンドであって、人ではありません。 サンドボックスはコマンドが触れるものを制限します。賢明でないものを承認してしまうのを止めることはできず、画面ロックや強固なアカウントサインインの代わりにはなりません。
- srt はベータ版のリサーチプレビューであり、 Frely CLI もその位置づけを受け継ぎます。
まとめ
コマンドを実行できる AI の安全性は、そのコマンドを取り巻く壁の強さで決まります。srt は OS レベルで壁を築きます。プロジェクト以外には書き込めないこと、認証情報のフォルダを隠すこと、ネットワークトラフィックを門番に通すことです。Frely CLI はその壁をデフォルトのまま維持し、壁を開けることを、意図的で狭く、人間の承認を要する手順にします。そして、カバーしきれない点も率直に伝えます。