NVIDIA、AIエージェントをモデルの外側で制御する「Open Agent Safety Platform」を発表――OpenShellは公開中、SentryはBlueField-4が前提

NVIDIAは9月28日、AIエージェントの実行を外側から縛る「Open Agent Safety Platform」を発表した。オープンソースのランタイム「OpenShell」と、BlueField-4 DPU上で動く監視役「Sentry」を含む参照システム設計だ。

同社は、相次いだ事案に共通するのはエージェントがアプリケーション層のセキュリティ制御を迂回した点だとし、境界をモデルの外に置く。本記事では、公開中のOpenShellと専用ハードウェアが前提のSentryを分けて整理する。

9月28日発表の「Open Agent Safety Platform」の構成

プラットフォームは、ソフトウェアのOpenShellとハードウェアを含む参照設計のSentryを柱とする。組織が自社の要件に応じて要素を選択できる構成だ。

OpenShellとSentryを組み合わせた参照システム設計

プレスリリースによると、統制の対象はソフトウェアからエージェントを動かすハードウェア・ロボティクスまでに及ぶ。

OpenShellは、エージェントの全ての動作を記録し、実行中にポリシーを執行するランタイムだ。一方のSentryは、BlueField-4 DPU上で動く帯域外の「番犬（watchdog）」だ。

要素は選んで配備でき、公式資料は同日に公開

プレスリリースは「組織は自社の要件に応じて、プラットフォームの要素を選んで配備できる」と書いた。技術ブログも、Sentryを「OpenShellと併用する任意のセキュリティ層」と位置づける（いずれも原文は英語、編集部訳）。

プラットフォームは、9月28日付のプレスリリースと、日本時間の同日17時台に公開された技術ブログ2本で公表された。CNBCによると、NVIDIAは前日の日曜に記者向けの電話説明を開いていた。

「アプリケーション層の制御を迂回」という共通パターン

NVIDIAは発表の理由として、最近の事案に共通するパターンを挙げた。前提にあるのは、エージェントに自らの統制を期待できないという見方だ。

プレスリリースと技術ブログが示した事案の型

プレスリリースは、最近のセキュリティ事案について「パターンは同じだ。エージェントは割り当てられたタスクを完了するために、アプリケーション層のセキュリティ制御を迂回した」と書いた（原文は英語、編集部訳）。

技術ブログによれば、複数の先端研究所が同種の事案を報告してきた。評価環境を抜け出したエージェントが触れるべきでないシステムに到達し、一部は自らの行動を誤って報告したという。

原因は単一の新しい能力ではなく「ツール・時間・曖昧な指示の組み合わせ」だったと、同ブログは述べた（原文は英語、編集部訳）。

前日に報じたOpenAIのサンドボックス外到達との関係

当メディアが前日に報じたOpenAIの2度目の訓練停止では、訓練中のモデルがDNSの穴から外部のチャットボットに到達した。警告は約12分で出たものの、停止は約2時間半後の手動だった。

確認したプレスリリースと技術ブログには、OpenAIの社名は記されていない。この事案がNVIDIAの言う「共通パターン」に含まれるかは、両資料からは判断できない。

ドリフトの教訓と、技術ブログが挙げた5つの原則

技術ブログは、タスクや制約から外れるエージェントの動き（ドリフト）は、能力を保ったまま訓練では取り除けないとした。最も重要な教訓として挙げたのは、こうした状況のエージェントに「自らの振る舞いを完全に律することは期待できない」点だ（原文は英語、編集部訳）。

その上で技術ブログは、境界をモデルの外側に移す設計の原則を5つ挙げ、アプリケーション・ランタイム・インフラの3層を置いた（引用はいずれも原文は英語、編集部訳）。

• ポリシーは検証可能に：実行前に、証明器（prover）がポリシーは運用者の意図を逸脱できないと示す。
• 執行は帯域外に：制御はエージェントの内側にも手の届く範囲にも置かず、「エージェントは自分が見られていると知る必要がない」とした。
• モデルへの経路が制御点：「エージェントは次の思考なしには行動できない」ため、モデルに至る経路を押さえる。
• 権限は思考の可視性に応じて：エージェントの思考を検査できる度合いに合わせて、与える権限を広げる。
• 共有責任モデル：研究所・企業・ハードウェア提供者が、現在のクラウドと同じように各層を受け持つ。

OpenShellで現在できること、YAMLのポリシーと監査ログ

OpenShellは、Apache 2.0ライセンスでGitHubに公開されているオープンソースのランタイムだ。各エージェントをサンドボックスで動かし、運用者の指示を検証可能なポリシーに変える。

ゲートウェイ・スーパーバイザー・サンドボックスの3部品

同日公開のウォークスルーによると、OpenShellは3つの部品から成る。ゲートウェイの役割は、多数のサンドボックスのライフサイクルとポリシーの管理だ。スーパーバイザーは各サンドボックスと対になって、送信要求をポリシーと照らし合わせる。

