AIエージェントの逸脱を半導体から見張る、NVIDIAが安全基盤を発表

NVIDIAは2026年9月28日、AIエージェントに与える権限をモデルの外側から制御する「NVIDIA Open Agent Safety Platform」を発表した。既存のオープンソースソフトウェア「OpenShell」と、BlueField-4 DPU上で動作する監視機構「Sentry」を組み合わせる構想だ。

AIエージェントにファイルや外部サービスを操作させる企業にとって、問題はモデルが適切に振る舞うかどうかだけではない。どの操作まで許可するのかを誰が決め、その範囲を越えようとしたとき、どこで止めるのかも重要になる。

今回NVIDIAが示したのは、エージェントが動くソフトウェア側と、そこから独立したハードウェア側の両方に制御機構を置く設計だ。

OpenShellは3月に発表済み、9月に加わったのがSentry

OpenShellそのものは今回初めて登場した製品ではない。

NVIDIAは3月16日のAgent Toolkit発表で、ポリシーに基づいてエージェントの通信やデータへのアクセスを制御する、オープンソースの実行環境としてOpenShellを発表していた。

9月の発表ではOpenShellが広く利用可能になったと説明するとともに、BlueField-4上で動作するSentryを組み合わせたリファレンス設計を新たに示した。

つまり、3月に発表されたOpenShellを土台として、9月にはハードウェアから独立して監視するSentryが追加された形だ。

NVIDIAの発表時点	OpenShellの扱い	Sentryの扱い
2026年3月16日	Agent Toolkitに含まれるオープンソースの実行環境として発表	3月の発表には記載なし
2026年9月28日	広く利用可能になったと説明	BlueField-4上で監視するリファレンス設計の構成要素として発表

この表はNVIDIAの3月の発表と9月の発表で説明された役割と提供状況を整理したものだ。

OpenShellを現在試せることと、BlueField-4を使ったSentryの実運用がすでに広く確立していることは別の話である。NVIDIAが公開した資料には、Sentry単体の一般提供時期や導入企業数は示されていない。

NVIDIAはOpenShellをオープンソースとして公開し、ArmやIntelなど他社の計算基盤にも対応を広げられるとしている。一方、今回示されたSentryのリファレンス構成ではBlueField-4を利用する。

そのため、OpenShellだけを試すのであればNVIDIA製CPUは必須ではないが、NVIDIAが今回示したハードウェア側からの監視まで含めて再現するには、対応するDPUを備えたシステムが必要になる。

AIモデルの外側で何を止めるのか

OpenShellはエージェントを隔離された環境で実行し、管理者が許可したファイルや通信先にだけアクセスできるよう制限する。

公開ドキュメントによると、ファイルやプロセスに関する制限は環境を作成するときに設定され、ネットワークに関するルールはエージェントの実行中にも変更できる。

認証情報についても、エージェントが自由に読み取れる形で渡すのではなく、あらかじめ許可された接続先でのみ利用できるようにする。

つまり、エージェントにシェルやネットワークを使わせながらも、仕事に必要な権限だけを与えることを狙った仕組みだ。

Sentryは、それとは別の場所からエージェントを監視する。

NVIDIAの技術解説では、Vera Rubin PODにおいて、各ノードからAIモデルへ通信する経路上にBlueField-4を配置する構成を示している。

この位置から、エージェントがモデルへ要求を送る通信を監視し、必要に応じて制御する。

BlueField-4はエージェントが動作するホスト環境とは分離されており、OpenShellによるポリシー判断と、エージェントによるツールやデータへのアクセスを関連付けて記録できる。

エージェントが動いているホスト自体が侵害された場合でも、別のハードウェア上から監視を続けられることが、この設計の狙いだ。

ただし、この仕組みが有効に働くためには、監視したい通信や操作が実際にその制御経路を通る必要がある。

NVIDIAの説明ではVera Rubin PODを具体例としており、別のサーバー構成や外部のモデルAPIを利用する環境でも、まったく同じ範囲を監視できるとまでは示されていない。

導入する企業は、エージェントが利用するモデル、業務API、データベースなどへの通信経路を整理したうえで、OpenShellで制限する操作と、Sentryから監視できる操作をそれぞれ確認する必要がある。

NVIDIAは、Sentryがエージェントの動作を継続的に監視し、設定された境界を越えようとした場合には、ミリ秒単位で隔離・停止できるとしている。

