アップデート一覧に戻る
New releaseAug 27, 2026

sandbox-runtime v0.0.74

コンテナを必要とせず、OSレベルで任意のプロセスに対してファイルシステムとネットワークの制限を強制する軽量なサンドボックスツール。

共有

Anthropic Sandbox Runtime (srt)

コンテナを必要とせず、OSレベルで任意のプロセスにファイルシステムとネットワークの制限を適用するための軽量サンドボックスツールです。

srt はネイティブOSのサンドボックスプリミティブ(macOSでは sandbox-exec、Linuxでは bubblewrap)とプロキシベースのネットワークフィルタリングを使用します。エージェント、ローカルMCPサーバー、bashコマンド、および任意のプロセスの動作をサンドボックス化するために使用できます。

ベータリサーチプレビュー

Sandbox Runtimeは、より安全なAIエージェントを実現するために Claude Code 向けに開発されたリサーチプレビューです。より広範なエコシステムがより安全なエージェントシステムを構築できるよう支援するため、早期のオープンソースプレビューとして公開されています。これは早期のリサーチプレビューであるため、APIおよび設定フォーマットは進化する可能性があります。AIエージェントをデフォルトでより安全にするためのフィードバックと貢献を歓迎します!

インストール

npm install -g @anthropic-ai/sandbox-runtime

基本的な使い方

# Network restrictions
$ srt "curl anthropic.com"
Running: curl anthropic.com
<html>...</html>  # Request succeeds

$ srt "curl example.com"
Running: curl example.com
Connection blocked by network allowlist  # Request blocked

# Filesystem restrictions
$ srt "cat README.md"
Running: cat README.md
# Anthropic Sandb...  # Current directory access allowed

$ srt "cat ~/.ssh/id_rsa"
Running: cat ~/.ssh/id_rsa
cat: /Users/ollie/.ssh/id_rsa: Operation not permitted  # Specific file blocked

概要

このパッケージは、CLI ツールとしてもライブラリとしても使用できるスタンドアロンのサンドボックス実装を提供します。一般的な開発者のユースケースに合わせた secure-by-default の思想で設計されており、プロセスは最小限のアクセス権で起動し、必要な穴だけを明示的に開けます。

主な機能:

  • ネットワーク制限: HTTP/HTTPS やその他のプロトコルでアクセスできるホスト/ドメインを制御
  • ファイルシステム制限: 読み書きできるファイル/ディレクトリを制御
  • Unix ソケット制限: ローカル IPC ソケットへのアクセスを制御
  • 違反モニタリング: macOS では、システムのサンドボックス違反ログストアに接続してリアルタイムのアラートを取得

ユースケースの例: MCP サーバーのサンドボックス化

主要なユースケースは、Model Context Protocol (MCP) サーバーをサンドボックス化してその機能を制限することです。たとえば、ファイルシステム MCP サーバーをサンドボックス化するには:

サンドボックス化なし (.mcp.json):

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

サンドボックス化あり(.mcp.json):

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

次に、~/.srt-settings.json で制限を設定します:

{
  "filesystem": {
    "denyRead": [],
    "allowWrite": ["."],
    "denyWrite": ["~/sensitive-folder"]
  },
  "network": {
    "allowedDomains": [],
    "deniedDomains": []
  }
}

これで、MCPサーバーは拒否されたパスへの書き込みをブロックされます:

> Write a file to ~/sensitive-folder
✗ Error: EPERM: operation not permitted, open '/Users/ollie/sensitive-folder/test.txt'

仕組み

サンドボックスは OS レベルのプリミティブを使用して、プロセスツリー全体に適用される制限を強制します:

  • macOS: 動的に生成された Seatbelt プロファイル を使用して sandbox-exec を実行します
  • Linux: ネットワーク名前空間の分離を伴うコンテナ化のために bubblewrap を使用します
  • Windows: 専用の srt-sandbox ローカルユーザーアカウントの下でサンドボックス化されたプロセスを実行し、そのアカウントの SID をキーとした Windows Filtering Platform の egress フェンスと、作業ツリー上のセッションごとの明示的な ACE を使用します

0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305

二重分離モデル

効果的なサンドボックス化には、ファイルシステムとネットワークの両方の分離が必要です。ファイル分離がなければ、侵害されたプロセスが SSH キーやその他の機密ファイルを流出させる可能性があります。ネットワーク分離がなければ、プロセスがサンドボックスを脱出して無制限のネットワークアクセスを取得する可能性があります。

ファイルシステム分離 は読み取りと書き込みの制限を強制します:

  • 読み取り (deny-then-allow パターン): デフォルトでは、読み取りアクセスはどこでも許可されます。広い領域 (例: /Users) を拒否してから、その中の特定のパス (例: .) を再許可できます。allowRead は denyRead より優先されます — これは書き込みとは逆で、書き込みでは denyWrite が allowWrite より優先されます。allowRead 領域の内側にある、より具体的な denyRead エントリ (例: allowRead: ["."] を伴う denyRead: ["**/.env"] や ["./secrets"]) は依然として拒否されたままです。
  • 書き込み (allow-only パターン): デフォルトでは、書き込みアクセスはどこでも拒否されます。パス (例: .、/tmp) を明示的に許可する必要があります。許可リストが空の場合、書き込みアクセスはありません。

