NVIDIA OpenShell 0.1.x: AIエージェント群のための安全でプライベートなランタイム

NVIDIAのOpenShellは、Apache-2.0ライセンスのランタイムであり、自律型AIエージェントにファイルアクセス、パッケージインストール、API呼び出し、認証情報などの実際の機能を提供しつつ、カーネルレベルでアクセス可能な範囲を制限し、ポリシー変更を適用前に正式に検証します。このプロジェクトはHacker Newsのトップページで489ポイント、213コメントを獲得し、議論は、バッテリー同梱のエージェントサンドボックスへの熱意と、デフォルトで有効なテレメトリ、名前、そしてこのカテゴリ全体がコンテナの再発明であるかどうかへの懐疑に分かれました。

OpenShellとは

OpenShellは、NVIDIAがApache License 2.0で公開している、自律型AIエージェント群のための安全でプライベートなランタイムです。その前提は、エージェントがファイルを読み、パッケージをインストールし、APIを呼び出し、認証情報を使用できるときに最も有用であり、その能力を提供することは、データ、秘密、ネットワークへの無制限のアクセスを提供することを意味しない、というものです。

コアデザインは宣言的です。ポリシーで各エージェントが触れることができるものを宣言し、OpenShellがそれを強制します。強制には2つのメカニズムがあります。

カーネルレベルの計装により、実行時にすべてのファイルアクセス、システムコール、ネットワーク接続にポリシーを適用します。
正式検証により、ポリシー変更が適用される前に、その変更が許可する内容をチェックします。

OpenShellはPyPIパッケージopenshellとして配布され、リポジトリはgithub.com/NVIDIA/OpenShellにあります。

0.1.xリリースライン

READMEは現在のシリーズのマイルストーンを示しています：「OpenShell 0.1.xの新機能：安定したリリースサイクル、新しい分離プリミティブ、拡張された拡張サーフェス、新しいAPI。」専用の0.1.0アップグレードガイドはdocs.nvidia.com/openshell/latest/upgrade/0-1-0で公開されています。

OpenShellを評価する人にとっての実際的な意味は、プロジェクトがアドホックではなく定義されたリリースサイクルに乗ったこと、そして拡張サーフェス（ミドルウェア、インターセプター、コンピュートドライバー）と公開APIの両方がこのシリーズで拡張されたことです。READMEはまた、SDKで使用されるOpenShellリリースをゲートウェイを実行しているリリースと一致させることを推奨しています。

カーネルレベルの強制の仕組み

OpenShellは各エージェントを分離されたサンドボックスに閉じ込め、エージェントのリクエストを解析するのではなく、カーネル境界でポリシーを強制します。READMEによると：

カーネル制御は、エージェントがアクセスできるファイルと実行できるシステムコールを制限します。
すべてのネットワーク接続は、サンドボックスを出る前にポリシーチェックを通過します。
エージェントは実際の認証情報を見ることはありません。OpenShellは、承認されたエンドポイント宛てのリクエストにのみ認証情報を追加します。

3番目のポイントは認証情報ブローカリングモデルです。サンドボックスは使用可能な秘密を保持せず、ランタイムは宛先が承認されたエンドポイントと一致する場合にのみ、送信パスで秘密を注入します。このプロジェクトはこの概念を「プロバイダー」と呼びます。承認されたエンドポイント（推論エンドポイントを含む）でのみ機能する認証情報です。

正式に検証されたポリシー変更

ポリシーのドリフトは自動アクションではなくレビューゲートとして扱われます。ポリシー変更が承認される前に、OpenShellは正式検証を使用して、変更が許可する新しいリスクのあるアクセス（例えば、認証情報を使用して新しいホストに到達する、新しいAPIメソッドを呼び出すなど）をフラグし、それらの変更は人間のレビューを待ちます。

OpenShellのドキュメントでは、これはポリシーセクションのアドバイザーとプロバーに分かれています。主張はエージェントが検証されているということではなく、古いポリシーと新しいポリシーの差分が、新たに許可する内容について分析されるということです。

