1回の成功したインジェクションは、全認証情報の引き渡しに等しい
APIキーを環境変数に設定することは、過去20年間におけるサーバーサイド開発のデフォルト動作でした。2026年9月28日、NVIDIAはオープンエージェントセキュリティプラットフォーム（Open Agent Safety Platform）を発表し、このデフォルト動作をエージェント時代のタブーと位置づけました。プラットフォームは2つの要素で構成されています：オープンソースソフトウェアOpenShell（Apache 2.0、GitHubリポジトリNVIDIA/OpenShell）、および参照システム設計Sentry——後者はBlueField-4 DPU（Data Processing Unit、データ処理ユニット）上で動作し、アウトオブバンド（out-of-band）ウォッチドッグとしてメインCPU上のエージェントを監視し、公式にはミリ秒レベルでのエージェント隔離が可能です。
リポジトリの現状：Rust実装で、cratesがcore、supervisor、credential-gateway、policy-engine、egress-gatewayなどのモジュールに分割されています；18.2kスター、1,852回のコミット；0.1.x安定版で、約3週間に1回のバージョンアップ。コミット密度と3週間ごとのリリースサイクルは、同じ判断を指し示しています——このランタイムはまだ急速に形成されている段階にあり、本番環境に導入する際にはインターフェースの変更に備えたコストを見積もる必要があります。
OpenShellの設計論理は1つの原則に要約できます：エージェントの挙動は予測不可能であるため、その到達範囲を限定し、認証判断をモデルコンテキストからカーネルに移動します。 エージェントランタイムの競争焦点はそれに伴って変化します——「モデルがどれだけ従順であるか」から「権限越えがどれだけ遠くまで行けるか」へ。
認証情報はゲートウェイに渡し、コンテキストには含めない
自律型エージェントの日常業務はシェルコマンドの実行、ファイルの書き込み、ネットワークリクエストの送信などで、認証情報は通常環境変数、設定ファイル、または.envに保存されています。1回の成功したプロンプトインジェクション、あるいは単なるモデルの誤った判断だけで、エージェントは全認証情報を使用して行動します。爆発範囲はそれに付与された権限セットに等しく、権限を限定することは爆発範囲を狭めることです。 これがOpenShell全体の設計の出発点です。
プロンプトレベルのフェンスは敵対的な入力に対して強制力を持たません。system promptの制約はモデルの従順さに依存しており、攻撃者がする必要があるのはモデルの考えを変えることだけです。カーネルレベルの権限境界はモデルの考えを気にせず、システムコールは直接拒否されます。フェンスと境界の違いは強制者にあります：1つはモデルの自主性に依存し、もう1つはカーネルに依存します。
図：OpenShellコマンドラインインターフェースの実行スクリーンショット。エージェントのアクションはポリシー検査が通過した後にのみ実行されます。出典：OpenShell公式リポジトリドキュメント
カーネルレベルの強制が最初の重要なメカニズムです。ポリシーはカーネルレベルで有効になり、ランタイムライブラリやコンテナ設定に依存しません；エージェントの境界内での各アクションはポリシー検査を通過する必要があります。コンテナはプロセス隔離とイメージ配布を解決しますが、OpenShellは別の問題に答えます：エージェント実行中の認証情報、ファイル、ネットワークへの各アクセスが許可されているかどうかです。
認証情報ゲートウェイが2番目の重要なメカニズムです。APIキーとトークンは認証情報ゲートウェイ（credential gateway）に預けられ、アウトバウンドリクエスト時に注入されます；認証情報は最初からエージェントのコンテキストに入らず、そのファイルシステムにも保存されません。「キーを.envに詰め込む」という従来の方法と比較すると、漏洩面はマシン全体からゲートウェイコンポーネントに限定されます。モデルは騙される可能性がありますが、騙されたモデルには鍵がありません。
アウトバウンドトラフィックも同様に管理されます：アウトバウンドゲートウェイ（egress gateway）は宛先ホワイトリストに基づいて許可を与え、ホワイトリスト外には一切到達できません；ファイルシステムとネットワークの対象も、エージェントが見るべきディレクトリとアドレスのみが公開されます。
図：OpenShellアーキテクチャ——エージェント、スーパーバイザー、認証情報ゲートウェイ、ポリシーエンジン、アウトバウンドゲートウェイがそれぞれ独立したモジュールで構成され、認証情報とポリシー判断はエージェントコンテキストの外で完了します。出典：OpenShell公式リポジトリdocs/images
ポリシーの変更はまず形式検証を通過し、有効化を検討する
ポリシーを1つ間違えることは、1つの穴を開けることと同じです。OpenShellはポリシーの変更を形式検証の後にブロックします：新しいポリシーは有効化される前にまず形式検証を通過し、セマンティクスが期待通りであることを確認します。同種のサンドボックスツールでは、このステップは稀です——ほとんどのソリューションはポリシーをコードとして扱い、変更後即座に有効化される状態に留まります。
supervisorコンポーネントはエージェントの作成、監視、終了を担当し、ライフサイクル管理層を構成します。SDKはPython、TypeScript、Go、Rustの4言語をカバーし、KubernetesデプロイはHelm経由で、エンジニアリング統合のパスは完全です。
形式検証には独自の境界があります：それは「ポリシーの誤り」に対抗しますが、「ポリシーは正しいが狭すぎる」問題は解決しません。ポリシーが狭すぎると、エージェントは仕事をできなくなり、運用圧力が人にルールを緩めるように促します；意図が一度緩められると、どれだけ厳密な検証も緩やかな意図を正確に実行するだけです。セキュリティ責任はコード層からポリシー作成者の手に移り、ポリシー自体が新しい監査対象となります。
図：サンドボックス強制点の図解——ポリシーはファイルシステム、ネットワーク、認証情報、アウトバウンドトラフィックの境界でそれぞれ有効になり、各境界は独立したコンポーネントに対応します。出典：OpenShell公式リポジトリdocs/images
ウォッチドッグをBlueField-4 DPUに搭載、ミリ秒レベルでの隔離を実現
Sentry参照設計はウォッチドッグをホストから外しました。それはBlueField-4 DPU上で動作し、アウトオブバンドでメインCPU上で実行されるエージェントを監視し、公式にはミリ秒レベルでのエージェント隔離が可能であり、デモ環境ではVera CPUも実行に参加しました。
アウトオブバンドはこの設計の重要なポイントです。インバンド監視は監視対象と同じカーネルと信頼ドメインを共有しており、ホストが乗っ取られると監視も乗っ取られます；DPUには独立した計算能力とネットワークパスがあり、メインCPU上のエージェントが制御不能になってもウォッチドッグ自体には到達できません。隔離動作はミリ秒単位で計測され、不正行動のウィンドウもミリ秒単位で狭まります——前提条件として、DPU側のファームウェアとソフトウェアスタックが守り抜き、ウォッチドッグ自体が新しい高価値の攻撃目標にならないことです。
公式ニュースリリースでは同時に12の業界パートナーと統合元がリストアップされており、クラウドベンダーとセキュリティベンダーが名簿に含まれています。エコシステムの立場の意味は明確です：NVIDIAは「エージェントが境界のあるランタイム上で動作すること」をデフォルトのデプロイ形態にしたいと考えており、仮想マシンに対するhypervisorのようにです。
0.1.xバージョン番号は「広く利用可能」という4文字よりも正直
バージョン番号がまず冷水を浴びせます。OpenShell現在は0.1.x安定版で、約3週間ごとのリリースサイクルですが、公式の表現は「すでに広く利用可能」（now broadly available）です。3週間ごとのリリースサイクル自体が信号です：インターフェースとセマンティクスはまだ変化中であり、本番環境に統合するには移行コストを見積もる必要があります；「広く利用可能」という4文字と0.1.xの間には、判断を委ねられる空間があります。
2番目の冷水：サンドボックスは爆発範囲を限定しますが、リスクを排除しません。カーネル強制層、認証情報ゲートウェイ、ポリシーエンジン自体が新しい信頼基盤となり、それらに問題があることは境界の無効化を意味します。攻撃面は位置を移動しましたが、総量は減っていません——監査対象は「エージェントアプリケーション」から「サンドボックスランタイム」に拡大しました。
ルート戦争はまだ結論が出ていません。AnthropicのClaude Managed Agentsなどのホスティングプラットフォームはサンドボックスをクラウドサービス内に組み込み、ユーザーは境界を自分で構築する必要がありません；OpenShellはセルフホスティング、監査可能なルートを取ります。2つの道の前提条件は異なります：データをドメイン外に出さず、自前の監査証跡を必要とするチームは後者を選び、専任の境界運用能力を持たないチームはホスティングサービスを選んで手間を省くでしょう。選択はコンプライアンス要件と運用能力によって決まり、2つの道にはそれぞれ成立するシナリオがあります。
ソフトウェアは無料、ハードウェアは売る
ビジネスの勘定は明確にする必要があります。OpenShellはApache 2.0でオープンソース化され、エージェントデプロイのコンプライアンスのハードルを下げています；Sentry参照設計はBlueField-4 DPUとVera CPUに結びついています。ソフトウェアは無料で配布され、セキュリティハードウェアは台単価で計算——CUDA時代の古いやり方が再演されています：エコシステムツールは無料、計算能力は有料です。サンドボックスランタイム自体は収益を生みませんが、境界がどのハードウェア上で動作するかによって、お金はそこで決済されます。
このやり方はユーザーにも理にかなっています：OpenShellを選択すると監査可能な境界と明確なハードウェア購入リストが手に入り、ホスティングプラットフォームを選択すると運用不要が手に入ります。2つの配信形態はそれぞれ別々の勘定を計算し、リポジトリのオープンソースライセンスだけを見ても、全体のビジネス構造はわかりません。
冒頭の境界線に戻ります。プロンプトフェンスはモデルが何を言うかを制御しますが、カーネル境界はプロセスが何をできるかを制御します；前者はモデルの従順さに依存し、後者はポリシーの正しさに依存します。NVIDIAがオープンソースランタイムとDPUウォッチドッグを同時に提供した後、エージェントセキュリティの焦点は「モデルを従順にさせる」から「権限越えが遠くまで行けないようにする」へ移っています。 モデルが制御不能になるかどうかは依然として不明ですが、プロセスがどれだけ遠くまで行けるかは今や測定可能、監査可能です——これは9月28日の発表で本当に新しいものであり、0.1.xバージョン番号がまだ間に合っていない部分です。
参照リンク：
- NVIDIA公式ニュースリリース
- OpenShell公式リポジトリREADME
- OpenShellアーキテクチャドキュメント
