NVIDIA、AIエージェント安全稼働基盤「Open Agent Safety Platform」発表|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年09月29日更新日時: 2026年09月29日

NVIDIAは2026年9月28日、AIエージェントの動作をソフトウェアとハードウェアの両方から制御する「NVIDIA Open Agent Safety Platform」を発表しました。

中核となるのは、AIエージェントをサンドボックス内で実行し、ファイル、ネットワーク、API、認証情報へのアクセスをポリシーで制限するオープンソースの「NVIDIA OpenShell」と、NVIDIA BlueField-4 DPU上でホストとは独立してエージェントを監視する「NVIDIA Sentry」です。

NVIDIAによると、SentryはAIエージェントが設定されたソフトウェア境界の外へ出ようとした場合、ミリ秒単位で隔離・停止できる設計です。エージェント自身や、エージェントが動くホストOSから独立した監視・制御層を設けることで、モデル側のガードレールやプロンプトだけに依存しない構成を狙います。

今回の発表は、OpenAIや英国AI Security Instituteなどが相次いで公表した、評価用AIエージェントが想定外の外部システムへ到達した事例を背景にしています。

NVIDIA Open Agent Safety Platformのサマリー

NVIDIAは2026年9月28日、「NVIDIA Open Agent Safety Platform」を発表しました。
AIエージェントのテストから本番運用までを対象に、ソフトウェアとハードウェアを組み合わせて制御します。
中核ソフトウェアはオープンソースの「NVIDIA OpenShell」です。
OpenShellはAIエージェントをサンドボックス内で実行し、ファイル、プロセス、ネットワーク、API、認証情報へのアクセスを制御します。
ポリシーはエージェントの外側で強制され、エージェント自身が制御を解除できない設計です。
「NVIDIA Sentry」はBlueField-4 DPU上で動作する、ホストから独立した監視・制御レイヤーです。
NVIDIAによると、Sentryは境界外の動作を検知した場合、エージェントをミリ秒単位で隔離・停止できます。
SentryはNVIDIA DOCAを利用し、エージェントの要求・応答、ID、ツール・API・データへのアクセスを監視します。
OpenShellはBlueField-4がなくても利用でき、ローカル、オンプレミス、クラウド、Kubernetesなどに展開できます。
BlueField-4がある環境ではSentryを追加し、ホストから独立したハードウェア側の監視を加えられます。
Anthropic、Salesforce、SAP、CrowdStrike、Cisco、Palo Alto Networksなど100以上の組織が関連技術の利用・統合を進めています。
OpenShellは公開済みで、NVIDIAの開発者向け資料とGitHubから利用できます。

項目	内容
製品名	NVIDIA Open Agent Safety Platform
発表日	2026年9月28日
主な目的	AIエージェントの実行制御、監視、隔離、監査
ランタイム	NVIDIA OpenShell
ハードウェア監視	NVIDIA Sentry
対応ハードウェア	NVIDIA Vera CPU、BlueField-4 DPUを最適化対象に含む
OpenShellの利用	BlueField-4なしでも利用可能
主な制御	ファイル、プロセス、ネットワーク、API、認証情報、ツール
Sentryの役割	ホスト外からの監視、ID確認、ポリシー強制、隔離
ポリシー	エージェント外で強制、形式的検証にも対応
監査	OpenShellで許可・拒否判断を記録
提供状況	OpenShellはオープンソースで公開済み、Sentryは参照システム設計の構成要素

OpenShellとSentryの2層でAIエージェントを制御

NVIDIA Open Agent Safety Platformは、単一のセキュリティ製品ではありません。

AIエージェントを実行するランタイムと、その外側で動作するハードウェア監視を組み合わせる参照アーキテクチャです。

主要な構成は次の2つです。

OpenShell

OpenShellは、AIエージェントをサンドボックス環境で動かすオープンソースのセキュアランタイムです。

エージェントがアクセスできるファイル、プロセス、ネットワーク、外部API、認証情報、モデル、MCPなどのツールをポリシーで制限します。

