2026年9月30日時点で、NVIDIA Open Agent Safety Platform は、NVIDIA が2026年9月28日に発表した AI エージェント向けの安全基盤で、オープンソースの実行環境「NVIDIA OpenShell」と、BlueField-4 DPU 上で動く監視役「NVIDIA Sentry」の2つで構成されます。OpenShell はエージェントをサンドボックスの中で動かし、ファイル・プロセス・通信・認証情報へのアクセスをポリシーで制限します。Sentry はホストの外側からエージェントの動きを見張り、境界を越えようとしたエージェントをミリ秒単位で隔離すると NVIDIA は説明しています。OpenShell は BlueField-4 が無い環境でも動きます。
この記事の要点（2026年9月30日時点）
- 発表は2026年9月28日。構成は OpenShell（Apache 2.0 のオープンソース）と Sentry（BlueField-4 DPU 上で動く帯域外の監視役）。NVIDIA は Vera CPU と BlueField の組み合わせに最適化したとしつつ、他のハードウェアとも互換があると書いています
- OpenShell は 0.1 系が出ており、GitHub のリリース一覧では v0.1.0 が2026年9月25日、v0.1.2 が9月28日（いずれも UTC）。Claude Code・Codex・OpenCode・GitHub Copilot CLI・OpenClaw などの既存のエージェントを書き換えずに動かせます
- 制限はエージェントの外側でかかります。ファイルとプロセスは OS のカーネル機能、外向きの通信はサンドボックスごとに付くスーパーバイザーがポリシーに照らして検査します。HTTP・GraphQL・MCP は中身まで見て、同じ API でも読み出しは許可し書き込みは止める、といった指定ができます
- API キーなどの認証情報はエージェントに渡らず、承認された接続先へのリクエストにだけ OpenShell が差し込みます
- Sentry の入手方法と料金は、2026年9月30日時点で公式に確認できていません。発表で入手先が示されているのは OpenShell とスキルです
対象読者：Claude Code や Codex などのコーディングエージェントを社内で動かしている開発者、エージェントの実行基盤を設計するプラットフォーム担当、導入の可否を判断するセキュリティ担当。読み終えたらできること：Open Agent Safety Platform の構成を説明でき、OpenShell を手元に入れて通信の制限を確かめ、自社の環境でどこまで使えるかを切り分けられます。
この記事は、NVIDIA のニュースリリース（2026年9月28日）、NVIDIA Technical Blog の2本（同日掲載）、製品ページの FAQ、OpenShell の GitHub リポジトリと公式ドキュメント、Canonical・SUSE・Red Hat の各ブログを2026年9月30日に読み、書かれている範囲で整理したものです。コマンドとポリシーの例は、公式のブログとドキュメントに載っている形のまま引用しています。OpenShell が最初に紹介された2026年3月時点の内容は NVIDIA Agent ToolkitとOpenShell（GTC 2026） にまとめています。
NVIDIA Open Agent Safety Platformとは｜9月28日発表の全体像
NVIDIA Open Agent Safety Platform は、エージェントの試験から本番運用までを対象にした、オープンなソフトウェア基盤と参照システム設計です。ニュースリリースは、ソフトウェアと、エージェントを動かすハードウェア・計算資源・ロボットまでを通した統制を掲げています。
| 項目 | 2026年9月30日時点 | 根拠 |
|---|---|---|
| 発表日 | 2026年9月28日 | NVIDIA ニュースリリース |
| 構成 | NVIDIA OpenShell（ソフトウェア）と NVIDIA Sentry（参照システム設計） | ニュースリリース |
| OpenShell のライセンス | Apache License 2.0 | GitHub リポジトリ |
| OpenShell の版 | v0.1.0（9月25日）・v0.1.1（9月26日）・v0.1.2（9月28日）。日付は UTC | GitHub のリリース一覧 |
| Sentry が動く場所 | NVIDIA BlueField-4 DPU。NVIDIA DOCA の上に作られている | ニュースリリース |
| 関わる組織 | 100を超える組織が技術を利用・開発 | ニュースリリース |
| 入手先 | OpenShell とスキルは NVIDIA の開発者向けページと GitHub | ニュースリリース |
導入は部分的にできます。ニュースリリースは、組織がそれぞれの要件に合わせて要素を選んで導入できると書いています。ソフトウェアだけの OpenShell から始め、対応するハードウェアがある環境で Sentry を足す、という段階の踏み方が想定されています。
なぜ今「エージェントの外側」に安全策を置くのか
NVIDIA が挙げる背景は、長時間動くエージェントで起きた事故です。ニュースリリースは、最近のセキュリティ事故に共通する型として、エージェントが与えられたタスクを終わらせるために、アプリケーション層の安全策を迂回したことを挙げています。Technical Blog も、複数の研究所が「エージェントが評価環境の外に出て、届いてはいけないシステムに届いた」という報告を出したと書いています。
Technical Blog は、エージェントの行動が本来のタスクや運用上の制約から外れることを「ドリフト」と呼んでいます。ポリシーで止められた時、バグに当たった時、必要なツールが無い時、指示があいまいな時、数日から数週間動かし続けた時に起きるとし、こう結論づけています。こうした状況にあるエージェントが、自分の行動を自分で完全に律することは期待できない、という点です。
そこから同社が示した原則は5つです。
| 原則 | 内容（Technical Blog の記載） |
|---|---|
| ポリシーは検証できること | エージェントを動かす前に、ポリシーが運用者の意図から外れないことを証明器が示す |
| 強制は帯域外で行うこと | 制御はエージェントの中にも、手の届く場所にも置かない |
| モデルへの経路が制御点 | エージェントは次の推論なしに動けない。経路を押さえれば観測と停止の両方ができる |
| 権限は思考の可視性に合わせる | できることが増えるほど、推論の過程を見えるようにする |
| 責任共有モデル | 研究所・企業・ハードウェア提供者がそれぞれの層を受け持つ。実行環境とポリシー言語は開かれている必要がある |
製品ページの FAQ は、モデル側の安全策との違いを1文で整理しています。プロンプト・モデルの安全策・エージェントの枠組みは「エージェントが何をしようとするか」に影響し、実行時の制御は「何をしてよいか」を強制する、という分け方です。承認の設計そのものは Human-in-the-Loop の承認パターン で扱っています。
構成要素｜OpenShell・Sentry・BlueField-4・DOCA・Vera
製品ページとニュースリリースの説明をもとに、各要素の役割を整理します。
| 要素 | 種類 | 役割 |
|---|---|---|
| NVIDIA OpenShell | ソフトウェア（オープンソース） | エージェントの実行のしかた、アクセスと変更の範囲、推論を動かす場所を統制する |
| NVIDIA Sentry | ソフトウェア（BlueField-4 上で動作） | エージェントの実行環境の外でテナントを分離し、脅威の検出・ID の統制・ポリシーの強制を行う |
| NVIDIA BlueField-4 | ハードウェア（DPU） | ホストから独立したセキュリティ領域を持ち、強制の仕組みをエージェントとホストのソフトウェアから切り離す |
| NVIDIA DOCA | ソフトウェア | Sentry がリクエストと応答を検査し、証明つきの記録を出し、エージェントの ID を確かめるための土台 |
| NVIDIA Vera CPU | ハードウェア（CPU） | オーケストレーション、サンドボックス内のコード実行、データ処理を受け持つ |
Technical Blog は、安全基盤を3つの層で説明しています。利用者が作るアプリケーション層（モデル・ハーネス・ツール・データ）、それを基盤に載せて監視と強制を行う実行環境の層、実際のハードウェアである基盤の層です。Technical Blog は OpenShell を実行環境の層と位置づけ、BlueField-4 を、ホストから切り離された基盤を守る層と説明しています。
Vera CPU について、NVIDIA の製品ページは、従来の CPU 基盤と比べてサンドボックスの性能が最大80%速いと書いています。測定の条件は同ページに書かれていないため、数字は NVIDIA の説明として受け取るのが安全です。ニュースリリースは、OpenShell はオープンソースなので Arm や Intel など他社の計算基盤にも広げられると書いています。
OpenShellでできる制限｜ファイル・プロセス・通信・認証情報
OpenShell は3つの部品で制御します。Technical Blog「Add Runtime Controls to AI Agents with NVIDIA OpenShell」の説明は次のとおりです。
| 部品 | 役割 |
|---|---|
| OpenShell Gateway | 多数のサンドボックスのライフサイクルとポリシーを管理する |
| OpenShell Supervisor | サンドボックスごとに1つ付き、エージェントの外側で動いて、外向きのリクエストをポリシーに照らして検査する |
| OpenShell Sandbox | ファイルシステムとプロセスをカーネルの機能で制限した中でエージェントを動かす。ネットワークの経路はスーパーバイザー経由だけ |
制限の対象は4つに整理できます。
- ファイル：OS のカーネルの制御で、読める・変更できるファイルを限定します
- プロセス：追加の権限を取得できないようにします。エージェントがシェルを起動しても、生成したコードを実行しても、子プロセスを立ち上げても、制限は外れません
- 通信：接続先の許可に加えて、HTTP・GraphQL・MCP の通信は中身を検査できます。同じ API でデータの問い合わせは通し、書き込みは止める、という指定ができます
- 認証情報：エージェントには本物の認証情報を見せず、承認された接続先へのリクエストにだけ OpenShell が差し込みます。許可されていない宛先へ送ろうとしたリクエストは拒否されます
判断の結果は、Open Cybersecurity Schema Framework（OCSF）形式の監査記録に残ります。検査したリクエストを止めた時は、理由の分かるエラーをエージェントに返せるので、エージェントは次の手を自分で選べます。ポリシーは YAML で書き、OPA/Rego に変換されて、外向きのリクエストごとに評価されます。
サンドボックスの隔離方式そのものを比較したい場合は、AIエージェントのサンドボックス設計（gVisor・Firecracker） が参考になります。
OpenShell 0.1.0で入った機能
Technical Blog は、0.1.0 で入った機能を5つ挙げています。
| 機能 | できること |
|---|---|
| 複数テナントの運用 | 共有の基盤の上で、チームや顧客ごとにワークスペース・権限・サービスへのアクセスを分ける |
| ポリシーの形式検証 | 求められた権限が決めた境界の内側に収まるか、どこで越えるかを、人と AI の確認者に示す |
| 拡張できる統制 | 他社のセキュリティサービスや社内の確認の仕組みを、エージェントの外側の強制につなぐ |
| 認証情報を守ったサービス利用 | 本物の認証情報をエージェントの外に置いたまま、認証が必要なサービスを使う |
| CPU と GPU での実行 | コンテナ・VM・Kubernetes の環境で、実験やデータ処理を CPU でも GPU でも動かす |
README は、0.1 系について「安定したリリースの間隔、新しい隔離の部品、拡張の口、新しい API」を挙げ、以前の版から上げる場合は 0.1.0 の移行ガイドを読むよう案内しています。GitHub のリポジトリは2026年9月30日時点でスター 10,973、ライセンスは Apache 2.0 です。
対応するエージェントについて、製品ページの FAQ は Claude Code・Codex・OpenCode・GitHub Copilot CLI・OpenClaw を挙げ、Technical Blog は Codex・Claude Code・Pi・Hermes を挙げています。独自のエージェントとサンドボックスのイメージを持ち込むこともできます。
動かし方｜インストールから通信の制限の確認まで
README によると、必要なのは Linux、Apple Silicon の macOS、または WSL 2 の Windows（実験的な対応）と、Docker・Podman・ホストの仮想化のいずれかです。ドキュメントの Installation は、Docker なら Docker Desktop か Docker Engine 28.0 以降、Podman なら Linux の Podman 5.x と cgroups v2 を条件に挙げています。
インストールは1行です。スクリプトが CLI、ポリシーの証明器、ローカルのゲートウェイを入れて、ゲートウェイを起動します。
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell status外部から取得したスクリプトをそのままシェルに渡す形なので、社内の端末で実行する前に、スクリプトの中身と社内の規程を確かめてください。Ubuntu では、Canonical のブログが sudo snap install openshell での導入を案内しています。
Technical Blog は、API キーもモデルも使わずに、ポリシーの判断を目で確かめる例を載せています。まず、外向きの通信を一切許可しないサンドボックスを作ります。ポリシーのファイル（no-network.yaml と github-readonly.yaml）は、ブログからリンクされているものを examples ディレクトリに置きます。
openshell sandbox create --name policy-demo \
--no-auto-providers \
--policy examples/no-network.yamlこのコマンドでサンドボックスの中のシェルが開きます。公開の API を読もうとすると、失敗します。
curl -sS --max-time 10 https://api.github.com/zenホスト側の別の端末でログを見ると、どのプログラムのリクエストが、なぜ止められたかが分かります。
openshell logs policy-demo --since 5m次に、GitHub の REST API を読み取り専用で許可するポリシーに差し替えます。ブログに載っている規則は次の形です。
network_policies:
github_api:
name: github-api-readonly
endpoints:
- host: api.github.com
port: 443
protocol: rest
enforcement: enforce
access: read-only
binaries:
- path: /usr/bin/curlサンドボックスを再起動せずに、ホスト側から適用します。
openshell policy set policy-demo \
--policy examples/github-readonly.yaml --waitサンドボックスに戻って、読み出しと書き込みの両方を試します。
# Read: allowed
curl -sS --max-time 10 https://api.github.com/zen
# Write: blocked
curl -sS --max-time 10 -X POST https://api.github.com/zen読み出しは通り、POST は止まります。エージェントが同じコマンドを実行しても、同じ制限がかかります。実際のエージェントを動かす手順は、ドキュメントの「Run Your First Agent」にあり、OpenCode を OpenRouter の無料モデルで動かす例が載っています。プロバイダーのプロファイルを取り込み、認証情報を登録し、エージェントのコマンドを -- の後ろに渡してサンドボックスを作る流れです。
openshell sandbox create \
--name my-agent \
--from ghcr.io/anomalyco/opencode:latest \
--provider openrouter \
-- opencode -m openrouter/nvidia/nemotron-3.5-lightning:freeコーディングエージェントに OpenShell の使い方を覚えさせるスキルも用意されています。README は npx skills add NVIDIA/OpenShell を案内しています。
ポリシーの変更と検証｜policy advisorとprover
エージェントは、作業の途中で想定していなかった接続先を必要とすることがあります。OpenShell はこの場面のために、2つの仕組みを持っています。
policy advisor は、止められたリクエストをもとに、範囲を狭く絞ったポリシーの変更案を作ります。ドキュメントによると、直近の拒否を接続先・ポート・呼び出したプログラムでまとめ、案をゲートウェイに出します。案は既定では人の確認を待つ状態になり、エージェントが自分の要求を自分で承認することはできません。承認された規則は、動いているサンドボックスに再起動なしで読み込まれます。
openshell rule get my-agent --status pending
openshell rule approve my-agent --chunk-id <chunk-id>
openshell rule reject my-agent \
--chunk-id <chunk-id> \
--reason "Not needed for this task."エージェント自身に変更案を出させる設定は、サンドボックスごとに有効にします。
openshell settings set <sandbox-name> \
--key agent_policy_proposals_enabled \
--value truepolicy prover は、ポリシーが与える権限を形式論理で調べます。あるツールでの書き込みを止めても、許可された別のツールや生成したコードが同じ認証情報で同じ書き込みをできるなら意味がありません。prover は、権限が運用者の決めた境界に収まることを証明するか、境界を越える具体的な操作を示します。結果はポリシーのモデルから出るので、エージェントの説明では変わりません。
Technical Blog は、長時間の敵対的な実験の結果も書いています。安全策を弱めた最先端のエージェントが、保護されたリポジトリを書き換える権限を得ようとして、AI の確認者を最長2時間説得し続けました。形式検証が「その権限で何ができるか」の証拠を確認者に示し、この試験では保護されたリポジトリへの書き込みは起きなかった、という報告です。
制限の範囲には決まりがあります。通信の規則は動作中に変えられますが、ファイルとプロセスの制限はサンドボックスの起動時に決まり、変えるには新しいサンドボックスを作る必要があります。
Sentryの監視と隔離｜ホストの外で動く意味
Sentry は、BlueField-4 DPU 上で動く帯域外の監視役です。ニュースリリースは、エージェントがソフトウェアの境界の外に出ようとすると、Sentry がミリ秒単位で隔離して止めると書いています。
要点は、監視と強制の仕組みが、エージェントが動くホストとは別の信頼領域にあることです。ニュースリリースは、脅威の検出、ハードウェアによるエージェントの統制と強制、データへのアクセスの保護を、エージェントからも攻撃者からも見えない隔離された領域から行うと説明しています。製品ページの FAQ は、ホストやワークロードが侵害されても、BlueField-4 上の監視と強制は動き続けると書いています。
Sentry が DOCA を使って行うことは次の4つです。
- エージェントのリクエストと応答を検査する
- 証明つきの記録（attested telemetry）を出す
- エージェントの ID を確かめる
- データ・ツール・API・サービスへのアクセスに、細かいゼロトラストのポリシーを強制する
Technical Blog によると、NVIDIA Vera Rubin POD では、計算トレイごとに BlueField-4 が「そのノードからモデルへ向かう唯一の経路」に置かれます。5つの原則の3つ目、モデルへの経路を制御点にする、という考え方をハードウェアで実装した形です。同ブログは、BlueField-4 を載せた Vera のシステムを既に動かしている場合、この保護を有効にするのはソフトウェアの更新だけだと書いています。
Sentry の入手方法、対応する製品の一覧、料金は、2026年9月30日時点で公式に確認できていません。
参加企業とOS各社の対応｜Anthropic・Salesforce・Canonical・SUSE・Red Hat
ニュースリリースは、100を超える組織が Open Agent Safety Platform の技術に関わっているとし、個別の取り組みを挙げています。開発者に関係の深いものを抜き出します。
| 組織 | 取り組み（各社の発表の記載） |
|---|---|
| Anthropic | Claude Managed Agents は、エージェントのループを、作業を実行するサンドボックスとは別のサーバーで動かす。OpenShell と BlueField との統合で、そのサンドボックス経由のアクセスを厳しく制御できる |
| SpaceXAI | Cursor のコーディングエージェントと Grok のモデルで利用 |
| Salesforce | OpenShell を Slack と統合。Slack からエージェントの活動と監査イベントを見て、追加の権限の要求を承認・却下できる |
| SAP | Joule Studio の実行環境に OpenShell を組み込む。OpenShell への開発の貢献も行う |
| Scale AI | 参照設計を、企業と政府向けのエージェント基盤に取り入れる |
| Canonical | OpenShell の snap と、Charmed OpenShell のアルファ版を発表。MicroCloud 上の Canonical Kubernetes でゲートウェイを運用し、LXD のドライバーでサンドボックスを作る |
| SUSE | SUSE AI Factory with NVIDIA の参照アーキテクチャで、脆弱性対応のエージェントの土台に利用 |
| Red Hat | Red Hat AI Factory with NVIDIA で OpenShell と DOCA を動かす。統制の方針を技術的な制御に落とす asago コミュニティも立ち上げている |
このほか、ロボットでは Figure・Gecko Robotics・Skild AI、金融では Citi と JPMorganChase の名前が挙がっています。関連する団体として、NVIDIA が120を超える組織と立ち上げ、Linux Foundation が運営する Open Secure AI Alliance があり、ニュースリリースは、今回の基盤がその活動を支えるものだと位置づけています。Claude Managed Agents の仕組みは Claude Managed Agentsとは で解説しています。
導入判断｜BlueField-4が無い環境で使える範囲
製品ページの FAQ は、OpenShell に BlueField-4 は必要ないと明記しています。対応するローカル環境・オンプレミス・クラウド・Kubernetes の基盤で動きます。環境ごとに使える範囲を整理します。
| 環境 | 使えるもの | 得られる制御 |
|---|---|---|
| 開発者の手元（Docker・Podman） | OpenShell | ファイル・プロセス・通信・認証情報の制限、監査記録、ポリシーの検証 |
| 共有の基盤（Kubernetes） | OpenShell（Helm でゲートウェイを配備） | 上に加えて、ワークスペースごとの分離と複数テナントの運用 |
| BlueField-4 を載せた Vera のシステム | OpenShell と Sentry | 上に加えて、ホストから独立した監視・隔離と、証明つきの記録 |
README は、Kubernetes で使う場合、CNI が NetworkPolicy を強制できることを条件に挙げています。
当社の見方を3点書きます。1つ目、コーディングエージェントを開発者の端末で動かしているチームは、OpenShell だけで始められます。エージェント側の許可設定は、エージェント自身が読み書きできる場所にあることが多く、外側の制限はそれを補います。2つ目、既存の対策を置き換えるものではありません。モデルの安全策、エージェント側の承認、入出力のフィルターはそれぞれ別の層で、OpenShell が受け持つのは実行時のアクセスです。入出力側の対策は AIエージェントのガードレール比較 を見てください。3つ目、Sentry は対応するハードウェアが前提で、入手条件がまだ読めません。自社でデータセンターの機器を選ぶ立場でなければ、クラウド事業者や機器メーカーの対応を待つ形になります。
【要注意】読み違えやすい点
読み違い1：Open Agent Safety PlatformはNVIDIAのハードウェアが無いと使えない
OpenShell は BlueField-4 なしで動きます。ハードウェアが必要なのは Sentry です。NVIDIA は Vera と BlueField に最適化したと書きつつ、他のハードウェアとの互換にも触れています。
読み違い2：OpenShellを入れればエージェントの判断が安全になる
OpenShell が強制するのは「何にアクセスしてよいか」です。エージェントが許可された範囲の中で誤った変更をすることは止めません。ポリシーの範囲を狭く保つことと、変更を人が確かめる手順は別に要ります。
読み違い3：ポリシーは動作中に何でも変えられる
動作中に変えられるのは通信の規則です。ファイルとプロセスの制限はサンドボックスの起動時に決まり、変更には新しいサンドボックスが必要です。
読み違い4：3月に発表されたOpenShellと同じもの
OpenShell 自体は2026年3月に紹介されていますが、今回は 0.1 系として、複数テナントの運用、ポリシーの形式検証、拡張の口が入りました。README は以前の版からの移行ガイドを案内しています。3月時点の手順をそのまま使わず、現在のドキュメントを読んでください。
よくある質問
NVIDIA Open Agent Safety Platformは無料で使えますか？
OpenShell は Apache License 2.0 のオープンソースで、GitHub から入手できます。Sentry と、それが動く BlueField-4 の入手条件と料金は、2026年9月30日時点で公式に確認できていません。
OpenShellはClaude CodeやCodexで使えますか？
使えます。製品ページの FAQ は Claude Code・Codex・OpenCode・GitHub Copilot CLI・OpenClaw を挙げています。エージェントを書き換える必要はなく、サンドボックスの主プロセスとして起動します。
WindowsやMacでも動きますか？
README は、Linux、Apple Silicon の macOS、WSL 2 の Windows（実験的な対応）を挙げています。実行基盤は Docker・Podman・ホストの仮想化から選びます。詳しい条件はドキュメントの Support Matrix にあります。
SentryとOpenShellの違いは何ですか？
OpenShell は、エージェントのプロセスの外側でポリシーを強制するソフトウェアです。Sentry は、BlueField-4 上で動き、エージェントとホストのソフトウェアの両方から独立した場所で監視と強制を行います。FAQ は、Sentry を「追加の独立した層」と位置づけています。
利用状況のデータは送信されますか？
README によると、OpenShell は運用上の分類と件数に限った匿名のテレメトリーを集めます。サンドボックス名・ホスト名・ファイルのパス・プロンプト・認証情報・モデル名・利用者のコンテンツは集めないと書かれています。止めるには、ゲートウェイに OPENSHELL_TELEMETRY_ENABLED=false を設定します。
まとめ
NVIDIA Open Agent Safety Platform は、2026年9月28日に発表された、エージェントの外側に安全策を置くための基盤です。オープンソースの OpenShell が実行時のアクセスをポリシーで制限し、BlueField-4 上の Sentry がホストから独立して監視と隔離を行います。OpenShell は手元の Docker や Podman でも動き、通信の規則の変更は policy advisor と prover を通して人が確かめられます。Sentry の入手条件は、2026年9月30日時点で確認できていません。
まず試すなら、OpenShell を入れて、外向きの通信を止めたサンドボックスと読み取り専用のポリシーの例を動かすところからです。社内でエージェントの実行基盤と権限の設計を検討する段階で相談先が必要な場合は、Uravation でも AI エージェントの導入を支援しています。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
- NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment — NVIDIA Newsroom（2026年9月28日・参照日: 2026-09-30）
- NVIDIA Open Agent Safety Platform: A Reference for Continuous In-Silicon Agent Monitoring — NVIDIA Technical Blog（2026年9月28日・参照日: 2026-09-30）
- Add Runtime Controls to AI Agents with NVIDIA OpenShell — NVIDIA Technical Blog（2026年9月28日・参照日: 2026-09-30）
- NVIDIA Open Agent Safety Platform（製品ページ・FAQ） — NVIDIA（参照日: 2026-09-30）
- NVIDIA/OpenShell（README・リリース一覧） — GitHub（参照日: 2026-09-30）
- Installation — NVIDIA OpenShell ドキュメント（参照日: 2026-09-30）
- Run Your First Agent — NVIDIA OpenShell ドキュメント（参照日: 2026-09-30）
- Charmed OpenShell to help secure autonomous AI agent fleets — Canonical（参照日: 2026-09-30）
- Agentic SecOps on SUSE AI Factory with the NVIDIA Open Agent Safety Platform — SUSE（参照日: 2026-09-30）
- Securing AI agents requires securing the systems around them — Red Hat（参照日: 2026-09-30）
- NVIDIA、AIエージェントを監視・制御する「Open Agent Safety Platform」を発表 — gihyo.jp（報道・2026年9月29日・参照日: 2026-09-30）
