アップデート一覧に戻る
New releaseJul 23, 2026

sandbox-runtime v0.0.67

軽量なサンドボックスツールで、コンテナを必要とせずに、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 ツールとしてもライブラリとしても使用できるスタンドアロンのサンドボックス実装を提供します。デフォルトで安全という設計思想に基づいており、開発者の一般的なユースケースに合わせて調整されています。プロセスは最小限のアクセス権で起動し、必要な穴だけを明示的に開けます。

主な機能:

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

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

主要なユースケースの一つは、Model Context Protocol (MCP) サーバーをサンドボックス化してその機能を制限することです。例えば、filesystem 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 の外向きフェンス、書き込み制限付きトークン、および作業ツリー上の明示的な ACE を適用します

0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305

二重分離モデル

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

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

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

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

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

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

  • Windows: マシン全体の WFP フィルタセットが、プロキシポート範囲へのループバックを除き、srt-sandbox アカウントとして実行されるプロセスによる外向き接続をブロックします。プロキシはその範囲内でリッスンし、すべてのネットワークアクセスのための制御されたチャネルを作成します。このフィルタは、ソケットを作成する前にスレッドに別のトークンを設定するサンドボックス化されたプロセスや、システムサービスがその代理で運ぶトラフィックには追従しません。Windows の既知の制限事項を参照してください

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 オブジェクトで、設定ファイルと同じ形式です。各行は設定全体を置き換え、同じスキーマに対して検証されます。つまり、各行はパッチではなく完全な設定です。network と filesystem は必須であり、行に含まれないキーはデフォルトに戻ります。

# fd 3 is the read end of a pipe the caller writes lines to
srt --control-fd 3 -- npm test

コマンド実行中に、受け入れられた行が変更するもの:

  • ネットワークリスト — network.allowedDomains、deniedDomains（deniedDomainReasons 付き）、および deniedResolvedAddresses — は、すべてのプラットフォームで次の接続時に有効になります。プロキシはリクエストごとにこれらを参照し、解決済みアドレスのチェックも同じ行から再構築されます。同様に network.mitmProxy と network.tlsTerminate.excludeDomains も、リクエストごとに読み取られます。
  • credentials.sigv4 は、srt が credentials ブロック付きで起動していた場合に限り、次のリクエストで有効になります。署名フックはその場合にのみインストールされ、ポリシーをキャプチャするのではなくリクエストごとに読み取ります。
  • それ以外は何も変わりません。ファイルシステムルールはすでに seatbelt プロファイル、bubblewrap の argv、または Windows の ACE に組み込まれており、資格情報マスクはコマンドがラップされた時点で構築され、実行中のプロキシサーバーは起動時に network.parentProxy と、そもそも TLS を終端するかどうかをキャプチャしています。
  • Windows では、srt はファイルアクセスセット（filesystem.* と credentials.files）が起動時に適用されたものと異なる行を検出し、SRT_DEBUG の下でのみそれを通知します。ACL の付与はセッション全体にわたるため、起動時に適用されたセットが有効なままです。行の残りの部分は上記のとおりに適用されます。

srt がチャネルを読み取る方法と、拒否するもの:

もっと読む

カテゴリ

防御ツールコンテナセキュリティ動的分析 (サンドボックス)構成監査セキュリティ仮想化ネットワークセキュリティインシデントレスポンス