AI エージェントには目標を設定できるほか、コードの記述とツールの使用も可能で、さらに新たな情報が利用可能になった際にも動作を継続することができます。これにより、ソフトウェアの障害を調査し、実験を実行し、数日または数週間かけてビジネスに不可欠なアクションと研究を行うアプリケーションの扉が開かれます。
有用なエージェントは、ワークスペース、コンピューティング リソース、データ、認証情報、外部サービスにアクセスする必要があります。しかし、アクセス範囲が広がると、本番環境のデータの変更や機密情報の漏えい、割り当てられたタスクの範囲を超えた行動など、より重大な問題が発生するリスクも高まります。
NVIDIA OpenShell 0.1.0 は、エージェントがアクセスできるシステムとデータを定義し、適用するためのオープンソースのランタイムです。 サンドボックス実行、制御されたサービスへのアクセス、認証情報の管理、形式的ポリシー分析を組み合わせています。チームは、タスクに必要な機能をエージェントに付与でき、OpenShell はワークロードの外側でそれらの権限を実施します。
Codex、Claude Code、Pi、Hermes、そして将来のフレームワークをサポートします。これは、社内のエージェント フリートや長期的な研究から、ロボティクスやエッジ システムに至るまで、エンタープライズ アプリケーション、フロンティア研究、フィジカル AI 全般にわたります。
この投稿では、NVIDIA OpenShell 0.1.0 が、既存の AI エージェントを書き換えることなく強制可能なランタイム制御を組み込む方法を説明します。これにより、チームはエージェントのワークロード外で API 操作の制限、認証情報の保護、権限の変更のレビューを行うことができます。
OpenShell は、より広範な NVIDIA Open Agent Safety Platform のランタイム レイヤーを提供し、アプリケーション、ランタイム、インフラストラクチャの各レイヤーにわたって保護を拡張します。
組織が OpenShell を採用している方法
OpenShell はオープン ソースであり、幅広いパートナー エコシステムを通じて企業向けに導入が可能で、そのエコシステムが製品自体を形作っています。チップ設計、エンタープライズ オートメーション、アクセラレーテッド コンピューティング、フィジカル AI など、さまざまなアプリケーションで、組織が OpenShell を採用しています。
- Cadence は、ChipStack Autonomous RTL Design Engineer により、チップ設計に OpenShell を使用しています。
- Slack は、タスクを自動化する OpenShell 上でオンデマンド エージェント プラットフォームを構築しています。
- Gecko Robotics は OpenShell を使用して、フィジカル ロボット上で意思決定を行うエージェントを制御します。
OpenShell 機能
OpenShell 0.1.0 は、サンドボックス操作、ポリシー検証、ガバナンスの統合、認証情報の保護、柔軟なコンピューティングをサポートします。
| 機能 | どのように役立つか |
|---|---|
| マルチテナント プラットフォームのサポート | 共有インフラストラクチャ上で個別のワークスペース、権限、サービス アクセスにより、複数のチームまたは顧客向けにエージェント サービスを運用します。 |
| 正式なポリシー検証 | 人間と AI のレビュー担当者に、リクエストされた権限が定義されたセキュリティ境界内にあるかどうかを示し、どこで制限を超えたかを特定します。 |
| 拡張可能なセキュリティとガバナンス | サードパーティのセキュリティ サービス、ガバナンス システム、およびカスタム チェックを、エージェント ワークロード外の強制ポイントに接続します。 |
| 認証情報で保護されたサービスへのアクセス | 実際の認証情報をエージェントのワークロードの外に保持し、承認済みのリクエストに紐付けた状態で、認証済みサービスを使用します。 |
| CPU と GPU の実行 | コンテナー、VM、Kubernetes 環境全体で、CPU または GPU 上で実験とデータ処理を実行します。 |
エージェント外で権限を強制する
エージェントは、命令を解釈し、ツールを選択し、時間の経過とともにアプローチを進化させることができます。 OpenShell は、その柔軟性を維持しながら、エージェント ワークロード外で権限を強制します。
OpenShell は、それぞれ独自の権限を持つ多数のエージェントとそのサンドボックスを管理し、一度に複数のグループにわたるガバナンスを可能にします。この制御は、次の 3 つのコンポーネントによって提供されます。
- OpenShell Gateway: 多くのサンドボックスのライフサイクルとポリシーを管理します。
- OpenShell Supervisor: 各サンドボックスと組み合わせることで、エージェント ワークロードの外部で実行され、ポリシーと照らしてアウトバウンド リクエストをチェックします。
- OpenShell Sandbox: ファイル システムとプロセスをカーネル レベルで制御することでワークロードを実行し、スーパーバイザーを介した以外にネットワーク パスを確立しません。
OpenShell サンドボックス ランタイムは、オペレーティング システムのカーネル制御を使用し、ワークロードが読み取るまたは変更できるファイルを制限し、追加のシステム特権を獲得するのを防止します。 ネットワーク アクセスについては、特定のサービスへの接続を許可するだけでなく、より具体的な指定を行うことができます。監督者は、構成済みの HTTP、GraphQL、Model Context Protocol (MCP) トラフィックを検査できるため、同じ API を通じて書き込みをブロックしながらデータ クエリを実行できます。これらの制御は、エージェントがシェルを開始、生成されたコードを実行、子プロセスの起動、またはサブエージェントへのタスク委任の提案を行う際にも、そのまま適用されます。 OpenShell は、Open Cybersecurity Schema Framework (OCSF) 監査トレイルにポリシーの意思決定を記録します。 インスペクトされたリクエストをブロックすると、エージェントの次の行動の判断に役立つ記述的なエラーを返すことができます。
ポリシーの意思決定を見る
この例では、GitHub REST API で curl と未認証のエンドポイントを使用し、API キーや言語モデルを必要とせずに、各ポリシーの決定を可視化します。 エージェントがリクエストを行った場合にも、同じ制御が適用されます。
インストール ガイドに従って、OpenShell 0.1.0 をインストールおよび起動します。次に、付属の no-network.yaml ポリシー ファイルと github-readonly.yaml ポリシー ファイルをサンプル ディレクトリにダウンロードします。
まず、アウトバウンド ネットワーク アクセスのないサンドボックスを作成します。
openshell sandbox create --name policy-demo \
--no-auto-providers \
--policy examples/no-network.yaml
create コマンドは、サンドボックス内のシェルを起動します。 パブリック エンドポイントを試す:
curl -sS --max-time 10 https://api.github.com/zen
そのサンドボックスにはアウトバウンド ネットワークの許可がないため、このリクエストは失敗します。ホストで 2 つ目のターミナルを開き、ログを確認して、どのプログラムがリクエストを行ったか、なぜブロックされたかを確認します。
openshell logs policy-demo --since 5m
次に、サンドボックス ポリシーを、GitHub REST API への読み取り専用アクセスを許可するポリシーに置き換えます。 ポリシーは YAML で作成され、OPA/Rego にコンパイルされ、OpenShell が各アウトバウンド リクエストについて評価します。
network_policies:
github_api:
name: github-api-readonly
endpoints:
- host: api.github.com
port: 443
protocol: rest
enforcement: enforce
access: read-only
binaries:
- path: /usr/bin/curl
このルールにより、/usr/bin/curl はポート 443 で GitHub API に到達します。OpenShell は、プロトコル: rest により、HTTP リクエストを検査し、書き込みをブロックしながら読み取りを可能にします。
ホスト端末では、サンドボックスを再起動することなく、完全な置換ポリシーを適用してください。
openshell policy set policy-demo \
--policy examples/github-readonly.yaml --wait
サンドボックス シェルに戻り、両方のリクエストを試してください。
# Read: allowed
curl -sS --max-time 10 https://api.github.com/zen
# Write: blocked
curl -sS --max-time 10 -X POST https://api.github.com/zen
OpenShell が POST をブロックしたことを確認するには、ホスト ログを再度確認してください。 これらのコマンドを実行するエージェントも、同様の制限に直面します。
認証情報を公開することなくサービスにアクセスする
多くのエージェントは、タスクを完了するために、モデル API やプライベート サービスを必要とします。 OpenShell は、実際の認証情報をエージェント ワークロードの外部に保持しながら、アクセスを承認します。
あるサービスに対して認証をしても、その認証情報が別のサービスで利用可能になることはありません。エージェントがプレースホルダーを認証情報の承認済みエンドポイント以外の場所に送信した場合、OpenShell はそのリクエストを拒否します。
受信サービスは、引き続き、実際の認証情報に添付された権限を強制します。 OpenShell は、エージェントがそれをどのように活用するかについて、別の制御を追加します。 たとえば、検査された読み取り専用の API ポリシーは、認証情報自体に書き込みアクセス権がある場合であっても、書き込みリクエストをブロックできます。
プロバイダー プロファイルは、サービスに対して、認証情報、エンドポイント、および許可されたプログラムを定義します。github という GitHub プロバイダーがすでに構成されていると仮定し、それを新しいサンドボックスに接続して、Codex を追加します。
openshell sandbox create \
--provider github \
-- codex
エージェントの実行中にネットワーク アクセスを調整する
エージェントは、タスク開始当時はまだ知られていなかったサービスやデータソースを必要としていると判断することがあります。 ポリシーがリクエストをブロックすると、OpenShell がその拒否を記録することで、オペレーターまたは AI エージェントの承認者がレビューできるようにします。 ポリシー アドバイザーを有効にすることで、エージェントは、狭い範囲のネットワークまたはファイル ポリシーの変更を提案できます。この提案は、デフォルトでは人間によるレビューを待機している状態であり、エージェント自体はリクエストを承認することはできません。承認後、OpenShell は新しいルールを実行中のサンドボックスにロードするため、エージェントは作業を再起動することなく再試行できます。
ファイル システムとプロセスの制限は、サンドボックスが起動するときに確立されます。 これらの制御を変更するには、新しいサンドボックスが必要です。
以下のコマンドを使用して、サンドボックスのポリシー アドバイザーを有効にします。
openshell settings set <sandbox-name> \
--key agent_policy_proposals_enabled \
--value true
ポリシーで付与される権限を確認する
ポリシーは、他のルートが開いたままの状態でも、制限的に見える場合があります。あるツールを通じて GitHub への書き込みをブロックしても、許可された別のツールまたは生成されたコードが、同じ書き込みを行うために認証情報を使用できる場合、意味がありません。
OpenShell ポリシー プローバーは、形式ロジックを使用して、プロバイダーが提供するアクセス権を含む、ポリシーによって付与される権限をチェックします。これにより、モデル化された許可がオペレーターによって定義された境界内に残っていることを証明したり、その境界を超えた具体的なアクションを特定したりできます。結果はポリシー モデルから得られるため、エージェントの説明でその結果が変わることはありません。リンク先の形式手法入門 (formal-methods primer) では、その仕組みについて説明しています。
長期間の敵対的な実験では、セーフガードを緩和したフロンティア エージェントが最大 2 時間かけて AI レビュー担当者を説得し、保護された GitHub リポジトリを変更できる権限を付与させようとしました。OpenShell の形式的ポリシー分析により、エージェントがレビュー担当者を操作しようとした場合でも、それらの権限で何が可能かを示す証拠がレビュー担当者に提供されました。レビュー制御とランタイム制御を組み合わせることで、有用なアクセスが可能になり、これらのテストでは保護されたリポジトリの書き込みは発生しません
現在、ポリシー分析を複数のエージェントに拡張しようとしている研究が進行中で、1 つのエージェントのアクセスを別のエージェントと組み合わせることができます。 この目的は、それらが一緒に形成するシステムの権限をチェックすることです。サポートされているチェックについては、プローバーのドキュメントをご覧ください。
ローカルで構築し、共有インフラにデプロイ
ローカル サンドボックスから始め、アプリケーションを構築し、権限を定義しましょう。 複数のユーザーにサービスを提供するには、ワークスペースとアクセス ガイドに従い、SDK を使用してサンドボックスを作成および管理してください。各ワークロードには、独自のポリシーとアタッチされたプロバイダーがあります。
サンドボックス外の信頼できるミドルウェアは、ID サービスを接続し、アプリケーション固有のチェックをリクエスト パスに追加できます。 コンピューティング ドライバーは OpenShell を Docker、Podman、MicroVM、Kubernetes に接続し、サポート マトリクスには現在の要件が記載されています。
CNCF Slack の #openshell-dev に参加して、質問やフィードバックの共有、OpenShell を活用して開発を行っている他のチームや開発者と交流しましょう。 GitHub でコードを確認して貢献したり、OpenShell dev ノートで進行中の研究とエンジニアリング作業をフォローしたりしましょう。既存のデプロイをアップグレードする場合は、0.1.0 移行ノートをご覧ください。
ビルドする準備はできていますか? クイックスタートから始めましょう。OpenShell を使用して独自のエージェントを実行し、そのエージェントがアクセスできるサービスを構成できます。
翻訳に関する免責事項
この記事は、「Add Runtime Controls to AI Agents with NVIDIA OpenShell」の抄訳で、お客様の利便性のために機械翻訳によって翻訳されたものです。NVIDIA では、翻訳の正確さを期すために注意を払っておりますが、翻訳の正確性については保証いたしません。翻訳された記事の内容の正確性に関して疑問が生じた場合は、原典である英語の記事を参照してください。
