Dockerの死角：一つのホスト、二つの全く異なるアクション
Dockerはプロセス分離に優れていますが、根本的な死角が残されています。それは、ネットワークリクエストの背後にある「意図」を識別できないという点です。基本的なネットワークの許可リストでは、エージェントが試みるアプリケーション層のアクションに関係なく、GitHubへのすべてのアウトバウンド接続を同一のトラフィックとして扱ってしまいます。
Dockerコンテナ内でGitHubトークンを保持しているエージェントを例に挙げます。コンテナから見れば、リポジトリデータを読み取るリクエスト（GET）と、Issueを作成するリクエスト（POST）は、同じサービスに向けられた同等のトラフィックに見えます。Dockerのレイヤー3/4での制御には、これら全く異なる操作を区別するためのセマンティックな認識能力が欠けており、重大なセキュリティギャップが生じています。
コンテナは実行環境をカプセル化し、堅牢なセキュリティ層を提供する上で依然として非常に有用です。しかし、ネットワークの到達可能性のみを許可されたアクションの判断基準に依存する場合に限界が生じます。従来のモデルは「エージェントはそのエンドポイントに到達できるか？」を問うものですが、より重要な「エージェントはそのアクセス権を使って何ができるのか？」という問いには答えられていません。
この死角は、サンドボックス化に対してより粒度の細かい、アプリケーションを認識したアプローチが必要であることを浮き彫りにしています。Dockerはエージェントのプロセスをホストから分離することには成功していますが、特定のAPIアクションを制御するきめ細やかな「アプリケーションレベルのポリシー」を表現できないため、重要な操作が無防備なまま放置されてしまいます。
違いを明らかにするcurlテスト
従来のネットワークセキュリティはエージェントがターゲットに到達できるかを問いますが、より深い問いは、接続後にどのようなアクションを実行できるかです。この重要な違いを説明するために、コンテナ内からGitHub APIに対して「curl」テストを実行してみましょう。初期状態では、リクエストはデフォルトで拒否されます。
次に、ポリシーを更新してGitHub APIへの読み取り専用アクセスを許可します。この変更はコンテナやエージェントを再起動することなく適用され、即座に「curl」コマンドによるデータ取得が可能になります。同じホストから同じツールを使用して、APIとの対話が成功するようになります。
しかし、重要なテストはここからです。GitHubのIssueを新規作成するために「POST」リクエストを試みます。全く同じ「curl」コマンドを使用し、同じAPIエンドポイントをターゲットにしているにもかかわらず、この書き込み操作は拒否されます。ポリシーが読み取りのみを許可し、書き込みを許可していないためです。
これはアプリケーション層の検査の威力を示しています。GitHubへのすべてのトラフィックを区別なく扱う基本的なIP/ポートルールとは異なり、NVIDIA OpenShellのような高度なサンドボックスは、HTTPメソッド（GET対POST）や特定のAPIパスに基づいてルールを適用できます。このセマンティックな認識により、有効なトークンを持っていてもエージェントの能力は意図した範囲に制限され、意図しない、あるいは悪意のあるアクションを防ぐことができます。
OpenShellがガードレールをランタイムに移行
NVIDIA OpenShellは、セキュリティ境界をコンテナホストから「エージェントランタイム」へと移行させます。Apache 2.0ライセンスで公開されているこのオープンソースのサンドボックスは、Dockerの代替品ではなく、自律型AIエージェント専用のポリシー適用層を提供します。OpenShellは、従来のネットワーク許可リストよりもはるかに細かい粒度でエージェントのアクションを監視します。
オペレーターはYAMLを使用して宣言的ポリシーを定義し、OpenShellがそれをOpen Policy Agent (OPA/Rego) ルールにコンパイルします。これらのポリシーにより、HTTPを認識した制御が可能になり、メソッド（例: GET 対 POST）、特定のパス、および許可されたバイナリ（例: /usr/bin/curl）に対する詳細な制限を設定できます。重要な点として、ワークフローで示されているように、ポリシーの変更は実行中のエージェントを再起動することなく反映されます。
OpenShellの設計はネットワークトラフィックの枠を超えています。LinuxのLandlock LSMおよびseccompプロファイルを採用し、ファイルシステムとプロセスを制限する多層的な分離機能を備えています。これにより、特権昇格や不正なシステムコールを拒否します。さらに、クレデンシャルブローカー機能がセキュリティを強化し、エージェントがAPIシークレットを直接保持することを防ぎます。リクエストが許可されたエグレスルールと一致する場合にのみ実際のトークンが注入されるため、プロンプトインジェクションのリスクを軽減します。
基礎となるメカニズムや実装の詳細については、プロジェクトのページをご覧ください: NVIDIA OpenShell: Runtime for Autonomous AI Agents。この包括的なアプローチは、エージェントがどこにアクセスできるかだけでなく、何ができるかを定義し、エージェントを封じ込めることを目的としています。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
読み取り専用でもリスクはゼロではない：境界を知る
きめ細かな制御を行っても、読み取り専用アクセスにリスクがないわけではありません。GETリクエストであってもクエリ文字列やヘッダーを介してデータを流出させる可能性があるため、ポリシーはHTTPメソッド以外の要素も考慮する必要があります。厳格なルールでは、単にPOSTやDELETE操作をブロックするだけでなく、特定のパス、パラメータ、および許可されたスキーマを制限する必要があるかもしれません。
運用上の制限にも注意が必要です。未知のエンドポイントの自動承認や、従来の強制レイヤーでは解析が困難なRaw WebSocketやGraphQLといった複雑なプロトコルの見落としにより、ポリシーの隙間が生じる可能性があります。NVIDIA OpenShellのスーパーバイザーはHTTPトラフィックをプロキシおよび検査し、宣言的なYAMLポリシーをOpen Policy Agent (OPA/Rego) ルールにコンパイルします。
OpenShellは、多層防御戦略における重要なレイヤーの一つとして扱ってください。現実的なプロンプトインジェクションのシナリオに対してポリシーをテストし、エージェントがアクセスできるクレデンシャルを最小限に抑え、ランタイムが実際に何を検査しているかを確認してください。サンドボックス内のエージェントはAPIシークレットを直接保持しません。代わりに、リクエストが許可されたエグレスルールと一致した場合にのみ、アップストリームのゲートウェイによって実際のトークンが外部から注入されます。
より深い洞察と実装については、OpenShell GitHubリポジトリおよびNVIDIAの包括的なドキュメントをご覧ください。OpenShellはLinuxのLandlock LSMおよびseccompプロファイルと統合されており、ファイルシステムとプロセスの制御を行い、特権昇格や不正なシステムコールを拒否します。
よくある質問
なぜDockerだけではAIエージェントのセキュリティとして不十分なのですか？
Dockerはプロセスを分離しますが、通常のネットワークルールでは、エージェントが行うAPIアクションではなく、宛先に基づいて接続を許可またはブロックするのが一般的だからです。
NVIDIA OpenShellは何を追加しますか？
OpenShellは、HTTPメソッドや宛先の制御を含む、エージェントに特化したポリシーを適用するために設計されたオープンソースのランタイムです。
OpenShellでGitHubの読み取りを許可しつつ、書き込みをブロックすることはできますか？
はい。ポリシーによって、許可された読み取りリクエストと、Issueを作成するためのPOSTのような許可されていない書き込みリクエストを区別できます。
読み取り専用のAPIアクセスでデータ流出のリスクはなくなりますか？
いいえ。クエリ文字列、ヘッダー、サポートされていないプロトコル、または過度に寛容なルールは依然としてリスクを生む可能性があり、慎重なポリシー設計が必要です。