AIエージェントやローカルMCPサーバーにbashや任意プロセスを任せるほど、鍵の持ち出しや意図しない外部送信をどう封じるかが重くなる。Anthropicが公開したsandbox-runtime(CLI名 srt、npm @anthropic-ai/sandbox-runtime)は、この悩みにコンテナなしで答えるOSSだ。本記事ではv0.0.81をLinux(x86_64)で実機検証し、仕組みと保証の範囲を整理する。

HOW SRT WRAPS A PROCESSsrt が包む流れ

srt は既定で全部閉じ、許可した穴だけ開ける

  1. 任意のプロセス

    エージェント・MCP・bash

  2. srt でラップ

    OS機構+プロキシ

  3. 既定は全拒否

    ネット無・外部書込無

  4. 許可だけ通す

    allowlist で穴開け

出典: README(2026-10-25時点)

30秒でわかるsandbox-runtime(2026-10-25時点)

  • ・正体:AIエージェント・MCPサーバー・bashをコンテナなしでOSレベルにサンドボックス化するCLI兼ライブラリ。★6.4k・Apache-2.0・Claude Code向けに開発
  • ・何ができる:ファイルの読み書きとネットワーク接続を既定で全拒否し、許可リストで必要な穴だけ開ける(deny-by-default)
  • ・実測:Linuxで許可ドメインはHTTP 200・非許可は遮断、CWD外の書き込みと.git/hooks・.bashrcへの書き込みが遮断されるところまで確認
  • ・注意:公式が「ベータ研究プレビュー」と明示。設定は変わりえて、ふさがらない経路も残る(多層防御の一枚)

AIエージェントの暴走や乗っ取りに備える防御の設計は、サプライチェーン攻撃とは|手口・防御ツール比較・npm 12の新機構まで実践解説に全体像をまとめている。本記事はその中で「実行時に何を触らせないか」を担う一手を掘り下げる。

sandbox-runtimeとは|コンテナなしのOSサンドボックス

sandbox-runtimeは任意のコマンドの前にsrtを足すだけで、そのプロセスツリー全体にファイルとネットワークの制限をかけるツールだ。READMEは自身を「コンテナを必要とせず、OSレベルでファイルシステムとネットワークの制限を強制する軽量なサンドボックス」と説明する。

読者の3つの疑問に即して言うと、何ができるかはプロセスが読み書きできるファイルと接続先ドメインを絞れること、何を解決するかはエージェントが鍵ファイルを読んで外部へ送る・設定ファイルを書き換えるといった経路を実行時に封じること、何を代替するかは「プロセス1個を囲うためにコンテナを立てる」手間をOS標準の機構で置き換えることだ。

Claude Code向けに開発され、より安全なAIエージェントを広く作れるようにと早期のオープンソースプレビューとして出された経緯がある。エージェントにファイルシステムを預ける危うさそのものはAIエージェントにファイル操作を任せる前に知る安全設計でも扱った課題で、srtはそこへ「OSに強制させる」という答えを出す。

srtの仕組み|OS機構とプロキシで既定を全拒否

srtは魔法ではなく、OSがもともと持つサンドボックス機構を束ねて使う。プラットフォームごとに下敷きが違う。

DENY BY DEFAULT実測した遮断と許可

許可リストに載せた操作だけが通る

既定=全拒否

  • net許可ドメインへ通信 通るanthropic.com → HTTP 200
  • netそれ以外へ通信 遮断example.com → HTTP 000
  • fs許可パスへ書込 通るallowWrite:[.]内
  • fs.git/hooks・.bashrc 遮断自動保護パス
出典: srt 0.0.81 を Linux x86_64 で実測(2026-10-25)
OS 隔離の下敷き ネットワークの絞り方
macOS sandbox-exec+動的生成したSeatbeltプロファイル localhostの特定ポートにだけ通信を許し、プロキシが仲介
Linux bubblewrap+ネットワーク名前空間の分離 名前空間を外し、全通信をUnixソケット経由でホスト側プロキシへ
Windows(alpha) 専用srt-sandboxアカウント+書込制限トークン Windows Filtering Platformで当該アカウントの外向き通信を遮断