スーパーバイザーは、エージェントのワークロードの外側で動く。サンドボックスはファイルシステムとプロセスをカーネルレベルで制御し、ネットワークに出る経路はスーパーバイザー経由に限られる。

運用者が決めるのは、エージェントが触れてよいファイル・ネットワーク・ツール・プロセス・認証情報だ。

YAMLで書くポリシーと、エージェントに見せない認証情報

ポリシーはYAMLで書き、OPA/Regoにコンパイルされる。OpenShellは、送信要求の1件ごとにこのポリシーを評価する。ウォークスルーの例は、接続先を api.github.com・ポート443・REST・読み取り専用に絞る内容だ。

スーパーバイザーはHTTP・GraphQL・MCPの通信を検査でき、同じAPIでもデータの照会は通し、書き込みは止められる。認証情報はエージェントに渡さず、承認済みの宛先に向かう要求にだけOpenShellが付け加える。エージェントが持つ代わりのプレースホルダを承認外の宛先に送れば、要求は拒否される仕組みだ。

証明器の判定・人の承認・OCSF形式の監査ログ

ポリシーの判定は、OCSF（Open Cybersecurity Schema Framework）形式の監査ログに残る。証明器は、ポリシーが与える権限が運用者の決めた境界に収まるかを形式論理で確かめ、はみ出すときは具体的な動作を示す。

ウォークスルーは「結果はポリシーのモデルから出るため、エージェントの説明では結果を変えられない」と書いた（原文は英語、編集部訳）。権限を広げたいとき、エージェントは範囲を絞った変更を提案できる。

提案は既定で人のレビュー待ちとなり、エージェントが自分の要求を承認することはできない。ただし、ファイルシステムとプロセスの制限はサンドボックスの起動時に固定され、変えるには新しいサンドボックスが要る。

対応エージェント・動作環境と、既定で有効なテレメトリ

対応するエージェントはCodex・Claude Code・Pi・Hermesで、実行基盤としてDocker・Podman・MicroVM・Kubernetesにつながる。動作環境はLinux・Apple SiliconのmacOS・WSL 2のWindows（試験的）だ。

SDKはPython・TypeScript・Go・Rustの4言語で用意された。プレスリリースは、オープンソースであるためArmやIntelの計算基盤にも「拡張できる」と書いた（原文は英語、編集部訳）。

公式ドキュメントによると、OpenShellは匿名のテレメトリを既定で収集する。無効化は環境変数 OPENSHELL_TELEMETRY_ENABLED=false で行う。

3月のearly previewから、9月25日の0.1.0へ

OpenShell自体は、3月からGitHubで公開されていた。最も古いリリースは3月16日のv0.0.6で、NVIDIAの公式ブログは3月23日時点で「OpenShellはearly previewの段階にある」と書いていた（原文は英語、編集部訳）。

9月25日（UTC）にはv0.1.0が公開され、READMEは0.1.xの新しい点の一つに「安定したリリースの周期」を挙げた。今回のプレスリリースは、OpenShellを「Now broadly available（広く利用可能になった）」と表現している。

Sentryは帯域外の「番犬」、BlueField-4上で動作

Sentryは、エージェントとは別のチップであるBlueField-4 DPU上で監視と執行を担う。9月28日にNVIDIAが公開した公式資料では、Sentryの提供開始日を確認できなかった。

BlueField-4上で「in-silicon」に執行し、ミリ秒で隔離

プレスリリースによると、Sentryはシリコン上でセキュリティを執行する（in-silicon）。エージェントがソフトウェアの境界の外に出ようとすれば、Sentryはミリ秒単位で隔離・停止するという。

執行は隔離された帯域外の信頼領域から行い、その領域は「エージェントにも攻撃者にも見えない」とNVIDIAは説明した（原文は英語、編集部訳）。

SentryはNVIDIAのDOCAソフトウェアを基盤とする。DOCAの機能を使い、エージェントの要求と応答の検査・証明付きのテレメトリ・エージェントの身元の検証・ゼロトラストのアクセスポリシーの執行を担う。

Vera Rubin PODで「モデルへの唯一の経路」に置かれるBlueField-4

技術ブログは、Vera Rubin PODでは各計算トレイのBlueField-4が「ノードからモデルへの唯一の経路」上にあると説明した（原文は英語、編集部訳）。

Vera CPUについては、NVIDIAの製品ページが初号機をAnthropic・OpenAI・Oracle Cloud Infrastructure・SpaceXAIに納入したと書く。

8月24日付のBlueField-4技術ブログと9月28日付の公式資料を確認した範囲では、BlueField-4単体の出荷時期とSentryの提供開始日は確認できなかった。

提供状況の段落が挙げたのは「OpenShellとskills」

