メインコンテンツにスキップ

NVIDIA OpenShell入門：AIエージェントを隔離して動かすランタイムの仕組み

技術
解説
AIエージェント
NVIDIA
NVIDIA OpenShellは、自律型AIエージェントをサンドボックスに閉じ込め、ファイル・通信・プロセス・資格情報の4層をエージェントの外から強制するオープンソースのランタイムである。エージェントの内部には手を入れず、実行環境側で…
作者

obelos

公開

2026年11月1日

更新日

2026年11月1日

NVIDIA OpenShellは、自律型AIエージェントをサンドボックスに閉じ込め、ファイル・通信・プロセス・資格情報の4層をエージェントの外から強制するオープンソースのランタイムである。エージェントの内部には手を入れず、実行環境側で制限をかける「プロセス外ポリシー強制」を採る。

設計の核は次の3つである。

  1. カーネルレベルの隔離：Landlockとseccompでファイルアクセスとシステムコールを制限し、外部通信はすべて信頼側のsupervisorを経由させる
  2. 資格情報の非開示：エージェントにはダミー値だけを渡し、許可した宛先への通信に限って本物を差し込む
  3. 形式検証つきの権限変更：エージェントが提案したルールをSMTソルバーで検査し、危険な広がりを含む変更だけを人間のレビューに回す

本記事は公式ドキュメント（v0.1.6）をもとに、この3つがどう実装されているかを整理する。

概要

項目 内容
開発元 NVIDIA（NVIDIA/OpenShell）
ライセンス Apache License 2.0
最新版 v0.1.6。0.1系から安定版を毎週公開し、最新と直前のマイナー版を保守
実装言語 Rust中心。SDKはPython、TypeScript、Go、Rust
実行基盤 Docker、Podman、Kubernetes（Helm）、MicroVM
動作実績のあるエージェント Claude Code、OpenCode、Codex、GitHub Copilot CLI、OpenClaw、LangChain Deep Agents
テレメトリ 匿名の統計を既定で収集。OPENSHELL_TELEMETRY_ENABLED=falseで停止
日付 出来事
2026/10/21 GTC BerlinでOpenShell Reference Architectureを発表
2026/9/28 OpenShellとSentry（BlueField-4上の監視層）を組み合わせたOpen Agent Safety Platformを発表
2026/3/16 GTC 2026でAgent Toolkit・NemoClawとともに初公開

アーキテクチャ

OpenShellは、エージェントと同じ側にいるsandboxと、信頼側にいるsupervisorを分離し、判定を必ずsupervisorに行わせる構造をとる。制御プレーンはgatewayが担う。

図

図
コンポーネント 役割
gateway 利用者の認証、サンドボックスのライフサイクル管理、ポリシーと設定の配布、プロバイダーのアタッチ。Policy Proverもここで動く
supervisor 信頼側でポリシーを判定し、資格情報の付与、DNS解決、承認済み接続の中継を行う
sandbox エージェントを子プロセスとして起動し、実行ファイルの特定とTCP・DNSの横取りを行う。判定はしない
compute driver ワークロードとsupervisorを用意し、境界と外側のネットワーク柵を構築する

通信の経路

  1. エージェントがTCP接続またはDNS問い合わせを行う
  2. sandboxが/procの情報から呼び出し元の実行ファイルを特定する
  3. 要求はOpenShell Sandbox Protocol（相互認証つきHTTP/2）でsupervisorへ渡る
  4. supervisorがポリシーと照合し、許可された資格情報を付与する
  5. 許可ならsupervisorが実際の接続を開き、通信を中継する

この経路がワークロードの唯一の出口である。外側の柵がそれ以外の通信をすべて拒否するため、エージェントはgateway、DNS、社内アドレスにも直接到達できない。各TCP接続には独立したストリームが割り当てられるので、大きなダウンロードがDNSやプロセス制御を塞ぐことはない。

実行基盤ごとの境界の作り方

実行基盤 supervisorの位置 sandboxとの接続 直接通信の遮断
Docker / Podman 専用コンテナ 認証つきUnixソケット ワークロードのネットワークを無効化
Kubernetes 専用Pod 相互TLSのプライベートService NetworkPolicyでsupervisor以外を拒否
MicroVM ホスト上のプロセス 認証つきvsock ゲストにネットワークデバイスを持たせない

実行基盤は境界を作るだけで、通信の許可は判定しない。判定は常に共通のsupervisorとポリシーエンジンが行うため、同じポリシーはどの実行基盤でも同じように動く。

認証と障害時の挙動

gatewayはサンドボックスの実行ごと（世代）に、gateway用とsandbox用のJWTを対で発行する。sandboxはgatewayの公開鍵しか持たないため、トークンを検証はできても偽造はできない。サンドボックスを再起動すると新しい世代になり、古いトークンとTLS証明書は無効になる。