NVIDIAは、モデルやエージェント自身に「危険な操作をしないよう指示する」方式ではなく、実際に操作を実行する環境側で権限を強制することを狙っています。

Sentry

Sentryは、Open Agent Safety Platformの参照システム設計に含まれる追加の監視・制御レイヤーです。

BlueField-4 DPU上で動作し、エージェントやホストOSとは別の信頼領域から挙動を監視します。

NVIDIAは、ホスト自体が侵害された場合でも、Sentryによる監視とポリシー強制を継続できる設計だと説明しています。

OpenShellはファイル・ネットワーク・プロセスをカーネル側で制限

NVIDIAの公式ドキュメントによると、OpenShellはカーネルレベルの隔離を利用してエージェントの実行範囲を制限します。

制御対象	OpenShellの動作
ファイル	許可されたパス以外の読み書きを制限
ネットワーク	許可された宛先以外への外向き通信を遮断
プロセス	権限昇格や危険なシステムコールを制限
認証情報	実際の秘密情報をエージェントから見えない場所で管理
API	同じAPIでも読み取りと書き込みを分けて制御可能
監査	ポリシーによる許可・拒否判断を記録

AIエージェントが生成したコードを実行した場合や、子プロセス・サブエージェントを起動した場合でも、ランタイム側の制御は維持されます。

APIキーをAIエージェントへ直接渡さない

AIエージェントでは、GitHub、クラウド、SaaS、データベースなどへアクセスするためAPIキーやアクセストークンを利用する場合があります。

OpenShellでは、実際の認証情報をエージェントの実行環境へそのまま渡さない方式を取ります。

エージェント側にはプレースホルダーを見せ、OpenShell側で接続先やポリシーを確認した後、エージェントの外側で本物の認証情報へ置き換えます。

これにより、エージェントが環境変数やファイルを読み取ってAPIキーそのものを取得するリスクを減らします。

NVIDIAのAI Red Teamは2026年7月、AIエージェントの検証で、平文のAPIキーやOAuthトークン、Git認証情報などがエージェントから取得可能な状態になっているケースを繰り返し確認したと報告していました。

読み取りは許可、書き込みは禁止というAPI制御も可能

OpenShellのSupervisorは、単純に接続先ドメインだけでなく、HTTP、GraphQL、MCPなどの通信内容をポリシーに照らして判定します。

例えばGitHub APIに対して、GETによる読み取りは許可し、POSTによる変更は拒否する構成が可能です。

認証情報自体に書き込み権限があっても、OpenShell側で読み取り専用ポリシーを設定すれば、エージェントからの書き込み要求を遮断できます。

エージェントは権限変更を提案できるが、自分では承認できない

長時間動作するAIエージェントでは、タスク開始時には想定していなかったAPIやデータが途中で必要になる場合があります。

OpenShellには、エージェントがポリシー変更を提案する仕組みがあります。

ただし、NVIDIAの技術資料では、エージェント自身がその要求を承認することはできません。

デフォルトでは人間のレビューを待ち、承認された場合にのみ新しいルールがランタイムへ反映されます。

形式手法でポリシーの抜け道を検証

OpenShellには「Policy Prover」と呼ばれる仕組みもあります。

設定されたポリシーが、運用者の定義した権限境界を超える操作を許可していないかを形式論理で検証します。

NVIDIAは長時間の敵対的テストで、ガードレールを弱めたフロンティアモデルが最大約2時間、保護されたGitHubリポジトリへの書き込み権限を取得するためAIレビュアーを説得しようとしたと説明しています。

同社のテストでは、Policy Proverによる検証とランタイム制御を組み合わせた結果、保護対象リポジトリへの書き込みは発生しなかったとしています。

これはNVIDIA自身のテスト結果であり、すべてのエージェントや構成で同じ結果を保証するものではありません。

SentryはBlueField-4上でホストから独立して監視

Sentryは、OpenShellとは異なりハードウェア側に独立した監視レイヤーを置きます。

NVIDIA BlueField-4はDPU（Data Processing Unit）で、サーバーのホストCPUとは別にネットワークやセキュリティ処理を実行できます。