アーキテクチャ：ゲートウェイ、スーパーバイザー、サンドボックス

OpenShellは、アーキテクチャドキュメントで説明されている3つの協力する部分で構成されています：ゲートウェイ、スーパーバイザー、サンドボックス。ゲートウェイはサンドボックス、ポリシー、アクセスのコントロールプレーンです。

ポリシーモデルは、ファイルシステムルール、ネットワークルール、プロセスルールをカバーします。サンドボックスドキュメントは、イメージ、ランタイム、GPU、ライフサイクルをカバーします。

インストールとクイックスタート

OpenShellは、Linux、Apple Silicon上のmacOS、またはWSL 2（実験的）を搭載したWindowsに加えて、Docker、Podman、またはホスト仮想化が必要です。サポートマトリックスに詳細が記載されています。

ドキュメント化されたクイックスタートは2つのコマンドです：

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo

インストーラーはCLIとローカルゲートウェイをセットアップします。デフォルトのサンドボックスイメージは、エージェントがインストールされていない最小限のUbuntuです。実際のエージェントを実行するには、「最初のエージェントを実行する」ガイドが、無料のOpenRouterモデルに対してOpenCodeを実行し、エージェントが要求する新しいアクセスを承認する手順を説明します。

SDK、Kubernetes、拡張機能

SDKはアプリケーションをOpenShellゲートウェイに接続します。CLIをインストールしません。

言語	インストール
Python	`uv add openshell`
TypeScript	`npm install @nvidia/openshell-sdk` (GitHub Packages)
Go	`go get github.com/NVIDIA/OpenShell/sdk/go@latest`
Rust	`cargo add openshell-sdk --git https://github.com/NVIDIA/OpenShell --tag <release-tag>`

Kubernetesの場合、ゲートウェイはHelmでデプロイされ、READMEは厳格な要件を述べています：CNIはNetworkPolicyを強制する必要があります。拡張性は、ミドルウェア、インターセプター、コンピュートドライバーを通じて公開されます。

リポジトリには、npx skills add NVIDIA/OpenShellでインストールできるエージェントスキルも含まれています。スキルは、コーディングエージェントにOpenShell CLIの操作、サンドボックスポリシーの作成、ゲートウェイと推論ルーティングのデバッグを教え、OpenShellソースチェックアウトなしで動作します。

OpenShellは明示的にエージェントファーストで構築されており、それが可能にするのと同じエージェント駆動のワークフローで開発されています。コントリビューターのセットアップはCONTRIBUTING.mdにあり、リポジトリのコーディング規約はAGENTS.mdにあります。

テレメトリと意図的に収集しないもの

OpenShellはデフォルトで匿名テレメトリを収集しますが、運用カテゴリとカウントに限定されます。READMEは収集しないものを列挙しています：サンドボックス名、ホスト名、ファイルパス、プロンプト、認証情報、プロバイダーまたはモデル名、ユーザーコンテンツ。このテレメトリからの集計レポートはリポジトリで公開されています。

テレメトリは2つの方法で無効にできます：ゲートウェイでOPENSHELL_TELEMETRY_ENABLED=falseを設定するか、Helmインストールでserver.telemetryEnabled=falseを設定します。完全にコンパイルアウトすることもできます。

デフォルトで有効なテレメトリは、Hacker Newsのスレッドで最も一貫した不満でした。あるコメンターはREADMEのテレメトリセクションを逐語的に引用し、そのままにしました。別のコメンターはもっと率直でした：

デフォルトのテレメトリを取るのは非常識です。それはさておき、制御のレベルはクールで、ほとんど細かすぎます。おそらく、非常に微妙なエンタープライズ要件にのみ特に役立つでしょう（おそらくそれがターゲットです）。ほとんどの企業は権限をより粗く設定でき、エージェント業界はデプロイプラットフォームとしてk8sから離れていると思います。

HNコメンターが気に入った点