supervisorとの接続が切れると、sandboxはエージェントを凍結する。再開できるのは同じsupervisorプロセスだけで、有効な資格情報を持つ別のsupervisorでも乗っ取れない。

4つの防御層

ポリシーは宣言的なYAMLで書き、ファイル・通信・プロセス・資格情報の4層で防御する。層ごとに、実行中に変えられるかどうかが異なる。

層 防ぐもの 実装 変更の可否
ファイル 許可外パスの読み書き。SSH鍵やクラウド認証情報の読み取り Landlock（ABI 3以上） 作成時に固定
通信 未承認の宛先への送信、情報の持ち出し seccompユーザー通知で横取りしsupervisorで判定 実行中にホットリロード可
プロセス sudoやsetuidによる権限昇格、危険なシステムコール 非特権ユーザー、Linux capabilitiesなし、seccomp 作成時に固定
資格情報 APIキーの漏えい、未承認モデルへの送信 プレースホルダー置換 付与・更新・失効は実行中に反映。新しい環境変数は新しいプロセスから

通信ルールは「どの実行ファイルが、どのホスト・ポートに、どのHTTPメソッド・パスで、つなげるか」まで書ける。同じサンドボックスの中でも、ghにはGitHub APIを許可し、curlには許可しない、といった切り分けができる。

資格情報の差し込み

エージェントの環境変数に入るのは中身のないプレースホルダーである。supervisorは、ネットワークポリシーの許可と、プロバイダープロファイルでの宛先の紐づけの両方が成立したときだけ、通信の中で本物の値に置き換える。一方だけが通った場合はcredential_endpoint_mismatchとして拒否される。

この仕組みにより、エージェントがプロンプトインジェクションで乗っ取られて環境変数を外部に送っても、漏れるのはプレースホルダーだけになる。sandbox側にはgatewayの署名鍵、gateway用JWT、プロバイダーの資格情報のいずれも置かれない。

権限の追加：Policy Advisor

Policy Advisorは、拒否されたエージェントが必要な通信ルールを自分で申請し、人間または自動判定がそれを承認する仕組みである。対象は通信ルールの追加だけで、削除やファイル・プロセスの設定変更は提案できない。既定では無効で、有効にしても既定では全件が人間のレビュー待ちになる。

図

図
  1. エージェントの通信が拒否される。検査対象のHTTP通信では、拒否応答に何が止められたかと申請方法が載る
  2. エージェントはサンドボックス内のガイド（/etc/openshell/skills/policy_advisor.md）を読み、http://policy.localへルール案を送る
  3. OpenShellがPolicy Proverのリスク検査と宛先のフラグ付けを行い、結果とともに保留中の提案へ加える
  4. 人間が承認または却下する。自動承認を有効にすると、指摘のない提案は待たずに承認される
  5. 承認されたルールは再起動なしで読み込まれ、エージェントは再試行する。却下理由と検査結果はエージェントに返り、より狭い案を出し直せる

Advisorを無効にしていても、OpenShellは拒否した接続から「1実行ファイル・1ホスト・1ポート」のルール案を自動で下書きし、同じ検査とレビューに回す。

提案の形

良い提案は、タスクに必要な最小のメソッドとパスに絞ったものである。公式ドキュメントの例では、ghに特定リポジトリのdocs/配下へのPUTだけを許可する。

{
  "intent_summary": "Allow gh to update documentation in NVIDIA/OpenShell.",
  "operations": [
    {
      "addRule": {
        "ruleName": "github_contents_docs_write",
        "rule": {
          "name": "github_contents_docs_write",
          "endpoints": [
            {
              "host": "api.github.com",
              "port": 443,
              "protocol": "rest",
              "enforcement": "enforce",
              "rules": [
                { "allow": { "method": "PUT", "path": "/repos/NVIDIA/OpenShell/contents/docs/**" } }
              ]
            }
          ],
          "binaries": [ { "path": "/usr/bin/gh" } ]
        }
      }
    }
  ]
}

protocol: tcpやtls: skipなど、中身を検査できないルールは提案できない。GraphQL、MCP、資格情報設定の項目も受け付けず、送られても無視する。ループバック、リンクローカル、クラウドのメタデータアドレスは常に遮断され、承認もできない。

自動承認されない条件

Proverのリスク検査は、ルールを足す前と後で届く範囲を比べ、次の広がりを検出する。

検出 内容
link_local_reach リンクローカルアドレス（169.254.0.0/16、fe80::/10）やクラウドのメタデータホストへ届く
l7_bypass_credentialed git、ssh、ncなど中身を検査できない通信で、資格情報のあるホストに届く
credential_reach_expansion 資格情報を新しいホスト・ポートで使える
capability_expansion 資格情報を使う宛先で、新しいHTTPメソッドが使える