ネットワーク分離 (allow-only パターン): デフォルトでは、すべてのネットワークアクセスが拒否されます。ドメインを明示的に許可する必要があります。allowedDomains リストが空の場合、ネットワークアクセスはありません。ネットワークトラフィックはホスト上で実行されているプロキシサーバーを経由してルーティングされます:

  • Linux: リクエストはファイルシステムを介して Unix ドメインソケット経由でルーティングされます。サンドボックス化されたプロセスのネットワーク名前空間は完全に削除されるため、すべてのネットワークトラフィックはホスト上で実行されているプロキシ (サンドボックスにバインドマウントされた Unix ソケットでリッスン) を経由する必要があります

  • macOS: Seatbelt プロファイルは特定の localhost ポートへの通信のみを許可します。プロキシはこのポートでリッスンし、すべてのネットワークアクセスのための制御されたチャネルを作成します

  • Windows: マシン全体の WFP フィルターセットは、プロキシポート範囲へのループバックを除き、srt-sandbox アカウントから発信されるすべてのアウトバウンド接続をブロックします。プロキシはその範囲内でリッスンし、すべてのネットワークアクセスのための制御されたチャネルを作成します

HTTP/HTTPS (HTTP プロキシ経由) とその他の TCP トラフィック (SOCKS5 プロキシ経由) の両方がこれらのプロキシによって仲介され、ドメインの許可リストと拒否リストが強制されます。

Claude Code でのサンドボックス化の詳細については、以下を参照してください:

アーキテクチャ

src/
├── index.ts                  # Library exports
├── cli.ts                    # CLI entrypoint (srt command)
├── utils/                    # Shared utilities
│   ├── debug.ts             # Debug logging
│   ├── settings.ts          # Settings reader (permissions + sandbox config)
│   ├── platform.ts          # Platform detection
│   └── exec.ts              # Command execution utilities
└── sandbox/                  # Sandbox implementation
    ├── sandbox-manager.ts    # Main sandbox manager
    ├── sandbox-schemas.ts    # Zod schemas for validation
    ├── sandbox-violation-store.ts # Violation tracking
    ├── sandbox-utils.ts      # Shared sandbox utilities
    ├── http-proxy.ts         # HTTP/HTTPS proxy for network filtering
    ├── socks-proxy.ts        # SOCKS5 proxy for network filtering
    ├── linux-sandbox-utils.ts # Linux bubblewrap sandboxing
    ├── macos-sandbox-utils.ts # macOS sandbox-exec sandboxing
    └── windows-sandbox-utils.ts # Windows srt-win sandboxing

使用方法

CLI ツールとして

srt コマンド(Anthropic Sandbox Runtime)は、あらゆるコマンドをセキュリティ境界でラップします:

# Run a command in the sandbox
srt echo "hello world"

# With debug logging
srt --debug curl https://example.com

# Specify custom settings file
srt --settings /path/to/srt-settings.json npm install

設定ファイルは任意です — ~/.srt-settings.json にファイルがなければ、srt は組み込みのデフォルトで動作します。ネットワークアクセスなし、デフォルトの書き込みパス以外への書き込みなし、読み取りは無制限です。設定ファイルが 存在する ものの、空であるか、読み取れないか、検証に失敗した場合はエラーです。srt はその旨を伝えて終了し、デフォルトへのフォールバックは行いません。デフォルトはより弱い設定ではなく別の設定であり、フォールバックするとファイルの denyRead、allowRead、および認証情報ルールを、ファイルが述べていた他のすべてとともに失うことになるからです。--settings で指定されたファイルも同様で、これも存在しなければなりません。

コマンド実行中に設定を更新する: --control-fd

--control-fd <fd> は、呼び出し側がすでに開いているディスクリプタから設定更新を読み取ります。1 行につき 1 つの JSON オブジェクトで、設定ファイルと同じ形です。各行は設定全体を置き換えますが、すでに実行中のものに対して変更を及ぼすのはネットワークリスト(allowedDomains / deniedDomains)だけです。プロキシはリクエストごとにこれらを参照します。ファイルシステムルールはラップ時にサンドボックスへコンパイルされるため、それらを変更する行は現在の実行には何も適用されません。

# fd 3 is the read end of a pipe the caller writes lines to
srt --control-fd 3 -- npm test
  • ディスクリプタは 3 以上 の整数で、読み取り可能でなければならない — 0-2 は標準ストリームである。srt は与えられたディスクリプタを読み取れない場合、 コマンドを実行せずにエラーで終了するため、死んだチャネルが生きたものと 誤認されることはない。単一の更新を配信する前に死んだチャネルは コマンドを道連れにする。配信後に死んだチャネルはその旨を報告し、 最後に適用された設定の下でコマンドを実行し続ける。
  • 有効な設定でない行は stderr に報告されて破棄され、 以前の設定が引き続き有効となる。
  • srt は ラップされたコマンドと共に終了 し、ライターがディスクリプタを 閉じるのを待たない。入力の終了もエラーではない。コマンドは 最後に適用された設定の下で実行し続ける。
  • srt には 専用の読み取り専用の端 を与えること。srt はパイプやソケットを 非ブロッキングモードに設定し、そのフラグはオープンファイル記述子上に存在するため、 同じ記述子を保持する他のもの — シェルの exec 3<fifo、親が使い続ける ディスクリプタの pass_fds — は、それ以降自身のブロッキング読み取りで EAGAIN を受け取ることになる。
  • macOS と Linux では、サンドボックス化されたコマンドはディスクリプタを 受け取らない。srt はそのスロットをコマンドに対して /dev/null に向けるため、 サンドボックス内の何も更新を読み取ったり、独自の設定を書き込んだりできない。

ライブラリとして

import {
  SandboxManager,
  type SandboxRuntimeConfig,
} from '@anthropic-ai/sandbox-runtime'
import { spawn } from 'child_process'

// Define your sandbox configuration
const config: SandboxRuntimeConfig = {
  network: {
    allowedDomains: ['example.com', 'api.github.com'],
    deniedDomains: [],
  },
  filesystem: {
    denyRead: ['~/.ssh'],
    allowWrite: ['.', '/tmp'],
    denyWrite: ['.env'],
  },
}

カテゴリ