要になるのはdeny-by-defaultの二重の絞り込みだ。ネットワークは既定ですべて拒否で、allowedDomainsに挙げたホストだけが通る。HTTP/HTTPSはHTTPプロキシ、それ以外のTCPはSOCKS5プロキシが仲介し、許可・拒否リストを適用する。ファイルは、書き込みが既定で拒否(許可したパスだけ可)、読み取りは既定で許可してdenyReadで塞ぐ、という非対称な設計になっている。

加えてLinuxでは、.bashrc・.zshrc・.gitconfig・.git/hooks/・.vscode/・.mcp.jsonなどが自動保護パスとして扱われ、allowWriteに広いパスを指定していても書き込みが弾かれる。サンドボックス回避や設定改ざんへの多層防御だ。

実測:導入から起動確認まで(Linux)

導入はnpmのグローバルインストールだけ。Node.js 22.12以降が要る。

npm install -g @anthropic-ai/sandbox-runtime
srt --version   # 0.0.81

Linuxでは追加でbubblewrap・socat・ripgrepが要る(Ubuntu/Debianならapt-get install bubblewrap socat ripgrep)。macOSはripgrepのみ、Windowsはsrt-win.exeが同梱で追加依存はない。

起動確認と、既定で通信が閉じていることを見る。設定ファイル~/.srt-settings.jsonが無ければ、srtは組み込みの既定(ネットワーク無し・既定の書込パス以外は不可・読み取りは自由)で動く。

srt echo "hello world"
srt -c "curl -s -m 10 -o /dev/null -w '%{http_code}\n' https://example.com"

手元のLinux(x86_64)では、1行目はhello worldを出し、2行目は000を返した。既定でネットワークが閉じているため、curlは接続を確立できない。

許可リストを効かせるには設定ファイルを書く。networkとfilesystemは必須で、filesystem.denyReadも省略できない(省くとsrtは起動を拒否し、安全側の既定へ勝手に落ちない)。

{
  "network": { "allowedDomains": ["anthropic.com", "*.anthropic.com"], "deniedDomains": [] },
  "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": [] }
}

この設定を置いた状態でwww.anthropic.comへはHTTP 200で通り、example.comへは000で遮断された(許可リスト外は通さない、という陽性対照つきの確認)。書き込みは、allowWrite: ["."]で作業ディレクトリ内は成功する一方、ディレクトリ外への書き込みと、.git/hooks/pre-commit・.bashrcへの書き込みはいずれも弾かれた。

検証環境:Linux(x86_64)・srt 0.0.81・bubblewrap 0.9.0/2026-10-25

  • ・npm導入→srt echoの起動、ネットワークの許可/遮断、ファイル書き込みの許可/遮断、自動保護パスの遮断まで、いずれも陽性対照つきで確認した。

未検証の範囲

  • ・macOS(Seatbelt)とWindows(alpha)は確認していない。Unixソケットを塞ぐseccompフィルタの挙動、実行中に設定を差し替える--control-fd、TLS終端によるHTTPS検査も未検証。

MCPサーバー・エージェントを安全に動かす

srtの狙いどころの一つが、ローカルMCPサーバーの権限を絞ることだ。.mcp.jsonで起動コマンドをsrtでラップするだけでよい。

{
  "mcpServers": {
    "filesystem": {
      "command": "srt",
      "args": ["npx", "-y", "@modelcontextprotocol/server-filesystem"]
    }
  }
}

あとは~/.srt-settings.jsonで読み書きとドメインを決める。たとえばallowWriteを作業フォルダだけにし、機微なフォルダをdenyWriteに入れれば、MCPサーバーがそこへ書こうとしてもEPERMで止まる。MCPの実行経路そのものに脆弱性が見つかった事例(AnthropicのMCP stdio実装におけるRCE)もあり、サーバー側の信頼だけに頼らず、実行時にOSで囲う価値は大きい。