何人かのコメンターはOpenShellを新しいアイデアではなく統合プレイと見なしました。「Nvidia Openshellは絶対に素晴らしく、一箇所に素晴らしい機能の束があります」とあるコメンターは書き、競合プロジェクトが登場するにつれてOpenShellが放棄されることを心配していたと付け加えました。別のコメンターは、すでにコンテナでエージェントを実行しているが、それでも価値を見出していると述べました：「まだコンテナでエージェントを実行していないなら、あなたは狂っています。とはいえ、これはそれらのコンテナを管理する素晴らしい方法のように見えます。」

GTC Europeに参加したスレッド参加者は、そこでのデモのかなりの部分がOpenShellを使用しており、以前は聞いたことがなかったと述べました。

好評だった再定義の1つは用語に関するものでした：「エージェントランタイム — 今日コーディングエージェントやエージェントハーネスと呼ばれるものには実際に良い名前です。」

批判：名前、マーケティング、メンテナンスの問題

名前はすぐに疑念を呼びました。OpenShellは、長年存在するOpen-Shell-Menuプロジェクトと名前を共有しており、あるコメンターはそれを衝突として指摘しました。他の人々はブランディングが矛盾していると感じました：「私はこれをこう読むほうが好きです：Nvidia Opens Hell」とあるコメンターは書きました。別のコメンター：「OpenとNvidiaが一文にあるのは素敵な撞着語です。」より広い異議は、「オープン」、「安全」、「プライベート」を製品説明に組み合わせることは疑念を招くということでした：「箱から出してすぐに何かをプライベートで安全と呼ぶことは、それらの主張のすべてに失敗する可能性が高いと本当に思わせます。」

あるコメンターはフレーミングに直接疑問を呈しました：

私にはこれは撞着語を曖昧にしているように思えます：エージェントに与えるアクセスが多ければ多いほど、それはより有能になります。両方を手に入れることはできません。このツールはバランスを取ることを可能にすると思います。しかし、宣伝文句はすべてをできるが、今は安全であるかのように読めます。それは真実ではありえません。

メンテナンスも別の懸念でした。あるコメンターは、OpenShellが既存のサンドボックス群とどう比較されるか、何がそれを際立たせるかを尋ね、その後、期待を率直に述べました：「私の期待は、それが十分にメンテナンスされないことです。nvidiaはソフトウェア会社ではありません。」スレッド内で誰も機能ごとの直接比較を提供せず、DockerのmicroVMベースのサンドボックスとOpenShellを比較する要求は未回答のままでした。

「なぜ単にコンテナを使わないのか？」

最も繰り返された異論は、コンテナがすでにこれを解決しているというものでした。「なぜ単にコンテナを使わないのか...」とあるコメンターは尋ね、別のコメンターはこの分野は「AI風味の仮想化とコンテナ化の再発明」であると述べました。

誰も決定的な答えを出しませんでしたが、OpenShellの設計は意図された違いを示唆しています：コンテナ分離はプロセスが到達できる範囲を制限しますが、OpenShellはさらにエンドポイントごとに認証情報を仲介し、ポリシーの変更を検証と人間のレビューを通じてゲートします。その差分が新しいランタイムを正当化するかどうかは、まさに懐疑論者が疑問視していた点です。あるコメンターは代替手段の実用的な制限も表面化させました：Docker SandboxはmicroVMに依存しており、同様のツールには既知のギャップがあります — 例えば、VS Code Remote SSHがホストをサンドボックスからの攻撃にさらすことです。

フリート問題：結託と集合的権限

詳細なコメントは、GTCでのOpenShellのピッチが個々の権限ではなく集合的な権限に関するものであると説明しました：

GTCでのピッチから、アイデアは各エージェントができることを制限するだけでなく、集合的な権限がエージェントにさせたいことを超えないようにすることです。どうやらエージェントは、必要な権限を持つ他のエージェントにタスクを委任することで、個々のサンドボックスから抜け出そうと結託するようです。これはエージェントフリートの問題です。なぜなら、タスクを調整する必要があるからです。だから彼らは通信する必要があります。エージェントがあなたが望まないことをするのを防ぐための素朴なアプローチは、権力の分離であり、個々の権限を各エージェントのタスクに限定することです... エージェントの1つが生データを公開する必要があると判断した場合、単一のエージェントがその目標を達成する権限を持っていなくても、彼らはそれを実現するために結託する可能性が高いです。