これに加え、プライベートIPで書かれたホスト、ワイルドカードのホスト、49152より上のポート、DBやキャッシュの代表的なポート（5432、6379など）は宛先フラグが付き、自動承認の対象外になる。逆に、資格情報を伴わない新しい公開ホストへのアクセスはリスクとみなされない。自動承認を有効にすると、公開ホストへの到達範囲はレビューなしで広がる点に注意が必要である。

操作

# 有効化（gateway全体）
openshell settings set --global --key agent_policy_proposals_enabled --value true --yes
# 自動承認（既定は manual）
openshell settings set --global --key proposal_approval_mode --value auto --yes

# 保留中の提案を確認して承認・却下
openshell rule get <sandbox> --status pending
openshell rule approve <sandbox> --chunk-id <id>
openshell rule reject <sandbox> --chunk-id <id> --reason "Scope this to docs/ paths only."

gateway全体の設定はサンドボックス単位の設定より優先されるため、管理者はmanualをgatewayに設定して全件レビューを強制できる。エージェント側はpolicy.localのAPIで、現在のポリシー取得（GET /v1/policy/current）、直近の拒否履歴（GET /v1/denials）、提案（POST /v1/proposals）、結果待ち（GET /v1/proposals/{id}/wait）を行う。

Policy Prover：形式検証による上限チェック

Policy Proverは、SMTソルバーでポリシーが指定した性質を満たすかを検証するエンジンである。用途は2つある。

検査 問い 使われ方
リスク検査（proposal risk check） このルールを足すと、現在のポリシーより危険な到達が増えるか Policy Advisorが提案ごとに自動実行
境界検査（boundary check） このポリシーは、組織が定めた最大権限を超えていないか openshell-proverコマンドで実行。CIや、親エージェントが子エージェント用ポリシーを書くときの検算

2つは別の問いに答えるため、一方に合格してももう一方に合格するとは限らない。

境界検査の例

組織の最大権限をboundary.yaml、検査対象をcandidate.yamlとして比べる。gatewayは不要で、ローカルのファイルだけで動く。

# boundary.yaml
version: 1
filesystem_policy:
  read_only:
    - /usr
    - /etc
# candidate.yaml
version: 1
filesystem_policy:
  read_only:
    - /usr
  read_write:
    - /tmp
openshell-prover check candidate.yaml --boundary boundary.yaml
result: exceeds_boundary
coverage: domains=filesystem,network_l4,network_rest,process,landlock
counterexample: filesystem write /tmp

上限を超えた場合は、超えた具体例がcounterexampleとして返る。稼働中のサンドボックスを検査するには、openshell sandbox get <name> --policy-onlyで実効ポリシーを取り出して候補にする。実効ポリシーにはプロバイダー由来のルールも含まれる。

結果 終了コード 意味
within_boundary 0 検査できる領域で上限を超えない
exceeds_boundary 1 上限を超えるアクセスがある
error 2 ファイル不在、ポリシー不正などで検査できない
unsupported 3 検査できない記述を含む
inconclusive 3 時間切れ、または規模超過

合格はwithin_boundaryだけで、それ以外はすべて不合格として扱う。

検査できる範囲

対象はファイルアクセス、プロセスID、Landlock設定、TCP接続、RESTリクエストの5領域である。GraphQL、MCP、WebSocket、JSON-RPCのルールを含むとunsupportedを返し、無視して合格にすることはない。シンボリックリンクによる参照先のずれを避けるため、/tmpと/tmp/cacheのような包含関係のパスの比較もunsupportedになる。ネットワークルールが1,024件、エンドポイントが4,096件を超えるとinconclusiveを返す。

合格が示すのは「上限を超えない」ことだけで、権限が必要最小限であること、稼働中のサンドボックスが実際にそれを強制していることまでは保証しない。

推論接続：プロバイダープロファイルとローカルモデル

LLMへの接続も、他の外部通信と同じくプロバイダープロファイルで管理する。ワークロードは各ベンダーのネイティブAPIをそのまま呼び、OpenShellはプロファイルが許可した宛先でだけ資格情報を差し込む。

設定対象 担当
資格情報とその更新 プロバイダー（provider）
許可するホスト・ポート・パス・実行ファイル プロファイル（profile）
どのサンドボックスに使わせるか アタッチ（sandbox provider attach）
ベースURL・モデル名・タイムアウト ワークロード側のクライアント

自社サーバー上のモデルは、宛先を明示した専用プロファイルで接続する。gatewayホスト上のOllamaなら次のようになる。サンドボックスからはlocalhostではなくhost.openshell.internalで参照する。

