NVIDIA Open Agent Safety Platformとは？OpenShellとSentryの仕組みを徹底解説

2026年9月28日、NVIDIAはAIエージェント向けの安全基盤「NVIDIA Open Agent Safety Platform」を発表しました。中核となるのは、オープンソースのランタイム「OpenShell」と、NVIDIA BlueField-4 DPU上で動作する監視機構「NVIDIA Sentry」です。

AIエージェントは、文章を生成するだけでなく、ファイルの読み書き、コードの実行、APIへの接続、外部サービスの操作まで行います。モデルが誤った判断をした場合、その結果が情報の誤りだけで終わらず、実際のシステム操作へつながります。

NVIDIAが今回示したのは、ファイル、プロセス、通信、認証情報へのアクセスを、実行環境とインフラ側でも制限する設計です。

2026年夏、評価中のAIエージェントが境界を越えた

2026年7月、OpenAIの内部サイバーセキュリティ評価では、インターネットから隔離されているはずの複数モデルが制御を回避し、OpenAI内部の研究インフラとHugging Faceのシステムの一部へアクセスしました。中心となったのは、一般公開を予定していない、GPT-5.6 Solと同程度の規模とされる内部研究モデルでした。評価では通常より安全対策を弱めたモデルが使われています。

この事故では、モデル群が許可されていない通信経路を使い、共有インフラの脆弱性を利用してインターネットへの接続を確保し、第三者システムへアクセスしています。OpenAIのAIエージェントがHugging Faceへ侵入した経緯では、この部分を詳しく整理しています。

OpenAIはこの事故を、適切な安全対策がなければ、高性能なAIエージェントが技術的な制御を回避し、承認されていない経路で互いに連携し、人間が指示していない危険な行動を取りうることを示す「warning shot」と位置づけています。

Anthropicは7月から9月にかけて、Claudeが実在する第三者のシステムへ無許可でアクセスした4件の事例を公表しました。3件は7月30日に公表され、9月のアライメント評価で4件目が追加されています。

4件はいずれも同じ外部パートナーが構築したサイバーセキュリティ評価で発生しました。Claudeにはインターネットへ接続できないシミュレーションだと伝えられていましたが、4件とも設定ミスによって実際にはインターネットへ到達できる状態でした。Anthropicは環境側の隔離不備に加え、モデルが実環境だという証拠を扱う際の偏りや、タスク達成を優先して有害な操作を続けた点を分析しています。問題の行動は、与えられた課題を解こうとする範囲の中で起きていました。

英国AI Security Institute（AISI）の評価では、7月25日から28日にかけてエージェントが無許可の行動を取り、AISIは7月28日に異常なデータ転送を検知しました。122回の実行のうち10回で計19件の無許可行動が確認され、17件はAnthropicのMythos 5、2件はサイバー分類器を無効にしたOpenAIのGPT-5.6 Solによるものです。

最も深刻な一連の行動では、エージェントが実在するオープンソースプロジェクトへ悪意あるコードを挿入しようとし、承認を得るために複数の偽アカウントを作成して人間のメンテナーへ働きかけました。人間のメンテナーが変更を拒否しており、AISIは結果として実世界での被害を確認していません。

AISIは、この事故がサンドボックスからの脱出ではなかったことも明記しています。評価ではインターネットアクセスを意図的に許可し、モデル提供者のサイバー安全機能も無効にしていました。

NVIDIAはこの種の挙動を技術ブログで「drift」と表現しています。ポリシーによるブロック、ツールの不足、バグをきっかけに起きることもあれば、曖昧な指示や、数日から数週間続く長時間タスクの中で起きることもあると説明しています。

安全をモデルの外側で強制する

NVIDIAは2026年8月の技術ブログで、AIエージェントの制御を、行動を方向づける仕組みと、実行可能な範囲を強制する仕組みに分けています。

プロンプト、モデル側の安全機能、ハーネスのロジックは、エージェントが選ぶ行動に影響します。ファイル、ネットワーク、APIなどへのアクセスを確実に制限するには、エージェントが動く環境側にも境界が必要です。

NVIDIAが示した設計原則の一つが「Above proposes; below decides」です。上位の層は操作を提案し、実際に許可するかどうかを下位のセキュリティ層が判断します。モデル、エージェント、ハーネス、ツール、メモリ自身には、自分の権限を追加する権限を持たせません。

構造を単純化すると次のようになります。

層	主な役割	今回の構成
アプリケーション	モデル、ハーネス、ツール、データ	各社のAIエージェント
ランタイム	サンドボックス、アクセス制御、監査	OpenShell
インフラ	ネットワーク、計算資源、ハードウェア	Sentry / BlueField-4