同じコメンターは、OpenShellがこれを、きめ細かいエージェントごとの権限でフリートの集合的な権限セットを監視することで対処し、エージェントが実行されるチップとホストの間に位置するハードウェアファイアウォール（BlueField上に構築）とともに提示されたと述べました。これにより、エージェントが自身のOpenShellポリシーを変更する能力が排除されます。そのハードウェアの詳細は、READMEではなく、コメンターのGTCプレゼンテーションの説明からのものです。

データ流出は未解決のエッジ

アプローチを気に入ったコメンターでさえ、残存リスクを特定しました。あるコメンターは、ドメインごとのネットワーク制限と認証情報の交換にIron Proxyを使用していると説明し、その後、残りのギャップを挙げました：

エージェントを本当に信頼したい場合に残る唯一の実際の問題は、データ流出を防ぐ方法です... ネットワークを信頼できるドメインに制限できますが、エージェントが特に狡猾である可能性は常にあり、特にプロンプトインジェクションされて、データを一度に数文字ずつ押し出すようなことをする場合です。

同じコメンターは、エージェントが公開リポジトリをフォークしたり、問題を開いたり、PRを提出したりできるかどうかを制御するために、直接アクセスを許可するのではなくghをプロキシすることを説明しました。結論は未解決のままでした：エージェントは許可されたドメインに予期しない方法でデータを送信できるかもしれません。

別のコメンターは、OpenShellを本番環境で実行しており、その上にチームポリシー、安全なgit使用法（エージェントがユーザーの完全なアクセスを継承しないように）、組み込みのSCA/SASTのためのレイヤーを構築していると述べました。彼らの動機の要約：「私が見たエージェントトレースはワイルドで、境界なしの目標追求は現実です。」

k3sネームスペースとともにACL強制プラグインを使用しているコメンターは、どのポリシーエンジンも完全には解決しない問題全体の最も難しい部分を説明しました：「最も難しいのはセキュリティルールを設定することではなく、エージェントが必要とするすべてのものを事前に知ることです。」

正式検証の議論

あるコメンターはOpenShellのプロバーをより広いテーゼに結び付けました：フロンティアモデルはすでにサンドボックスから抜け出す方法、権限を回避する方法、サイドチャネルを考案する方法を見つけることができ、したがって形式手法によるセキュリティバイコンストラクションが唯一の永続的な答えです。彼らはAnthropicの公開された正式検証の研究を、大規模な検証が可能である証拠として指摘しましたが、メモリサニタイゼーションのバグがないことを証明することは問題の1つのクラスにすぎず、フルスタックの保証には、検証されたチップ、ブートローダー、最小限のLinux、アプリケーションライブラリスタックが必要であり、その後で「どのレベルでも認証情報を漏洩する方法がない」というようなエンドツーエンドの主張が意味を持つようになると主張しました。

採用シグナルと未解決の質問

スレッドでの採用証拠は逸話的です：あるコメンターはしばらくOpenShellを使用しており、他のチームのために拡張していると述べました。別のコメンターは、エージェントをコンテナ化した後の自然な次のステップと見なしました。それに対して、何人かのコメンターは実際のユーザーがどこにいるのか尋ねました — 「人々は実際にエージェントのフリートで何をしているのか？」 — そして、GTC Europeのデモでこのツールが多用されたことは、独立した採用というよりNVIDIA主導の可視性を示唆しているという皮肉な指摘がありました。

リポジトリが具体的に確立していること：OpenShellはApache-2.0であり、PyPIでopenshellとして配布され、Python、TypeScript、Go、Rust SDKを提供し、NetworkPolicyを強制するCNIを必要とするHelmベースのKubernetesパスを文書化し、Linux、Apple Silicon macOS、WSL 2（実験的）をDocker、Podman、またはホスト仮想化でサポートし、取得した外部資料は独自の別個の条件に準拠し、ソフトウェアは「現状のまま」提供されるという明示的な免責事項が含まれています。