NVIDIAは、AIエージェントに強制可能な権限、サンドボックス化、認証情報制御を追加するオープンソースのランタイムOpenShell 0.1.0を公開した。

NVIDIAは、展開後のAIエージェントがアクセスできるものや実行できることを制御するために設計されたオープンソースのランタイム、OpenShell 0.1.0を発表した。このシステムは、サンドボックス化、サービス制御、認証情報管理、ポリシー適用をエージェントのワークロードの外側に置くことで、チームがエージェント自体を書き換えることなく安全対策を追加できるようにしている。
このリリースは、増大する運用上の課題を対象としている。コードを書き、ツールを使い、社内システムへアクセスし、新しい情報が届くたびに動作し続けるエージェントは、長時間の作業には有用だが、本番データを変更したり、機密情報を漏えいさせたり、割り当てられたタスクを超えて行動したりする可能性もある。NVIDIAは、OpenShellが企業の自動化、研究、ロボティクス、その他の展開において、こうした行動に対するランタイム境界を提供することを意図していると述べている。
NVIDIA OpenShellは、新しいエージェントフレームワークではなく、制御レイヤーとして位置付けられている。Codex、Claude Code、Pi、Hermesなど既存のシステムと連携しつつ、ワークスペース、計算リソース、データ、認証情報、外部サービスへのアクセスを制御するよう設計されている。
この分離は、製品設計の中核である。エージェントは引き続き指示を解釈し、ツールを選択し、アプローチを変更できるが、周囲のランタイムが要求された操作を許可するかどうかを決定する。これにより、異なる開発者によって構築されたり、異なるモデルに基づいたりするエージェント群に対して、プラットフォームチームが一貫した制御を適用する手段を得られる可能性がある。
NVIDIAによれば、OpenShell 0.1.0はサンドボックス操作、ガバナンス統合、認証情報保護、ポリシー検証、柔軟な計算資源をサポートする。ローカルではサンドボックス経由で使用でき、その後、DockerやKubernetesの計算ドライバー、ワークスペース、IDミドルウェアを使って共有インフラに展開できる。
このランタイムは、アプリケーション、ランタイム、インフラの各層をカバーすると同社が説明する、NVIDIAのより広範なOpen Agent Safety Platformの一部である。OpenShellは特にランタイム層に対応しており、エージェントの外向き要求や実行環境とのやり取りを検査・制限できる。
OpenShellは3つの主要コンポーネントを使用する。OpenShell Gatewayは、複数のエージェントにまたがるサンドボックスのライフサイクルとポリシーを管理する。OpenShell Supervisorは各サンドボックスの外側、つまりエージェントのワークロードとは別に実行され、外向き要求を適用可能なポリシーと照合する。サンドボックスは、カーネルレベルでエージェントのファイルシステムとプロセスに制御を適用する。
このアーキテクチャは、エージェントが自分自身の制御を単純に改変することを防ぐことを目的としている。権限はワークロードの外側で管理でき、チームは個々のサンドボックスやエージェントのグループに異なる能力を割り当てられる。これは、1つの広範な権限セットによって、あるワークフローのエラーが無関係なシステムに影響を及ぼす恐れがある、エージェント・フリートを運用する組織にとって重要である。
NVIDIAはまた、認証情報の保護も強調している。OpenShellは、認証情報をエージェントに直接公開するのではなく、サービスへのアクセスを仲介し、エージェントが実行できるAPI操作を制限できる。同社は、これにより、機密性の高い認証情報をエージェントのワークロード外に置いたまま、タスクに必要な能力をチームに提供できるとしている。
このシステムには、形式論理に基づくポリシープローバーが含まれている。NVIDIAによれば、モデル化された権限が定義された境界内に収まっているかを検証し、その境界を越えるアクションを特定できる。これは、プロンプトや指示のみに頼るよりも強力なアプローチだが、結果の有効性は、組織が自社のシステム、API、ID、許可されたアクションをどれだけ完全にモデル化しているかに左右される。
このレポートの製品詳細はNVIDIAのDeveloper Blogによる発表に基づいており、ベンダー発の情報である。出典には、独立したテスト結果、侵害防止の測定値、レイテンシ数値、運用コスト比較、あるいはポリシープローバーに対する第三者評価は含まれていない。
NVIDIAは、Cadence、Slack、Gecko Roboticsなどの組織がOpenShellを採用していると述べている。同社はこれらの例を異なるユースケースに結び付けている。Cadenceはチップ設計向けにChipStack Autonomous RTL Design Engineerと組み合わせて使用しており、Slackはタスク自動化のためにOpenShell上でオンデマンドのエージェントプラットフォームを構築しており、Gecko Roboticsは物理ロボットに関わる意思決定を行うエージェントを統制するために使用している。
これらの例は、NVIDIAが追求している展開の幅を示しているが、採用規模、本番利用可能性、測定可能なビジネス成果を示すものではない。発表では、関与するエージェント数、ユーザー数、ワークロード数、拠点数は明記されていない。したがって、導入の兆候は、各組織がさらに実装の詳細を公開するまでは、企業による主張として扱うべきである。
0.1.0というバージョンは、ランタイムの初期段階であることも示している。オープンソースとして利用できることで、開発者はコードを調査し、貢献し、制御をテストできるが、それだけで高いリスクを伴う本番環境向けの成熟度が証明されるわけではない。組織は、プロジェクトの運用安定性、統合コスト、障害時の挙動を評価する必要がある。
AI開発者にとって、OpenShellはエージェントのコードやプロンプトの中にすべてのセキュリティ制御を組み込む必要を減らせる可能性がある。基盤モデル、フレームワーク、エージェント指示が変わっても、ランタイム境界は再利用できる。これは、複数のAIエージェントを試しているチームや、モデルを頻繁に更新するチームにとって特に重要である。
企業向けAIチームにとっての実際的な問いは、ランタイムポリシーを既存のID、アクセス、ガバナンスの仕組みにきれいに対応させられるかどうかである。有用な導入には、どのエージェントが特定のデータベースにアクセスできるか、どのAPIメソッドが許可されるか、要求に人間の承認が必要か、ポリシー変更をどのようにレビューし記録するか、といった問いへの回答が必要になる。
このアプローチは、特に長時間稼働するエージェントに関連が深いかもしれない。短命でテキストを下書きするアシスタントは、数日かけてソフトウェア障害を調査し、実験を実行し、ファイルを変更し、あるいは物理環境で行動するエージェントとは異なるリスクプロファイルを持つ。OpenShellは、ワークロードの外側に制御を置くことで、複数の段階にわたって作業する能力を失わせることなく、エージェントの変化する意思決定の影響を抑えようとしている。
トレードオフもある。厳格なポリシーは、有用な自律性を低下させたり、正当なタスクが新しい権限を必要とする場合に運用上の摩擦を生んだりする可能性がある。緩い、あるいは不完全なポリシーは、ランタイムが正しく機能していてもギャップを残すかもしれない。ポリシープローバーはモデル化された競合の特定に役立つが、チームがポリシーやインフラモデルに表現していない前提を検証することはできない。
次のシグナルは、本番向けドキュメント、独立評価、そしてOpenShellが障害や攻撃の際にどう振る舞うかの証拠である。開発者は、NVIDIAの発表にある例を超えて、ポリシー構文、監査ログ、承認ワークフロー、ロールバック手順、IDシステムのサポートに関する詳細を探すべきだ。
企業の購入者は、Cadence、Slack、Gecko Roboticsが、エージェント・フリートの規模、制御されたアクションの種類、これらのポリシーを適用する運用コストを含む、具体的な導入結果を公開するかどうかにも注目すべきである。プロジェクトのGitHub活動、リリース頻度、課題解決、Docker、Kubernetes、ガバナンスツールとの統合が、成熟度をさらに示す。
最後に、OpenShellとより広範なOpen Agent Safety Platformとの関係が重要になる。NVIDIAの今回の発表はランタイム制御に焦点を当てているため、購入者はその制御がアプリケーションレベルの安全対策、インフラセキュリティ、監視、人間による監督とどう結び付くのかを理解したいはずだ。
NVIDIAのOpenShellリリースは、現実の導入ギャップに対処している。つまり、エージェント自身を信頼できる管理者として扱うのではなく、役立つシステムへのアクセスをエージェントに与えるという課題だ。その最も重要なアイデアは、エージェントの振る舞いと実行を支配する権限を分離することにある。
それでも、このリリースは完全な安全ソリューションではなく、初期版のインフラとして評価すべきである。ビルダーや企業にとっての価値は、ポリシーの品質、既存の制御との統合、独立したテスト、そして自律的なワークフローを扱いにくくせずにランタイムが信頼性を維持できるという証拠に左右される。