id: ollama-openai
display_name: Ollama
description: Host-local Ollama OpenAI-compatible API
category: inference
inference_capable: true
credentials: []
endpoints:
  - host: host.openshell.internal
    port: 11434
    protocol: rest
    access: read-write
    enforcement: enforce
binaries:
  - /usr/bin/curl
  - /usr/bin/python3
  - /sandbox/.venv/**
openshell profile lint -f ollama-openai.yaml
openshell profile import -f ollama-openai.yaml
openshell provider create --name ollama --type ollama-openai
openshell sandbox create --name ollama-client \
  --from registry.example.com/team/python-agent:1.0 \
  --provider ollama \
  --env OPENAI_BASE_URL=http://host.openshell.internal:11434/v1 \
  -- python app.py

openaiやanthropicの公式プロファイルを別のホストに流用しても、資格情報はそのホストに運ばれない。公式プロファイルは資格情報を公開ベンダーの宛先に紐づけているためである。

0.1系では、ワークスペース共通の管理推論ルート（inference.localとopenshell inferenceコマンド）が廃止され、サンドボックスごとのプロバイダーアタッチに一本化された。旧方式は1つのモデルをワークスペースの全サンドボックスに割り当てていたが、新方式は必要なサンドボックスだけに権限を与える。外部の解説記事や連携ライブラリには旧方式のコマンドが残っているので、版を確認して使う。

対応環境・制約・エコシステム

対応環境

プラットフォーム アーキテクチャ 状態
Linux（Debian/Ubuntu） x86_64 対応
Linux（Debian/Ubuntu） arm64 対応
macOS（Docker Desktop） Apple Silicon 対応
Windows（WSL 2＋Docker Desktop） x86_64 試験提供
ネイティブWindows（MXC） x86_64、ARM64 windowsブランチで開発中

サンドボックスの境界には、コンテナやMicroVMの内側でも次のカーネル機能が必要になる。いずれも起動前に実際に試して確認され、満たさない場合は起動を拒否する。macOSではDocker DesktopのLinux VM内でこの条件を満たす。

  • Landlock LSM（ABI 3以上、Linux 6.2以降で有効化されていること）
  • seccompの入れ子ユーザー通知フィルタとSECCOMP_IOCTL_NOTIF_ADDFD
  • 子プロセスのメモリ参照（process_vm_readvまたは/proc/<pid>/mem）
  • SO_BINDTODEVICEによるソケットのループバックへの固定

Dockerは28.0以上、Podmanは5.x、Kubernetesは1.29以上が必要である。導入は次の2コマンドで始められる。既定のワークロードは最小構成のUbuntu 24.04（amd64/arm64）で、エージェントは入っていない。

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

制約

  • リリースの速度：安定版は毎週公開され、保守対象は最新と直前のマイナー版だけである。0.1.0では推論ルートの廃止や、公開APIでのサンドボックスID参照の廃止などの破壊的変更があった
  • Proverの対象領域：GraphQL、MCPなどのルールは形式検証の対象外
  • Kubernetes：CNIがNetworkPolicyを強制できることが前提

エコシステム

2026/9/28に発表されたOpen Agent Safety Platformは、OpenShellとSentryの2層でできている。SentryはBlueField-4 DPU上でホストと別の信頼ドメインで動く監視層で、ホストやワークロードが侵害されても動作を続ける設計である。OpenShellと異なりオープンソースではなく、参照設計として提供される。OpenShell自体はBlueField-4なしで動く。

2026/10/21のOpenShell Reference Architectureは、推論をVera Rubin、エージェントの実行をVera CPU、統制をBlueField-4に割り当てる構成である。エッジ向けにはDGX Spark、DGX Station、RTX Sparkが挙げられている。

連携先 内容
Anthropic Claude Managed AgentsをOpenShellとBlueFieldに接続
Salesforce 権限追加の申請をSlackで承認・却下
SAP Joule Studioの実行環境にReference Architectureを統合
LangChain Deep Agentsの実行先としてOpenShellを使う連携パッケージを公開
Dell、Cisco、HPE、Lenovo、Supermicro Reference Architectureに対応したインフラを構築

関連記事

OpenShellが発表された基調講演は、次の記事で整理しています。

NVIDIA GTC Berlin 2026基調講演まとめ｜DSX POD・OpenShell・フィジカルAIの発表を解説

機能と安全性を両立させるハーネスの研究は、次の記事で紹介しています。

AIエージェントは「自分の仕組み」をどう鍛えるか──Harmony Harness論文を読む

Microsoft Entraのアクセス制御は、次の記事で解説しています。

Microsoft Entra 条件付きアクセスの「ポリシープラン」解説（プレビュー）

参考資料