NVIDIA 发布 Open Agent Safety Platform

NVIDIAは9月28日、AIエージェントの動作を監視・制御する「NVIDIA Open Agent Safety Platform」を発表した。エージェントを隔離されたサンドボックスで動かすOpenShellと、独立した監視・制御を担うNVIDIA Sentryを組み合わせ、テストから実運用まで、エージェントをより安全に動かすための仕組みを提供する。

NVIDIAによると、同プラットフォームの技術の開発や活用に関わる企業・組織は100を超えており、Anthropic、Microsoft、Hugging Face、CrowdStrike、SAPなどが含まれる。CanonicalやSUSE、Red Hatも、同プラットフォームの技術をOSやAI基盤へ統合する取り組みを進めている。

Today, with over 100 industry partners, we introduced the NVIDIA Open Agent Safety Platform, bringing together OpenShell and Sentry.

Artificial intelligence is extraordinary technology that will advance discovery, productivity, security, health, and prosperity for generations to… pic.twitter.com/dReAxwpRUn— Jensen Huang (@JensenHuang) September 28, 2026

長時間処理を続けるエージェントを⁠、独立した仕組みで制御

AIエージェントは、ツールを呼び出し、エラーに対処しながら、数日間にわたって処理を続けることがある。NVIDIAは、曖昧な指示やツールの不足、処理の失敗などをきっかけに、エージェントの行動が本来のタスクや運用上の制約から外れる問題を挙げる。こうした状況で、エージェント自身に行動の管理を任せることには限界があるとしている。

Open Agent Safety Platformを構成するOpenShellは、アクセスできる範囲などを定めたルール（ポリシー）に従い、エージェントの外側からアクセスを制御する。Sentryを追加すると、ハードウェア側からもエージェントの動作を監視・制御できる。NVIDIAが示した構成では、Vera CPU上のOpenShellと、NVIDIA BlueField-4 DPU上で動作するSentryを組み合わせる。

OpenShellはファイルや通信へのアクセスを実行時に制限

OpenShellは、AIエージェントを隔離されたサンドボックスで動かし、アクセス可能なファイルやネットワーク、実行できる処理などを制御する実行環境（ランタイム⁠）⁠。サンドボックスを動かす実行基盤には、DockerやPodmanのコンテナ環境やVMなどを選べる。

OpenShell自体は2026年3月に紹介されている。今回の発表に合わせ、NVIDIAはバージョン0.1.0を使い、既存のエージェントの動作を実行時に制御する方法も公開した。

ファイルやプロセスの制限にはOSのカーネル機能を使い、外向きの通信はポリシーに照らして検査する。HTTP、GraphQL、MCPの通信は、設定に応じてリクエストの内容も検査できる。例えば、同じAPIへのアクセスでも、データの読み出しは許可し、書き込みは拒否するといった制御ができる。エージェントがシェルを起動したり、生成したコードや子プロセスを実行したりする場合にも、制御を維持するという。

また、OpenShellのリポジトリによると、OpenShellはAPIキーなどの認証情報をエージェントに渡さずに管理し、承認された接続先へ送るリクエストにだけ、その認証情報を組み込む。

ポリシーを変更する際には、論理的な条件を検証するソフトウェア「Z3」を使った形式検証で、新たに許可されるアクセスを調べる。認証情報を新たな送信先へ渡すなど、リスクのある変更は人による確認を待つことになる。

OpenShellのコードはApache License 2.0で公開されている。NVIDIA Open Agent Safety PlatformのFAQによると、BlueField-4なしでも、対応するローカル環境、オンプレミス、クラウド、Kubernetes基盤で利用できる。既存のエージェントを動かせるほか、エージェントや必要なツールを組み込んだ独自のイメージも使える。

インストールしてOpenCodeを動かす例

公式の初回起動ガイドでは、コーディングエージェントのOpenCodeと、モデルAPIサービスのOpenRouterを使う例を紹介している。ほかにも、Piを動かす例やClaude CodeからGitHubへの書き込みを許可する例が公開されている。

ここでは、OpenCodeの例に沿って、導入から応答の確認までを示す。OpenCodeはローカルのサンドボックス内で動かし、AIモデルはOpenRouter経由で利用する。

この例では実行基盤にDockerを使う。LinuxにDocker Engine 28.0以降を導入・起動した環境と、OpenRouterのアカウント・APIキーを用意する。以下のコマンドは、サンドボックスを動かすLinuxホストのBashで順に実行する。サンドボックスのコンテナはOpenShellが作成・起動する。

まず、OpenShellのインストールスクリプトを実行すると、CLIやポリシーの検証ツールが導入され、サンドボックスを管理するローカルゲートウェイも起動する。openshell statusで、CLIからゲートウェイに接続できることを確認する。

次に、以下のコマンドで取得済みのOpenRouterのAPIキーを入力し、環境変数OPENROUTER_API_KEYに設定する（入力中のAPIキーは画面には表示されない⁠）⁠。続いて、OpenCodeからOpenRouterへの接続を許可するプロファイルを取り込み、この環境変数を使って認証情報を登録する。

最後に、OpenCodeを含むイメージを指定してサンドボックスを作成し、「⁠OKと返答する」という短い指示を実行する。モデルには、公式例と同じくOpenRouterで無料提供されるNVIDIA Nemotron 3.5 Lightningを指定している。

実行すると、モデルの応答がターミナルに表示される。取り込んだプロファイルは接続を許可する実行ファイルと送信先を指定し、OpenShellはopenrouter.aiへ送るリクエストにだけAPIキーを加える。新たな接続を許可する手順など、詳しくはエージェント起動ガイドを参照のこと。

SentryはBlueField-4上で独立して監視⁠・隔離

Sentryは、ネットワークやセキュリティなどの処理を担う専用プロセッサ「NVIDIA BlueField-4 DPU」上で動作する。エージェントを実行するホスト側のソフトウェアから分離された環境で、エージェントの動作を監視・制御する。

BlueField上でソフトウェアを開発・実行するための「NVIDIA DOCA」を使い、リクエストと応答の検査、エージェントのID確認、データやツールへのアクセスポリシーの適用などを行う。NVIDIAは、エージェントがソフトウェアで設けた制限を越えようとした場合、そのエージェントをミリ秒単位で隔離・停止できるとしている。

コラム⁠：許可済みの通信から異常を見つける試み

通信先を許可していても、その使い方が本来の目的に沿っているとは限らない。Hugging Face CEOのClément Delangue氏はXへの投稿で、許可済みの通信を監視するOpenShell向けの概念実証を紹介した。

同氏が問題として挙げるのは、許可されたソフトウェアリポジトリを、エージェント同士の連絡用掲示板に転用する使い方。通信先の許可だけでは、こうした利用を捉えられない。

投稿では、サンドボックスごとのリクエスト数・書き込み数・通信量に上限を設ける方法や、各サンドボックスの振る舞いを通常時や他のサンドボックス群と比較し、変化を検出する方法を挙げている。複数のサンドボックスを横断した監視も含み、多数のサンドボックスが同じホストへ急に書き込み始めた場合などを検出対象にする。

紹介されたデモでは、4つのエージェントが許可済みのリポジトリを介して連携する状況を再現した。個々のアクセスルールへの違反はなかったものの、複数のサンドボックスを横断して監視することで、この連携を数分で検出できたという。

また、許可済みの通信を監視する仕組みを試すため、通信回数の上限を設定して動作を確認する手順も公開されている。手順では、OpenShellのフォーク上にある実証用ブランチを使う。