NVIDIAが公開した内容
NVIDIAは9月28日、エージェントフレームワークを書き換えずにAIエージェントを制約するオープンソースのランタイムOpenShell 0.1.0を公開しました。NVIDIAは、サンドボックスの状態とポリシーを管理するgateway、各ワークロードの外側で外向き要求を検査するsupervisor、カーネルレベルでファイルシステムとプロセスを制限し、ネットワーク経路をsupervisorへ限定するsandboxの3要素を説明しています。
このリリースはマルチテナント運用、CPUとGPUのワークロード、認証情報を保護したサービス接続、外部ガバナンス拡張、ポリシー変更の形式的分析をサポートします。NVIDIAによると、検査型ポリシーはHTTP、GraphQL、Model Context Protocolの読み取りと書き込みを区別でき、判断をOpen Cybersecurity Schema Framework形式で記録します。HPEは別途、Private Cloud AIとの連携を2026年第4四半期に提供予定としています。ここまでは各社の公表内容であり、以下はIneezaの本番運用分析です。
外部の強制点こそ重要な境界になる
Ineezaの分析: シェルを起動し、コードを生成し、子プロセスを実行し、指示を再解釈できるエージェントに自己統制を任せることはできません。ネットワークと認証情報の統制をワークロード外へ移すことで、モデルの推論や選択したツールから独立した境界になります。エージェントがアクセス理由を巧みに説明しても、拒否された要求は拒否されたままです。
この境界にはfail-closedの挙動も必要です。supervisor停止、古いポリシー、gateway分断、DNS変更、不透明なプロトコル、未対応のrequest body、ストリーミング接続、子プロセス実行を試験すべきです。操作を分類できない場合に、メソッド単位の認可から無制限のネットワーク到達性へ暗黙に緩和してはいけません。
認証情報の分離は露出を減らすが、アカウント権限は減らさない
Ineezaの分析: 実際の秘密情報をプレースホルダーに置き換え、許可済みendpointだけで解決すれば、窃取や誤送信のリスクは下がります。しかし接続先のサービスアカウントが持つ権限は狭まりません。proxyポリシーが重要操作を許可した場合やプロトコルを十分に検査できない場合、広い権限のtokenは広い権限のままです。
本番では、接続先の最小権限credentialsとランタイムの要求単位ポリシーを整合させます。rotationとrevocationの証跡にはprovider revision、対象sandbox、反映確認状態、process再起動要否、処理中の要求を含めるべきです。コピーしたplaceholderが別の接続先で失敗すること、detach後に古いprocessが権限を使い続けられないことも試験します。
ポリシー証明には版管理されたセキュリティ境界が必要
Ineezaの分析: 形式的分析は、エージェントの説明ではなくモデル化された権限を評価する点で有用です。ただし保証範囲は、境界定義、protocol model、providerが追加する規則、実際に配置されたpolicy versionまでです。GitHubへの書き込み権限を追加しないという証明だけでは、モデル化されていないtunnel、別エージェントの補完的なアクセス、読み取るデータの業務上の認可までは保証できません。
policy、provider profile、middleware、sandbox image、prover versionを一つの昇格対象として扱います。変更時には、審査可能な権限差分、証明結果、承認者、配置先、rollback参照を記録します。マルチエージェントでは構成後の試験も必要です。個別には許容できる二つのエージェントでも、一方が読み取り、他方が送信できれば許容できない経路を作る可能性があります。
ランタイム権限は業務認可ではない
Ineezaの分析: binaryに許可済みAPI methodへの到達を認めても、現在のtaskでこのcustomer、order、payment、repository、本番recordを変更してよいとは限りません。本人性、tenant境界、transaction上限、職務分離、customer consent、step-up承認は、モデルループ外の決定的なapplication serviceで実施すべきです。
監査証跡は、taskと開始主体をsandbox identity、agentとmodel version、policy判断、credential provider revision、正確なtool request、接続先の認可判断、response、最終的な業務状態へ結び付けます。重複要求、長時間task中のpolicy変更、失効したuser、別tenantのidentifier、接続先での部分成功、supervisorがretryを遮断した後の復旧を運用試験に含めます。
Ineezaの見解
OpenShell 0.1.0は、エージェント封じ込めをprompt上の約束から、操作を検査し認証情報を保護できる独立したランタイム層へ移した点で重要です。堅牢な本番設計は階層的です。ランタイムが到達可能な能力を制限し、接続先システムが業務権限を判断し、end-to-endの証跡が実際に何が変わったかを証明します。単一のsandboxやpolicy proofだけで、この3つの統制を代替することはできません。