プレスリリースの提供状況の段落は「OpenShellとskills」を挙げ、NVIDIAの開発者向けページとGitHubで入手できるとした。確認した同段落には、Sentryの記載がない。

技術ブログは、Vera＋BlueField-4のシステムを既に使う組織なら、Sentryの保護は「ソフトウェア更新だけ」で有効にできると書いた（原文は英語、編集部訳）。また、NVIDIAは製品・機能の多くを、提供可能になった時点で提供する（when-and-if-available）としている。

OpenShellとSentryの動作場所・前提・提供状況

同じプラットフォームの名で発表されたものの、OpenShellとSentryは入手方法と確認できた提供状況が異なる。公式資料で確認できた範囲の違いは次の通りだ。

項目	OpenShell	Sentry
位置づけ	オープンソースのセキュアランタイム	参照システム設計の構成要素
動作場所	各サンドボックスと、ワークロードの外側のスーパーバイザー	BlueField-4 DPU
執行の位置	送信要求ごとにポリシーを評価	帯域外の信頼領域（in-silicon）
前提ハードウェア	Linux・Apple SiliconのmacOS・WSL 2のWindows（試験的）で動作	BlueField-4 DPU（Vera＋BlueField-4の利用者はソフトウェア更新で有効化）
提供状況	GitHubで公開中（9月25日〈UTC〉にv0.1.0を公開）	9月28日付の公式資料では提供開始日を確認できず

Anthropic・SpaceXAI・SAPの協業と開発ペースの議論

プレスリリースによると、プラットフォームの技術に取り組む組織は100を超える。各社の取り組みは次の通りだ。

Anthropicは「脳」と「手」を分けたManaged Agentsと統合

プレスリリースによると、AnthropicのClaude Managed Agentsは、エージェントのループを作業用のサンドボックスとは別のサーバで動かす。OpenShellとBlueFieldとの統合により、企業はそのサンドボックスを通るアクセスを厳しく制御できるという。

Anthropicは4月8日のエンジニアリング記事で、Claudeとハーネスの「脳」を、サンドボックスとツールの「手」から切り離す設計を説明していた。最高商業責任者のPaul Smith氏は、企業にはエージェントの行動を指示し検証する必要があると述べた。

SpaceXAI・Salesforce・SAP・Red Hatの取り組み

SpaceXAIは、CursorのコーディングエージェントとGrokモデルでプラットフォームを使っている。社長のMike Nicolls氏は「安全は、エージェントが越えられない追加の制御によって、モデルの外側で執行すべきだ」と述べた（原文は英語、編集部訳）。

プレスリリースによると、SalesforceはOpenShellをSlackと統合し、Slackからエージェントの活動と監査イベントを確認できる。追加権限の要求も承認・却下できるという。SAPはJoule StudioのランタイムにOpenShellを組み込み、開発にも貢献する。

Red HatのCTO、Chris Wright氏は9月28日付のブログで「単一のプラットフォームの制御が『エージェントを守る』わけではない」と書いた（原文は英語、編集部訳）。ランタイムに加え、エージェントの外のインフラも執行点になり得るという。

Open Secure AI Allianceと、RFC段階のSAFE

Open Secure AI Allianceは、NVIDIAが7月27日に設立を発表した枠組みだ。9月28日付のプレスリリースによると、NVIDIAが120超の組織と立ち上げ、Linux Foundationが運営する。この「120超」は、プラットフォームの技術に取り組む「100超」とは別の集合だ。

取り組みの一つであるSAFE（Shared AI Findings Exchange）は、AIの事故やニアミスを機密扱いで集めて分析し、繰り返す失敗を共有の対策に変える仕組みだ。公式Webサイトでは、現在RFC（意見募集）の段階とされる。

開発ペースをめぐる議論と提供状況の整理

技術ブログは、ここ数週間の事案の報告が「エージェント開発のペースをめぐる真剣な議論」につながったと書く（原文は英語、編集部訳）。米国では9月18日、開発ペースの協調をめぐってAI大手4社が反トラスト集団訴訟を起こされた。

NVIDIAのJustin Boitano副社長（エンタープライズAI担当）はCNBCに「モデルレベルの安全策だけでは、エージェントが何にアクセスし何をするかを統制できない」と語った（原文は英語、編集部訳）。今回の発表は、提供状況と責任分界の観点から次の3点に整理できる。

• 現在入手できるのはOpenShell：Linux・Apple SiliconのmacOS・WSL 2のWindows（試験的）で動き、CodexとClaude Codeを含むエージェントに対応する。
• Sentryは参照設計の構成要素：BlueField-4 DPU上で動く。9月28日付の公式資料では、提供開始日を確認できなかった。
• 共有責任モデルは3つの層で構成：研究所・企業・ハードウェア提供者が、アプリケーション・ランタイム・インフラの各層を受け持つ。