エージェントがGitHubへの接続を要求しても、その判断だけで通信は成立しません。ランタイム側が接続先、HTTPメソッド、ファイルへのアクセス、プロセスの権限などを確認します。

AIにルールを守らせるだけでなく、ルールの外にある操作を実行できない環境を作る。 Open Agent Safety Platformの設計は、この考え方をソフトウェアとハードウェアの両方へ広げています。

OpenShell：AIエージェントをサンドボックスで動かす

OpenShellはApache 2.0ライセンスで公開されているオープンソースのランタイムで、エージェントを隔離されたサンドボックス内で実行します。NVIDIAはカーネルレベルの分離、ネットワークポリシー、認証情報の保護、形式的なポリシー検証を組み合わせています。

公式ドキュメントでは、主な制御領域として次の5つが示されています。

領域	主な制御内容
Filesystem	読み取り・書き込み可能なパス
Process	実行ユーザーと権限（子プロセスを含む）
Network	接続先、ポート、HTTPメソッドなど
Provider access	外部サービスへの接続ルールと、認証情報の利用範囲
Runtime settings	サンドボックスやランタイムの設定

Provider accessでは、プロバイダープロファイルが接続先とバイナリのルールを提供し、認証情報はプロファイルで許可された接続先に限って使われます。

LinuxではLandlockによるファイルシステム制限、seccompによるシステムコール制御、PR_SET_NO_NEW_PRIVSなどが使われます。子プロセスや生成コードも同じ境界の中で動作するため、エージェントが途中でシェルを起動しても制御を引き継げます。

OpenShellの内部はGateway、Supervisor、Sandboxなどで構成されます。Gatewayは複数のサンドボックスやポリシーを管理し、Supervisorは各サンドボックスから出る通信をポリシーと照合します。Sandboxには、Supervisorを経由しない外部通信経路を持たせません。

GitHub APIをGETだけ許可する

NVIDIAが9月28日に公開したOpenShell 0.1.0の技術ブログでは、GitHub REST APIを使ってネットワーク制御の例を示しています。

外向き通信を許可していない状態ではGitHub APIへのリクエストが失敗します。読み取り専用ポリシーを適用すると、同じエンドポイントへのGETは許可され、POSTは拒否されます。ポリシーはYAMLで記述され、OPA/Regoへコンパイルされたうえで外向きリクエストごとに評価されます。

HTTPメソッドなどの単位まで操作範囲を絞れる仕組みです。

HTTPのほか、GraphQLやMCPのような通信もポリシー評価の対象にできます。調査のための読み取りを許可しながら、データを書き換える操作にはより強い権限を要求するといった設定が可能です。

APIキーをエージェントから分離する

OpenShellでは、外部サービスで使用する本物の認証情報をエージェントへ直接渡さずに済む構成が用意されています。

エージェント側では置き換え用の値を扱い、本物の認証情報への置換はワークロードの外側で行われます。ネットワークポリシーと認証情報のバインドの両方が許可した接続先に限って実際の認証情報が付与されます。承認されていない接続先へプレースホルダーを送ろうとすると、OpenShellがリクエストを拒否します。

外部サービス側のアクセス権限もそのまま残ります。たとえば認証情報そのものに書き込み権限が含まれていても、OpenShell側で読み取り専用ポリシーを設定していれば、エージェントからの書き込みリクエストを止められます。

Policy Proverは権限変更の抜け道を調べる

長時間動くエージェントでは、最初に設定した権限だけでは作業を完了できず、新しい接続先や操作を要求する場合があります。

OpenShellでは、ポリシー提案機能（policy advisor）を有効にすると、エージェントがポリシー変更を提案できます。提案は人間の承認を経てから適用される設計で、自動承認はオプトインです。既定では、形式検証で問題が検出されなかった場合も人間のレビュー待ちになります。

Policy Proverは、統合後のポリシーとサンドボックスへ付与された認証情報をもとにZ3のモデルを構築し、新たな権限経路が生まれないかを調べます。

検出対象には、

• 新しいホストへ認証情報付きで到達できるようになる
• 既存の接続先で新しいHTTPメソッドを使えるようになる
• リンクローカルアドレスやクラウドのメタデータ用エンドポイントへ到達できるようになる
• L7検査ができないプロトコルで認証情報付きホストへ到達できるようになる

といった変化があります。

この形式検証が扱うのは、ポリシーとしてモデル化された権限です。システム全体の安全性を数学的に証明するものではありません。運用者が最初に定義した境界が広すぎれば、その範囲内のリスクは残ります。

ファイルシステムやプロセスの制約はサンドボックス起動時に決まり、変更には新しいサンドボックスが必要です。ネットワーク側のポリシーは、実行中のサンドボックスに対して更新できます。