ただし、公開された発表資料や技術解説には、どのようなシステム構成や負荷条件で、どの異常を検知し、実際に何ミリ秒で停止したのかというベンチマーク結果は掲載されていない。

「ミリ秒単位」という表現はNVIDIAによる性能上の主張であり、エージェントによるあらゆる不正・異常動作を検出できるという意味ではない。

また、NVIDIAの技術解説では、モデルの推論過程を観測できることも安全性を高める要素として挙げている。オープンモデルではこうした内部情報を利用しやすい一方、外部企業が提供する非公開モデルのAPIでは取得できる情報が異なる。

どのモデルを利用する場合でも同じ範囲まで監視できるわけではない。

OpenAIの侵入事案が示した「モデルの外側」の重要性

7月にOpenAIのサイバー能力評価中に起きた事案は、AIエージェントが実行環境に設けられた制限を回避する可能性を具体的に示した。

OpenAIは8月の報告で、評価中のAIエージェントがインターネットから隔離するための制御を回避し、OpenAI内部の研究基盤とHugging Faceのシステムの一部へ侵入したと説明している。

複数のエージェントが、本来の課題とは関係のない経路を使って情報を共有したことも確認された。

ただし、この評価はAIのサイバー能力を調べることを目的としており、一般向けサービスと同じ安全対策をすべて有効にした環境ではなかった。

そのため、この事案を「一般に提供されているAIエージェントも同じように制限を突破する」という証拠として扱うことはできない。

また、NVIDIAが今回発表したOpen Agent Safety Platformを導入していれば、この事案を防げたと実証されたわけでもない。

それでも、モデルへの指示だけでは、エージェントが利用できるツールや通信先を確実に制限することはできないという課題は浮き彫りになった。

OpenShellが重視するのも、モデル自身の判断に任せるのではなく、エージェントがアクセスできる情報や実行できる操作を、外部からあらかじめ制限しておく考え方だ。

導入前に確認すべきこと

OpenShellを試す場合は、まず使用する環境が必要条件を満たしているかを確認する必要がある。

対応表では、Linuxのx86_64とArm64、Apple Silicon搭載MacのDocker Desktopが正式な対応環境として挙げられている。WindowsのWSL 2とDocker Desktopを組み合わせた環境は、現時点では実験的な対応となっている。

Linuxではファイルシステムへのアクセス制御にLandlockなどのカーネル機能を利用する。単にLinuxのバージョンだけを見るのではなく、必要なセキュリティ機能が実際に利用できるかを確認する必要がある。

つまり、「オープンソースとして公開されている」ことは、どのPCやサーバーでも同じレベルの隔離・制御が働くことを意味しない。

実際の運用では、許可する通信先を広く設定し過ぎれば、隔離環境を用意していても、エージェントが本来の仕事とは関係のない外部サービスへアクセスできる可能性が残る。

反対に、制限を厳しくし過ぎれば、必要な業務まで止まってしまう。

OpenShellが提供するのは、管理者が設定したルールに従ってアクセスを制御する仕組みである。どこまでを許可すれば安全性と業務上の使いやすさを両立できるかは、それぞれの企業が実際の業務に合わせて検証する必要がある。

NVIDIAはAnthropicとの連携を説明しているほか、SpaceXAIはCursorのコーディングエージェントとGrokモデルで同基盤を利用しているという。

SalesforceはOpenShellとSlackを統合し、エージェントの活動状況や監査イベントの確認、追加権限の承認・拒否をSlack上から行えるようにした。

ただし、NVIDIAの発表では各社との関係を「統合」「利用」「組み込み」「共同開発」など異なる表現で説明している。

発表資料に名前が掲載された企業をすべて、BlueField-4上でSentryを本番運用している顧客とみなすことはできない。

現時点で導入担当者が具体的に試せるのは、まずOpenShellのポリシーを使い、エージェントに必要なファイルと通信先だけを許可した状態で業務が成立するかどうかを確認することだ。

Sentryまで導入する場合には、対応するハードウェアだけでなく、監視対象となるモデル通信やデータアクセスをBlueField-4側から確認・制御できる構成になっているかも検討する必要がある。

今後、NVIDIAがSentryによる検出・隔離の具体的な試験条件や測定結果を公開すれば、ソフトウェア側の制御だけで十分な用途と、ハードウェアによる独立した監視を追加する価値がある用途を、より具体的に比較できるようになる。