コンテナは部屋であり、権限システムではない
AIエージェントは重大な新しいリスクをもたらします。開発者はClaude CodeやCodexのようなツールに機密性の高いリポジトリ、API、認証情報への広範なアクセス権を日常的に付与し、そのまま無人で実行させています。この利便性は多くの場合、セキュリティを犠牲にして成り立っています。なぜなら、エージェントの有用性は重要なリソースへのアクセス権に直結しているからです。
通常のコンテナはホストの分離には有効ですが、微妙なアクションの違いを判別することはできません。例えば、GitHubへの接続はデータの読み取りと破壊的な変更の両方を許可してしまいます。コンテナは同じアドレスへのトラフィックとしてしか認識できず、エージェントがコードを閲覧しているだけなのか、それとも積極的にIssueを作成しているのかを判別することはできません。
NVIDIAの新しいオープンソースサンドボックスであるOpenShellは、このギャップに対処します。Rustで記述され、Apache 2.0ライセンスの下で提供されるOpenShellは、リソースにアクセスできるかどうかだけでなく、エージェントがそのアクセス権を使って「何ができるか」を制御します。重要な点として、NVIDIA GPUは不要であり、標準的なハードウェアで動作します。
OpenShellのポリシーファースト設計は、ファイルアクセス、システムコール、ネットワーク接続に対するきめ細かな制御を強制します。デフォルトで拒否する姿勢で動作するため、明示的に許可されない限り、エージェントは何もできません。この詳細な強制力は、基本的なコンテナ化を大きく超える飛躍です。
バウンサー（用心棒）がすべての出口をチェックする
OpenShellは3つの主要コンポーネントをマッピングします。インターフェースとコントロールプレーンとして機能するGateway、ポリシーを強制し認証情報を仲介するSupervisor、そしてエージェントが実行される制約付き環境を提供するSandboxです。Sandboxの唯一の出口経路はSupervisorを経由するため、すべての外部とのやり取りが仲介されることが保証されます。
デフォルト拒否の動作は、OpenShellのセキュリティモデルの中心です。カーネルレベルのファイルシステムおよびプロセス制限により、不正なパスや権限昇格が最初からブロックされます。エージェントからのネットワークリクエストはすべてSupervisorを通過する必要があり、定義済みのポリシーと照らし合わせて精査されます。
例えば、curlバイナリがGitHub APIに対して読み取り専用のリクエストを行うことを許可するポリシーを考えてみましょう。Supervisorはこれを許可します。しかし、同じcurlバイナリが未承認のPOSTリクエストでIssueを作成しようとすると、Supervisorはそれを拒否します。これらのポリシーはサンドボックスを再起動することなくopenshell policy updateでライブ更新でき、すべての拒否はログに記録されるため、明確な監査証跡が提供されます。
重要なのは、エージェントが認証情報を直接扱うことが決してないという点です。Supervisorは承認されたリクエストに対してのみトークンを挿入するため、プロンプトインジェクションによる漏洩を防ぎます。DNS解決でさえもSupervisorを経由して行われるため、エージェントの可視性と制御は制限されます。この設計により、エージェントが侵害されたとしても、漏洩させるべき鍵は存在しません。
巧妙な点：エージェントは決して鍵を保持しない
OpenShellの最も独創的な機能は認証情報のマスキングです。エージェントは機密性の高いAPIキーやトークンを直接保持しません。その代わりに、Supervisorがこれらの秘密情報を保持し、確立されたポリシーに合致する承認済みの送信リクエストに対してのみ注入します。この設計により、エージェントが漏洩させる認証情報が存在しないため、プロンプトインジェクションの攻撃対象領域が大幅に削減されます。
ポリシー変更が適用される前に、OpenShellはZ3 solverを使用して形式検証を行います。この数学的エンジンは提案されたポリシーの変更を評価し、新しく付与されるアクセス権の全範囲を計算します。この事前のチェックは、意図しないワイルドカードや過度に広範な権限など、リスクの高いルールを露呈させるのに役立ち、それらがデプロイされるのを未然に防ぎます。
代替手段は存在します。Dockerは基本的な分離を提供し、AnthropicのSandbox Runtimeはより軽量なセットアップを提供し、E2BやDaytonaのようなホスト型ソリューションは管理された実行環境を提供しますが、OpenShellは独自のニッチな領域を切り開いています。OpenShellは、Docker、Podman、Kubernetesなどのコンテナランタイム上で動作する、ポリシー主導型の自己ホスト型エージェント制御に重点を置いています。基盤となるアーキテクチャやオープンソースへの貢献に関心がある方は、NVIDIA/OpenShell on GitHubからプロジェクトにアクセスできます。
OpenShellは、「エージェントはそこにアクセスできるか？」という問いから、「エージェントに何ができるか？」という考え方への転換を表しています。NVIDIAのテレメトリレポートによると、この夏の2週間でOpenShellは55万以上のサンドボックスを作成し、420万件のエージェントアクションを拒否しており、エージェントの境界を強制する上での積極的な役割を強調しています。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
セキュリティの防壁ではなく、有用なガードレール
OpenShellはセキュリティの防壁ではなく、有用なガードレールを提供します。Cisco、CrowdStrike、Google Cloud、Microsoft Securityといったエコシステムからの注目を集めているものの、プロジェクトのバージョンはまだ0.1.5であり、「早期プレビュー」とラベル付けされていることからも初期段階であることがわかります。テレメトリはデフォルトで有効になっており、イベントを匿名でカウントしますが、環境変数で無効にすることも可能です。
Macユーザーは、OpenShellのサンドボックスがLinuxベースであり、Docker Desktopの仮想マシン内で実行されることに注意してください。これにはLandlockやホストネットワークなどのカーネル機能が必要ですが、これらはデフォルトでオフになっていることが多いです。NVIDIAのdoctorコマンドが正常と報告する場合でも、テストを行うことを推奨します。
NVIDIAの内部テレメトリは、2週間で55万件以上のサンドボックス作成と420万件のエージェントアクション拒否という驚異的な活動を報告しています。これらの数字は、OpenShellが阻止するエージェントの暴走の規模を浮き彫りにしています。ただし、NVIDIAは同期間中にサンドボックス作成の約12%が失敗したことも報告しています。これらは同社のテレメトリ数値であり、独立した監査によるものではありません。
Claude Codeのようなツールを使ったよりシンプルなローカルコーディングであれば、基本的なコンテナやAnthropic Sandbox Runtimeで十分かもしれません。しかし、実際の認証情報や長期間実行される監視なしのタスクを扱うエージェントの場合、OpenShellのリクエストごとのルールや認証情報のマスキングは非常に価値があります。サンドボックス化はリスクを軽減しますが、すべての潜在的な脆弱性を排除できるわけではないため、慎重なポリシー設計が依然として重要です。
よくある質問
NVIDIA OpenShellとは何ですか？
OpenShellは、エージェントの外部で強制されるポリシーを通じて、AIエージェントのファイル、プロセス、ネットワークへのアクセスを制限するためのオープンソースランタイムです。
OpenShellにはNVIDIA GPUが必要ですか？
いいえ。ビデオではMac上で動作している様子が示されており、OpenShellはNVIDIA GPUハードウェアに依存していません。
OpenShellとDockerの違いは何ですか？
Dockerはコンテナを分離しますが、OpenShellは、どのプロセスが特定のネットワークエンドポイントや操作にアクセスできるかといったルールを含む、きめ細かな制御を追加します。
OpenShellはすべてのAIエージェントのセキュリティリスクを防げますか？
いいえ。エージェントがアクセスできる範囲を制限しますが、完全なセキュリティ保証ではありません。構成、分離境界、ソフトウェアの成熟度が依然として重要です。