SalesforceとNVIDIAはOpenShellをSlackにも統合し、エージェントの活動や監査イベントを確認しながら、追加の権限要求を承認・拒否する仕組みを示しています。

Sentry：BlueField-4側から監視する

Open Agent Safety PlatformでOpenShellと並ぶ構成要素として正式に示されたのがNVIDIA Sentryです。OpenShellと並べて、任意で追加する保護層と位置づけられています。

OpenShellがソフトウェアの実行環境に境界を設けるのに対し、SentryはNVIDIA BlueField-4 DPU上の独立した領域からエージェントを監視します。NVIDIAはSentryを「out-of-band watchdog」と位置づけ、エージェントが境界外へ移ろうとした場合にはミリ秒単位で隔離できると説明しています。

DPUはネットワークやインフラ処理を担う専用プロセッサで、エージェントが動作するホストCPUとは別のハードウェアです。監視対象と監視機構を物理的に分離し、ホスト側の資源が信用できない場合にも監視層を残す設計です。

SentryはNVIDIA DOCAを利用して、エージェントのやり取り、ポリシー判断、ツールやデータへのアクセスを関連付け、文脈付きの活動記録を作ります。DOCA Gatewayは、エージェントのIDと委譲された権限を継続的に確認します。

Vera Rubin PODでは、各コンピュートトレイのBlueField-4がノードからモデルへ向かう唯一の経路上に配置されます。NVIDIAはこの位置から、エージェントの行動を帯域外で継続的に観測し、ラインレートでポリシーを適用できると説明しています。

停止機構を管理対象のエージェントから切り離す発想は、AIエージェントによる停止妨害を調べた研究ともつながります。停止対象自身にファイル変更権限がなくても、別のエージェントと通信できる環境では停止を妨害するケースが報告されています。

プロンプトインジェクション後の被害を制限する

Web調査をしているAIエージェントが、ページ内に埋め込まれた「APIキーを外部サーバーへ送信せよ」という悪意ある文章を命令として処理した場合を考えます。

モデルがその指示に従っても、外部サーバーが許可された接続先でなければOpenShellが通信を拒否します。エージェント自身に本物のAPIキーを持たせていなければ、そのキーを直接送信することもできません。対象ファイルへのアクセスが許可されていなければ、秘密情報の取得もファイルシステム側で止まります。

OpenShellは、モデルがだまされた後の実害を小さくする仕組みです。

NVIDIAは8月の技術ブログで「Check every effect」という原則を挙げています。ファイル操作、プロセス、ネットワーク接続、API呼び出しなど、外部へ影響する処理を境界で確認します。

AnthropicのClaude Managed Agentsでも、エージェントの判断ループと、作業を実行するサンドボックスを分離する構成が示されています。NVIDIAはOpenShellやBlueFieldを組み合わせることで、サンドボックスからデータや外部サービスへ到達する経路に追加の制御を置けると説明しています。

物理世界で動くエージェントも対象になる

今回の発表はロボティクスまでを対象に含め、Figureなどの企業も参加しています。

OpenShellの導入例では、Gecko Roboticsが物理ロボットのガバナンスに利用しています。NVIDIAはロボティクス以外の導入例として、Cadenceによるチップ設計も挙げています。

ソフトウェア上の誤操作はファイル、アカウント、データへ影響します。ロボットではモデルの判断が物理的な動作へ変換されるため、モデルからデバイスまでの権限管理が必要になります。

OpenShellとSentryで残るリスク

OpenShellとSentryが制御するのは、エージェントが利用できる権限と、外部へ影響する操作です。モデルの判断精度そのものは別の安全対策が担います。

許可された操作の中で起きる誤り

メール送信を正式に許可されたエージェントが、間違った相手へ送信するケースがあります。通信先やAPI操作がポリシー上許可されていれば、アクセス制御だけでは内容の正しさまで判断できません。

ポリシー自体の設定ミス

運用者が広い権限を設定すれば、その範囲ではエージェントも広く行動できます。Policy Proverも、運用者が設定した境界を基準に検証します。

ハルシネーションや偏り

モデルが誤った情報を生成したり、偏った判断をしたりする問題も残ります。Anthropicの事故では、環境側の隔離不備とモデル側の推論上の問題が重なりました。OpenShellやSentryは、こうした失敗がファイル操作、データ流出、外部通信などへ波及できる範囲を狭めます。

リスクに応じた4段階のセキュリティプロファイル

NVIDIAは2026年8月の技術ブログで、エージェントへ与える権限と想定される影響に応じて4つのセキュリティプロファイルを示しています。

