コーディングエージェントへ「このバグを直して」と頼むと、AIはコードを読むだけでなく、ファイルを書き換え、コマンドを実行し、パッケージを入れ、外部APIへ接続する。
便利さは、従来のチャットAIよりはるかに大きい。
同時に、誤った指示やプロンプトインジェクションが実際のシステム操作へつながる範囲も広がる。
NVIDIAが2026年9月28日に発表したOpen Agent Safety Platformは、この問題を「モデルが安全に振る舞うこと」だけへ任せず、実行環境とハードウェア側でも制御する考え方だ。
中心になるOpenShellはすでにオープンソースで利用できる。
一方、SentryはBlueField-4 DPU上で独立して監視する企業インフラ向けの層だ。
両者を同じ製品として考えるより、リスクに応じて防御層を追加する仕組みとして理解すると導入判断がしやすい。
NVIDIA Open Agent Safety Platformは、ソフトウェアのOpenShellと、リファレンスシステム設計としてのNVIDIA Sentryを組み合わせる。
OpenShellはエージェントをサンドボックスで実行し、どのファイル、ネットワーク、プロセス、モデルプロバイダーへアクセスできるかを宣言的なポリシーで制御する。
SentryはBlueField-4 DPU上でホストとは別の信頼領域から挙動を監視し、境界を逸脱した場合の隔離・停止を担う。
NVIDIAはVera CPUとBlueField-4を組み合わせた構成を最適化されたリファレンスとして示すが、OpenShellそのものは第三者の計算基盤へ拡張できる。
したがって「NVIDIAの次世代サーバーを買わなければOpenShellを試せない」という理解は正しくない。
OpenShellの現在のドキュメントでは、主な防御領域をfilesystem、network、process、providersに分けている。
filesystemではLandlockを使い、エージェントが読める・書けるパスを制限する。processでは非特権ユーザーやseccompなどを使い、権限昇格や危険なシステムコールを抑える。
networkでは送信先、ポート、実行バイナリなどをポリシーで評価し、許可していない外向き通信を止める。
providerはAPIキーなどの資格情報をエージェントへ丸見えで渡さず、許可したエンドポイントとバイナリへ結びつける仕組みだ。
秘密情報を読ませた上で「使わないで」と指示するのではなく、そもそも直接触れにくい境界を作る。
公式QuickstartではインストールスクリプトでCLIを導入し、ローカルgatewayとsandboxを作成する流れが案内されている。
現行READMEでは、まず最小Ubuntuサンドボックスを作り、必要なエージェント、provider、policyを後から明示的に追加する。
実運用では最初から広い権限を与えない。
作業ディレクトリだけ読み書き可、ネットワークはGitHubや利用するモデルAPIなど必要な宛先だけ、資格情報も必要なproviderだけを渡す。
ポリシー変更ではfilesystemやprocessのように作成時に固定される制御と、networkやproviderのように実行中に更新できる制御がある。
例外が必要になったとき、全部解除するのではなく不足した権限だけを追加する運用が基本になる。
OpenShellの現行READMEはLinux、Apple SiliconのmacOS、実験的なWindows WSL2を案内している。
Docker、Podman、ホスト仮想化が利用でき、プロジェクトはMicroVMやKubernetesを含む複数の計算基盤をサポート対象としている。
Supported AgentsではClaude Codeがbase imageでfull coverage、OpenCodeがpartial coverage、Codexもプリインストール対象として記載されている。
ただし「動く」と「標準ポリシーで全機能が安全にカバーされる」は別なので、各エージェントのDefault Policy欄を確認したい。
推論先もNVIDIAモデルに限定されない。
providerを設定して外部APIを使う構成や、ローカル・セルフホストの推論先へルーティングする構成を取れる。
DockerやVMもエージェント隔離に使えるため、OpenShellは「サンドボックスという概念を初めて作った」ものではない。
違いは、エージェント運用に必要な権限管理をpolicy、provider、network egress、observabilityとまとめて扱う点にある。
通常のDockerコンテナでもファイルマウント、capabilities、seccomp、ネットワークを細かく設定できる。
しかしエージェントが途中で新しいAPIを必要としたり、複数の資格情報を扱ったりすると、運用ルールを自前で組み合わせる必要がある。
OpenShellはその境界をエージェント前提で提供する。ただしDockerやVMより常に安全と一言で比較できるわけではない。
ホスト設定、ポリシー品質、脆弱性、管理者権限など別の攻撃面は残る。
SentryはOpenShellの上位版ではない。
BlueField-4 DPUというホストから独立したハードウェア上で動き、エージェントの挙動をout-of-bandで監視する追加の信頼層だ。
NVIDIAのリファレンスでは、BlueField-4をモデルへの経路上に置き、OpenShellのポリシーやエージェント活動を独立して観測する。
ホスト側のエージェントやOSが侵害された場合でも、監視側を同じプロセスから操作しにくくするのが狙いだ。
個人開発や低リスクの社内検証では、まずOpenShell単体でエージェントの権限を狭めるところから始められる。
たとえば公開リポジトリのコード修正、テスト生成、社外秘を含まない調査などだ。
ここでは専用BlueFieldを導入するより、作業ディレクトリ、外部通信、provider、ログを正しく設定する方が優先度は高い。
エージェントにホストのホームディレクトリ全体を渡さない、クラウド管理者キーを置かない、といった基本設計の効果が大きい。
OpenShellは防御を自動で完成させる製品ではない。どの権限が必要かを人間が定義し、例外をレビューする仕組みは残る。
Sentryの価値が上がるのは、エージェントが長時間自律動作し、重要データや本番システム、ロボティクスなどへアクセスする環境だ。
ソフトウェア境界だけでは、ホストOS自体が侵害された場合や、監視プロセスと実行プロセスが同じ信頼領域にあることが問題になる。
独立したDPUから監視すれば、エージェントや攻撃者から見えにくい場所でポリシーを強制できる。
一方、小規模チームがClaude Codeを安全に試すためにBlueField-4を買うという話ではない。
SentryはデータセンターやAI factoryを想定したリファレンス設計として捉えるべきだ。
権限を狭くすると、エージェントが正当な作業を進める途中でブロックされることがある。
そのとき自動的に全権限を解放すると、サンドボックスの意味が薄れる。
OpenShellはobservabilityとしてsandbox logsやOCSF JSON形式のエクスポートを案内している。
誰がどのポリシー変更を承認したか、どの外部宛先へ接続したかを追えるようにする。
本番では、読み取り、内部書き込み、外部送信、デプロイ、削除、決済など操作の影響度を分ける。
危険度の高い操作はOpenShellの実行境界だけでなく、アプリ側でも人の承認を残す多層設計が安全だ。
レベル1は個人・検証環境だ。
OpenShellで専用sandboxを作り、必要な作業フォルダとAPIだけを許可する。
秘密鍵や個人ホームを見せない。
レベル2は社内データを扱う環境。providerで資格情報を分離し、通信先をallowlist化し、ログを保存する。
ポリシー変更にレビューを入れ、エージェント用のサービスアカウントも最小権限にする。
レベル3は重要インフラ・本番系。OpenShellに加え、ネットワーク分離、独立監視、ハードウェアベースの信頼境界を検討する。
Vera／BlueField-4／Sentryはこの層のリファレンスとして位置づけられる。
Open Agent Safety Platformの価値は「安全なAIモデル」を作ることではなく、モデルが間違えても実行できる範囲を別の層で狭めることにある。
OpenShellはすでにApache 2.0のOSSとして利用でき、ファイル、通信、プロセス、資格情報をエージェント外の境界で制御する。
NVIDIA VeraやBlueFieldがなければ使えないソフトではないため、開発者は既存環境から検証を始められる。
Sentryはさらに、ホストから独立したBlueField-4上で監視する企業インフラ向けの層だ。
すべての環境へ同じ構成を入れるのではなく、エージェントが触るデータ、実行できる操作、停止時の影響を基準に防御層を増やすのが現実的だ。
.png){kind=logo}
.png)