コンテナとの住み分けはこう整理できる。

CONTAINER VS SRTコンテナとの違い

コンテナとsrtはどう違うか

コンテナ(Docker)で隔離

イメージ単位

  • イメージ・デーモンの用意が要る
  • プロセス1個を包むには重い
  • FS・ネットは別概念で組む

srt で隔離

プロセス単位

  • コンテナ不要・OS機構を直接使う
  • コマンドの前に srt を足すだけ
  • deny-by-default の許可リストで両方
出典: README(2026-10-25時点)

Dockerはイメージ単位で環境ごと隔離するのに向き、srtは「いま動かすプロセス1個」を軽く囲うのに向く。AIエージェントが本番データベースを一瞬で消したCursorのエージェントが本番DBを削除した事例のような事故は、書き込み先を許可リストで縛っていれば被害を狭められた類のものだ。

保証範囲と注意|ベータ研究プレビュー

ここが一番大事なので、公式の但し書きのまま書く。srtはベータ研究プレビューであり、APIや設定形式は今後変わりうる。そして「導入すれば安全」ではなく、設計上ふさがらない経路がREADMEに明記されている。

・広いドメイン許可は抜け道になる:github.comを許可すれば任意のリポジトリへpushできてしまい、データ持ち出しの経路になりうる。許可は最小限にし、必要ならMITMプロキシで個別APIまで絞る。
・Unixソケットの許可は権限昇格を招く:/var/run/docker.sockを通せば、実質ホストを握られる。許すソケットは慎重に選ぶ。
・広い書き込み許可も危うい:$PATH上の実行ファイルやシェル設定を書ける範囲を許すと、別の文脈でのコード実行に化ける。
・弱めるオプションは弱める:Docker内で動かすためのenableWeakerNestedSandboxや、macOSのenableWeakerNetworkIsolationは、名前のとおり安全性を下げる。使うなら別の隔離が別途あるときだけ

つまりsrtは「エージェントに渡す権限を既定で絞り、必要な穴だけ開ける」ための道具であって、万能の封じ込めではない。多層防御の一枚として、許可リストを最小に保つ運用とセットで効く。Claude Code自体のサンドボックス設計を含む全体像はClaude Code完全ガイドも参照したい。

ライセンスと採用判断

ライセンスはLICENSEファイル実体でApache-2.0(Copyright 2025 Anthropic、追加条項なし)。npmで@anthropic-ai/sandbox-runtimeとして配布され、CLIとライブラリ(SandboxManager)の両方で使える。言語はTypeScript主体に、Unixソケット遮断用のseccompをC、Windowsヘルパをrustで補う構成だ。

向いている人:ローカルMCPサーバーやエージェントにファイル・ネットワークの最小権限を与えたい人、コンテナを立てずにプロセス単位で囲いたい人。待った方がよい人:設定形式の安定を前提に本番へ組み込みたい人(ベータ研究プレビューのため)、macOS/Windowsで本記事の未検証部分まで保証が要る人は、自分の環境で起動確認してから採る方がよい。

まとめ

この記事の結論

  • ・srtは、AIエージェントやMCPサーバーをコンテナなしでOSサンドボックス化し、ファイルとネットワークを既定で全拒否にできるApache-2.0のOSS。Linuxで許可/遮断・自動保護パスまで実測できた。
  • ・ただし公式がベータ研究プレビューと明示し、広いドメイン許可などふさがらない経路も残る。許可を最小に保つ運用とセットで、多層防御の一枚として使うのが前提。

参照ソース

・anthropics/sandbox-runtime(公式リポジトリ・README) — 仕組み・設定・Security Limitations(2026-10-25時点・v0.0.81)
・npm: @anthropic-ai/sandbox-runtime — 配布パッケージ・バージョン