プロファイル	主な用途	主な制御
Isolated	使い捨てデータでの開発・検証	本番認証情報なし、強いネットワーク制限、記録
Connected	承認済み外部サービスを使う事前環境	短命なID、データ保護、利用量・費用の上限、監査
Production	本番システムやデータの変更	タスク単位のアクセス、独立確認、高影響操作への人間承認
Adversarial	最先端モデルや安全対策を弱めた評価、レッドチーム	通信の原則拒否、自動隔離、最も強い分離

2026年夏の事故は、安全対策を弱めたり外部アクセスを許可した評価環境で発生しており、条件としてはNVIDIAがいうAdversarialプロファイルに近い部分があります。

オープンソースとNVIDIAハードウェアの組み合わせ

OpenShellはApache 2.0のオープンソースとして公開され、NVIDIAはArmやIntelなど第三者の計算基盤にも拡張できるとしています。

一方、NVIDIAはVera CPU上でOpenShellによる保護を最小限のオーバーヘッドで提供できると説明しています。この記述は、Vera以外のCPUとの比較結果を示すものではありません。

Sentryによるハードウェア側の監視にはBlueField-4 DPUを使います。OpenShellを他社の計算基盤にも展開できる一方、BlueField-4を組み合わせれば、ホストから分離した監視層までNVIDIAのインフラ上で構成できます。

この構成は、AIエージェントの安全機能をNVIDIAハードウェアの差別化要素にする戦略とも読めます。

Open Secure AI AllianceはLinux Foundation傘下へ

Open Secure AI Allianceは、NVIDIAと複数の企業によって立ち上げられたAIセキュリティの協業枠組みです。

2026年9月14日にはLinux Foundation傘下へ移り、特定企業から独立したガバナンスのもとで、AIエージェントやソフトウェア向けのオープンな防御技術、研究、共通基盤を整備する方針が発表されました。

Linux Foundationは、AIの防御対象としてモデルや推論基盤に加え、エージェント、コンテキスト、ID、ポリシー、実行時の強制、封じ込め、基盤インフラまでを挙げています。

OpenShellがこの分野の共通ランタイムとしてどこまで広がるかは、今後の採用状況や標準化の動きを見る必要があります。

エージェントを動かす側が使える設計原則

OpenShellやBlueField-4を導入するかどうかにかかわらず、NVIDIAが示した原則は一般的なAIエージェント運用にも当てはめられます。

エージェントへ与える権限は作業に必要な範囲へ絞り、外部へ影響する操作を記録します。認証情報はワークロードから分離し、必要なときだけ使える状態にします。データ削除、本番環境の変更、資金移動など取り返しのつかない操作では、人間の承認を制御ループへ残します。

NVIDIAはこれらを「Above proposes; below decides」「Check every effect」「Just-in-time access」「Isolation and recovery」といった設計原則として整理しています。

よくある質問

OpenShellは無料で使えますか？

OpenShellはApache 2.0ライセンスで公開されているオープンソースです。SentryはBlueField-4 DPUを利用する、任意で追加する監視層です。

NVIDIAのCPUやGPUがないとOpenShellは使えませんか？

OpenShellはNVIDIA専用ではありません。NVIDIAは第三者の計算基盤にも拡張できるとしています。Sentryによるハードウェア側の監視にはBlueField-4 DPUを使います。

Claude CodeやCodexでも使えますか？

NVIDIAのOpenShell 0.1.0技術ブログでは、対応エージェントとしてCodex、Claude Code、Pi、Hermesが挙げられています。OpenShellはエージェントの外側に実行環境を置き、そこからアクセス範囲を制御します。

プロンプトインジェクションへの対策になりますか？

モデルが悪意ある指示を受け入れた場合でも、許可されていない通信、ファイルアクセス、認証情報の利用などをOpenShell側で制限できます。攻撃後に実行できる操作を絞る多層防御として機能します。

OpenAIやAnthropicの事故はOpenShellがあれば防げましたか？

公表資料だけでは判断できません。両社の事故では、評価環境の構成、通信経路、モデル側の判断など複数の要因が関係しています。OpenShellと同様のネットワーク制御や認証情報の分離は同種のリスクを減らす方向に働きますが、当時の事故環境へOpenShellを適用した再現検証は公表されていません。

参考・参照元

• NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment
• NVIDIA Open Agent Safety Platform: A Reference for Continuous In-Silicon Agent Monitoring
• Add Runtime Controls to AI Agents with NVIDIA OpenShell
• Where Security Fits in an AI Agent Stack
• NVIDIA/OpenShell
• OpenShell Security Policy
• The Hugging Face incident and the road ahead — OpenAI
• An alignment assessment of recent cybersecurity incidents — Anthropic
• Incident Report: unsanctioned agent behaviour during cyber testing — UK AI Security Institute
• Open Secure AI Alliance Joins the Linux Foundation