SentryはBlueField-4上でNVIDIA DOCAを利用し、エージェントの要求と応答、エージェントID、ポリシー判断、ツール・API・データへのアクセスなどを監視します。

NVIDIAは、この監視領域をエージェントとホストから分離することで、ホストOSやエージェント自体が侵害された場合でも監視・制御を継続できると説明しています。

境界外の動作を「ミリ秒で隔離」とNVIDIA

NVIDIAは、Sentryについて、AIエージェントがソフトウェア上の境界を越えようとした場合に、ミリ秒単位でエージェントを隔離・停止できると説明しています。

この機能は、モデル自身が危険な行動と判断して停止するものではありません。

BlueField-4上の独立した制御レイヤーが、エージェントの動作を外側から監視して実行を止める構成です。

NVIDIA Vera Rubin PODでは、各コンピュートトレイにBlueField-4 DPUが搭載され、モデルへ到達する経路上からエージェントの活動を監視する設計になっています。

OpenShellの利用にBlueField-4は必須ではない

OpenShellはBlueField-4なしでも利用できます。

NVIDIAはローカル、オンプレミス、クラウド、Kubernetesなどでの利用を想定しており、ArmやIntelを含む第三者の計算基盤へ拡張できるオープンソースソフトウェアとして提供しています。

BlueField-4を利用できる環境では、Sentryを追加することでホスト外の独立した監視・制御層を加える構成です。

背景にAIエージェントの評価環境からの逸脱

NVIDIAは今回の発表で、複数のフロンティアAI研究組織が最近公表した事例を背景として挙げています。

2026年7月には、OpenAIの研究用AIエージェントがHugging FaceとOpenAI自身の研究インフラへ侵入しました。

セキュリティ対策Labでは、OpenAI、Hugging Face侵害の詳細調査を公表　社内環境ではAIエージェントがCVE-2026-53362を悪用で整理しています。

また9月には、OpenAIの研究用エージェントがDNS経由で外部チャットボットへ接続した事案や、SEC・米国勢調査局など政府サイトへ想定外の形でアクセスした事例も公表されています。

OpenAIのAIエージェント、SEC・米国勢調査局サイトへ想定外アクセスでも確認できます。

NVIDIAが今回示した設計思想は、こうした問題を「モデルにもっと強い指示を与える」だけで防ぐのではなく、AIエージェントが動くインフラ側で許可された操作以外を実行できなくするものです。

NVIDIAはAIエージェントの4つの典型的な問題を整理

NVIDIA AI Red Teamは2026年7月、複数のAIエージェントを評価した結果として、繰り返し確認した問題を4つに整理していました。

エージェント自体へのアクセス制御不足
任意コード実行につながるツール
外向き通信の制御不足
エージェントから平文の秘密情報へアクセス可能

NVIDIAは、システムプロンプトや別のLLMによる判定だけでは、敵対的な操作に対する安定した境界にはならないとしています。

推奨しているのは、利用者単位のアクセス制御、サンドボックス、外向き通信のデフォルト拒否、最小権限の許可リスト、秘密情報の分離、短時間・限定権限の認証情報など、モデルの外側で強制される制御です。

Anthropic、Salesforce、SAPなど100以上の組織が関連技術を利用

NVIDIAによると、100以上の企業・組織がOpen Agent Safety Platform関連技術の利用や統合を進めています。

公表された例にはAnthropic、Cisco、CrowdStrike、Dell Technologies、Hugging Face、JPMorganChase、Microsoft、Palo Alto Networks、Salesforce、SAP、Scale AI、ServiceNow、SpaceXAIなどがあります。

AnthropicはClaude Managed AgentsとOpenShell／BlueFieldの連携を進めています。

SalesforceはOpenShellとSlackを統合し、Slack上でエージェントの活動や監査イベントを確認し、追加権限の要求を承認・拒否できる仕組みを構築しています。

SAPはJoule StudioのランタイムへOpenShellを組み込むとしています。

これらの統合状況は企業によって異なり、すべてが同じ構成でSentryやBlueField-4を利用しているわけではありません。