自律エージェントの権限をOSS「OpenShell」はどう絞るのか

「エージェントに本番のファイルもAPIキーも渡しているが、何かあったときに止められる気がしない」「サンドボックスに入れておけば安全だと聞いたが、何をもって安全なのかを自分で説明できない」——自律型のAIエージェントを社内で動かし始めた、情報システムとセキュリティの担当者から出てくる声です。こうした不安は、実行環境を一つ用意すれば片づくように見えます。しかし本当に問われているのは、道具の有無ではありません。エージェントが何に触れてよいかを、誰が、いつ決めて、それを機械が強制できるかが分かれ目です。この記事では、NVIDIAが公開している実行環境のOSS「OpenShell」を取り上げ、エージェントの権限をどこでどう絞るのか、クラウド型の実行環境として知られるE2Bとは何が違うのかを、公開されている一次情報に基づいて整理します。導入や設定の手順は扱いません。

OpenShellとは何か。2026年10月時点で確かめられる事実

OpenShellは、NVIDIAがGitHubで公開しているオープンソースのソフトウェアです。リポジトリの説明では「自律型のAIエージェントを、安全で私的な環境で動かすための実行基盤」とされています。公式ドキュメントの表現では、多数のエージェントを、カーネルレベルの隔離を備えたサンドボックスの中で実行するためのオープンソースの実行環境、と説明されています。ライセンスはApache-2.0で、商用利用を含めて使えます。

配布の形を確かめておきます。リポジトリは著名な企業の組織アカウントとして公開されており、アカウントは2012年5月に作られ、公開しているリポジトリは819件あります。OpenShellのリポジトリ自体は2026年2月24日に作られ、2026年10月16日時点でスターは約1万6300、フォークは約1800、最後の更新は同じ日でした。スターの伸びは1日あたり70件ほどと速い部類ですが、これは有名企業が公開した基盤ソフトであることを踏まえて読む必要があります。

配布の経路も複数あります。公式ドキュメントは最新版を0.1.4として公開し、Pythonのパッケージ置き場であるPyPIにも、同じ0.1.4が2026年10月13日に登録されています。PyPIの記載では開発の段階が「アルファ」、対応するPythonは3.11以上、作者はNVIDIA Inc.とされています。リリースの一覧には0.0系の版が数多く並び、2026年6月から10月にかけて、短い間隔で版が積まれています。この点は後の章で改めて触れます。

なぜ今、エージェントに専用の実行環境が要るのか

公式ドキュメントは、問題の出発点をはっきり書いています。エージェントは、ファイルを読み、部品を導入し、外部のAPIを呼び、認証情報を使ってこそ役に立ちます。しかし同じ権限が、そのまま大きな危険にもなります。ドキュメントは、この「できること」と「危ないこと」の釣り合いを取るために作られたのがOpenShellだと説明しています。

ドキュメントが挙げる典型的な失敗は四つです。エージェントが社内のソースコードやファイルを、許可されていない宛先へ送ってしまう情報の持ち出し。手元に置かれた鍵やクラウドの認証情報を読み出される認証情報の窃取。承認していないモデル提供元へ、入力やデータを送ってしまうAPIの不正利用。そして、管理者の権限を取ろうとしたり、危険なシステムコールを呼んだりする権限の昇格です。

これらは、ふつうのアプリの弱点と同じ顔をしています。違うのは、入力を解釈して自分で次の操作を選ぶ主体が、社内のネットワークの中にいるという点です。プロンプトインジェクション（文書に紛れ込ませた命令でAIを操る攻撃）が一つ通るだけで、エージェントは自分に許された権限を、利用者の意図とは違う目的で使いうる。だからこそ、モデルの側の言いつけではなく、実行環境の側で物理的に制限する必要が出てきます。

カーネルレベルで何を止めるのか

OpenShellの第一の柱は、カーネル（OSの中核）の仕組みを使って、エージェントの操作を実行のたびに検査する点です。READMEの説明では、エージェントごとに隔離されたサンドボックスを作り、カーネルの制御で「どのファイルに触れるか」「どのシステムコールを呼べるか」を閉じ込め、外へ出るすべての通信を、サンドボックスを出る前にポリシーの検査に通します。

公式ドキュメントの構成の説明では、現在のLinux向けの実装について、作業用のプロセスは一つの特別な権限を持たない利用者のIDで動き、Linuxの権限（ケイパビリティ）を一切持たないとされています。ファイルへのアクセスはLandlock（ランドロック）というカーネルの仕組みで宣言した場所だけに限定し、ネットワークの操作はseccomp（シーコンプ）の仕組みでいったん止めて判断を仰ぐ。止める対象は、ファイル、通信、プロセスの三つです。

守る対象	何を防ぐか	いつ決まるか
ファイル	許可した場所の外の読み書きを防ぐ	サンドボックスの作成時に固定される
通信	許可していない宛先への送信を防ぐ	実行中でも変更できる
プロセス	権限の昇格と危険なシステムコールを防ぐ	サンドボックスの作成時に固定される
認証情報	許可していない接続先に鍵が渡るのを防ぐ	実行中に付け外しと失効ができる

設計として重要なのは、失敗したときに必ず安全側に倒れる点です。ドキュメントによれば、監視役が境界を確認するまでエージェントは起動を保留され、両者をつなぐ通り道が切れるとエージェントは凍結されます。再開できるのは同じ監視役だけで、別の監視役が正しい資格情報を持っていても、動いているサンドボックスを引き継ぐことはできません。止まることが既定で、動き続けることが例外という作りです。

認証情報をエージェントに渡さない仕組み

第二の柱は、認証情報の扱いです。READMEの説明では、エージェントは本物の認証情報を決して見ません。OpenShellは、認可された接続先へ向かう要求にだけ、認証情報を付け加えます。社内のAPIキーやトークンを、エージェントの手元に置かないという発想です。

ドキュメントの用語では、これを「プロバイダー」という仕組みで扱います。サービス名と、保管された認証情報を結びつけておき、監視役がポリシーで許された場所にだけそれを渡す。エージェントの側が持つのは、実物ではなく、実物に置き換わる目印だけです。仮にエージェントがプロンプトインジェクションで乗っ取られても、鍵そのものを読み出して別の宛先へ送る、という筋書きが成立しにくくなります。

さらに、サンドボックスの側には「盗む価値のあるものが置かれていない」とドキュメントは書いています。ゲートウェイの署名鍵も、ゲートウェイ用のトークンも、プロバイダーの認証情報も持たない。持っているのはゲートウェイの公開鍵だけで、相手を確かめることはできても、相手になりすますことはできません。守りの要を、攻撃者の届く場所に置かないという整理です。

ポリシーの変更を形式検証で確かめる

第三の柱は、ポリシーの変更を形式検証（数学的な方法で、取りうる状態を網羅的に確かめる手法）にかける点です。エージェントは仕事を進めるうちに「新しい接続先へ行きたい」「別のAPIを呼びたい」と、権限の追加を求めてきます。これを人が毎回読み解いて判断するのは現実的ではありません。

ドキュメントによれば、ポリシーの検証役はゲートウェイの中で動き、エージェントが提案した通信の規則を形式検証で調べます。検出するのは、認証情報を付けたまま新しい接続先へ届けるようになる変更、これまで使えなかったHTTPのメソッドが使えるようになる変更、クラウドのメタデータ用の接続先に届くようになる変更などです。危険な拡張が一つでも見つかれば、自動承認は止まります。

同じ検証は、単体で動く検証用のツールとしても配布されているとドキュメントは説明しています。ポリシーの変更を、版で管理する道具立てと組み合わせ、レビューの関門として使える形です。ここで押さえたいのは、形式検証が見るのは「その変更で何が可能になるか」であって、その変更が妥当かどうかではないという点です。最後に「この業務にこの接続先が必要か」を決めるのは人です。

ゲートウェイ・監視役・サンドボックスの役割分担

構成を三つの部品で見ておきます。ゲートウェイは制御の中心で、サンドボックスの作成と廃棄、ポリシーと設定の配布、認証情報の割り当て、誰が何をしてよいかの管理、サンドボックスへの接続の取りまとめを担います。各サンドボックスを作る役割は、作業用の本体とは別に「監視役」を用意し、両者の間に保護された通り道を作って境界を組み立てます。

大事なのは、信頼を置く場所が分かれていることです。ドキュメントは、監視役は境界の信頼された側にいて判断を下す存在であり、攻撃者と同じ側にいる作業用の本体は、ポリシーの判断を一切しないと明記しています。本体は「何をしようとしているか」を報告するだけです。

両者をつなぐ通り道は、相互に認証した一本の接続で、その上に複数の流れを載せます。通信の接続ごとに流れを分けるため、大きなファイルの取得が、名前解決やプロセスの操作を待たせません。呼び出しているプログラムの特定には、エージェントが自己申告する名前ではなく、カーネルが持つ信頼できる情報を使うとされています。名乗りではなく、観測で本人を決めるという考え方です。

実行基盤を選べること。コンテナとKubernetesと仮想マシン

ドキュメントは、境界の作り方を実行基盤ごとに用意していると説明しています。同じ契約に従いつつ、それぞれの環境がもともと持っている仕組みで、監視役の置き場所、通り道、外への通信の遮断を実現します。DockerとPodmanでは、作業用のコンテナの通信を切り、監視役は別のコンテナで動き、両者は専用の領域に置かれたソケットで通信します。

Kubernetesでは、監視役は専用の実行単位で動き、相互認証つきのTLSで本体とつながり、ネットワークポリシーで監視役の窓口以外への通信を許さない構成にします。軽量な仮想マシンを使う場合は、監視役はホスト上のプロセスとして動き、その仮想マシンの側には通信の装置自体を持たせません。どの基盤でも、判定をするのは共通の監視役とポリシーの仕組みで、基盤ごとに判断が変わることはないとされています。

Kubernetesへの配布用の部品や、既存の秘密管理、ID管理、イメージの流れ、保存、デバイス連携などとの接続も用意されているとドキュメントは述べています。実行環境の違いを、守りの違いにしないことが設計の狙いです。もっとも、Kubernetesでは、利用しているネットワークの仕組みがネットワークポリシーを実際に強制できることが前提だと明記されています。ここが満たされていないと、境界そのものが成立しません。

想定される使い方と、使う場面

公式ドキュメントは、主な使い方として四つの場面を挙げています。第一に、コーディング用のエージェントを、触れるファイルと通信先を絞った状態で走らせる使い方です。ドキュメントには、複数の代表的なコーディングエージェントの名前が例として挙がっています。既定のサンドボックスにはエージェントが入っていないため、自分で用意した環境を持ち込む形になります。

第二に、自社で持つモデルの接続先へ、選んだサンドボックスだけを接続する使い方です。第三に、ポリシーを版で管理されたセキュリティの統制として扱い、レビューと監査の対象にする使い方。第四に、既定の環境を使い回す、あるいは自分のコンテナを持ち込む使い方です。いずれも、エージェントに何でもできる権限を与えずに、業務に必要な範囲だけを開けるという考え方で共通しています。

開発の入口も用意されています。コーディングエージェントに、OpenShellの操作やポリシーの書き方を教えるための公開の部品が配られており、本体のソースを手元に持ってこなくても使えるとされています。アプリケーションから接続するための開発キットは、Python、TypeScript、Rustなどの複数の言語向けに提供されています。エージェントを守る道具を、エージェント自身に使わせるという、少し変わった作りです。

E2Bとの違いを、実行環境の選び方として整理する

エージェントの実行環境としては、E2Bがよく引き合いに出されます。E2Bのリポジトリの説明では、AIが生成したプログラムを、クラウド上の隔離されたサンドボックスの中で安全に動かすための基盤とされ、サンドボックスの起動と制御には開発キットを使います。同じくApache-2.0で、2023年3月から公開されている先輩格です。両者は競合というより、重心の違う道具と見たほうが実態に合います。

違いは「どこで動かすか」と「何で絞るか」に表れます。下の表は、それぞれの一次情報で確認できる範囲を整理したものです。

見る点	OpenShellの場合	E2Bの場合
動かす場所	自社の環境に置く（パソコン、自社のKubernetes、仮想マシン）	クラウド上のサンドボックスを中心に使う
権限の絞り方	ファイル・通信先・プロセス・認証情報を、宣言したポリシーで絞り、カーネルで強制する	隔離されたサンドボックスを与え、その中でコードやコマンドを実行させる
認証情報の扱い	エージェントに本物を渡さず、許可された接続先への要求にだけ監視役が付ける	利用者が取得した鍵で、サンドボックスの起動と制御を行う
主な用途	コーディングエージェント、社内の私的なモデル接続、ポリシーの監査	AIが生成したコードの実行と、その結果の受け取り
ライセンス	Apache-2.0	Apache-2.0
公開からの期間	2026年2月から（0.1系・開発初期）	2023年3月から

表のとおり、E2Bは「エージェントに隔離された作業用のコンピューターを与える」ことを中心に据え、OpenShellは「そのエージェントがファイル、通信先、認証情報のどこまで触れるかを、ポリシーで細かく統制する」ことに重心を置いています。どちらが上かではありません。

では企業は何で選ぶか。確かめる点は五つに絞れます。第一に、実行する場所を自社の統制下に置く必要があるか。社内の機密に触れるエージェントなら、データが自社の外へ出ない構成かどうかが第一の関門になります。第二に、権限をどの粒度で絞りたいか。第三に、認証情報の実物をどこに置くか。第四に、ポリシーの保守を誰が担うか。第五に、開発段階の製品を本番の守りに使えるか、という成熟度です。道具の機能ではなく、自社の守りたい対象から逆算して選ぶのが順序です。

安全性の評価：紹介可とした根拠

このラインでは、紹介するOSSを、公開されている事実だけを基に精査しています。OSSをダウンロードしたり動かしたりはしていません。OpenShellの判定は「紹介可」です。

根拠にした事実は次のとおりです。公開しているのはNVIDIAの組織アカウントで、2012年5月に作られ、公開リポジトリは819件、フォロー数は3万1300件を超えます。作ったばかりの使い捨てのアカウントではありません。プロジェクトのリポジトリは2026年2月24日に作られ、スターの伸びは1日あたり70件ほどです。数字だけを見れば速い成長ですが、作者が明確な企業の公式プロジェクトであることを踏まえれば、不自然な水増しを示すものではありません。

あわせて、GitHub上にこのリポジトリのセキュリティ勧告は登録されておらず、ライセンスはApache-2.0で、商用利用を妨げる条件は見当たりません。弱点の報告は、リポジトリのセキュリティの方針文書に従い、公開の場ではなく専用の窓口へ非公開で届ける形に整理されています。

一方で、リポジトリの直下には、導入の途中で自動的に動くスクリプトが置かれています。このラインの決まりでは、OSSの取得や実行は行わないため、このスクリプトの中身や動きは確かめていません。導入を検討する組織は、何が自動で行われるのかを自分たちの目で確かめる必要があります。

なお、ここで問題が見つからなかったことは、安全の保証ではありません。この精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。導入の可否は、自社の確認の手順に沿って判断してください。

導入前に知っておきたい注意点

紹介可とはいえ、一次情報を読むと気になる点がいくつかあります。一つ目は、利用状況の送信が既定で有効なことです。READMEによれば、OpenShellは運用に関する区分と件数に限った匿名の情報を送り、サンドボックスの名前、ホスト名、ファイルの場所、プロンプト、認証情報、提供元やモデルの名前、利用者の内容は送らないとされています。設定で止めることも、機能ごと外して作ることもできるとされます。

それでも、守りの道具が既定で外部へ何かを送る設定になっていることは、機密を扱う環境では先に決めておくべき論点です。既定の設定を、そのまま本番の前提にしないという原則が当てはまります。

二つ目は、製品の成熟度です。PyPIの記載では開発の段階が「アルファ」とされ、0.1.0が2026年9月25日、0.1.4が同年10月13日と、版の進みが非常に速い状態です。公式ドキュメントには0.1.0への更新手順の案内があり、版をまたぐと設定の形が変わりうることを示しています。長期の運用に組み込むなら、版の固定と更新の計画が要ります。

三つ目は、動かす環境の前提です。Linuxではカーネル側の機能を必要とし、Kubernetesではネットワークポリシーを実際に強制できる仕組みが前提とされています。Linux以外の対応は限定的で、あるOS上では実験的な対応であることもREADMEに書かれています。四つ目に、利用条件の文面です。READMEの注意書きは、このソフトウェアが外部の材料を自動で取得しうること、それらは別の条件に従うこと、取得した材料の安全性や適切さを確かめる責任は利用者にあること、無保証で提供されることを述べています。社内規程との突き合わせが必要です。

悪用されうるリスク

ここからは、一次情報で確認した事実ではなく、構成から導かれる推測を含みます。OpenShellは守りのための基盤で、それ自体が攻撃の道具として作られたものではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、「サンドボックスに入れた」という安心が、監視を弱めることです。隔離は、ポリシーが実際に厳しく、前提が満たされているときにだけ働きます。

推測として挙げます。まず、ポリシーの初期値が緩いまま運用されれば、隔離は見かけだけになります。権限を絞る道具は、絞る規則を人が書かない限り何も守りません。次に、エージェントに強い権限を与える構成では、守りの基盤そのものが侵入の踏み台になりえます。監視役やゲートウェイの側が破られれば、認証情報はそこに集まっているため、影響はサンドボックス一つでは済みません。

さらに、ポリシーのファイルは社内のネットワーク構成や接続先の一覧を含みます。統制の文書が、そのまま内部の地図になりうる点は、保管と閲覧の範囲を決めておく必要があります。なお、この基盤が悪用された事例は、2026年10月16日時点で一次情報からは確認できませんでした。

導入を検討するときに確かめること

OpenShellのような実行環境を検討するとき、機能の一覧より先に確かめたい点があります。下の手順は、OSSを動かす前の段階で、資料と社内の取り決めによって確かめられることに絞っています。

この手順の要は、道具を入れる前に、道具に何を任せないかを決めておくことです。実行環境は、入れた瞬間から「守られている」という印を出し始めます。その印が何を意味するのかを先に決めておかないと、印だけが独り歩きします。

企業が取るべき対策

OpenShellを入れるかどうかにかかわらず、エージェントの実行環境について、企業として決めておきたい対策を挙げます。一つ目は、ポリシーを版で管理された統制の文書として扱うことです。公式ドキュメントも、ポリシーをレビューと監査の対象にできる統制として位置づけています。変更の理由を残し、承認の記録と結びつけます。

二つ目は、権限をエージェントごとに分けることです。一つの広い権限を使い回すと、一つのエージェントの乗っ取りが全体に広がります。業務ごとに箱を分け、箱ごとに必要な分だけを開けるのが基本になります。

三つ目は、認証情報の実物をエージェントに渡さない設計を、社内の標準にすることです。四つ目は、利用状況の送信の扱いを決め、社内の規程に書き加えること。五つ目は、調達の段階での確認です。サポートの窓口、更新の頻度、弱点への対応の約束、ライセンスの条件、動かす環境の前提を、導入前に文書で確かめておきます。あわせて、エージェントの操作の記録を、認証情報と同じ水準で守る対象に位置づけます。

AIに任せる範囲と、人が決める範囲

OpenShellの設計は、AIに判断させない部分を意図的に広く取っています。権限の追加を提案するのはエージェントですが、危険な拡張を検出して自動承認を止めるのは機械の検証で、最後にその変更を受け入れるかを決めるのは人です。AIに判断させない範囲を先に決め、根拠を書かせて人が確かめるという順序が、そのまま仕組みになっています。

この順序を崩すと、便利さだけが残ります。エージェントが提案した権限の追加を、内容を確かめずに通してしまう。記録を取らない。前提が満たされているかを確かめない。やってはいけない向き合い方を挙げておきます。

• エージェントが提案した新しい接続先への追加を、内容を確かめずに自動で承認する
• 既定のポリシーのまま、社内の機密に触れるエージェントを動かす
• ポリシーを変更した理由と承認者を、どこにも残さない
• 利用状況の送信設定を確かめないまま、機密を扱う環境に導入する
• サンドボックスに入れたことを理由に、エージェントの操作の記録を取らない
• 開発初期の版を、版を固定せずに追いかけ続ける

裏を返せば、人が決める範囲ははっきりしています。どのエージェントに何を許すか、権限の追加を誰が承認するか、鍵をどこに置くか、どこまで記録するか。この四つはAIにも道具にも委ねず、人が決めます。道具に任せてよいのは、人が決めた範囲の中で、決まった形の危険を速く確実に止める部分です。

よくある質問：サンドボックスに入れれば安全なのか

答えは「それだけでは決まらない」です。サンドボックスは、その中で何を許すかを決めた規則と、規則を実際に強制する仕組みがそろって、初めて意味を持ちます。OpenShellは、ファイル、通信、プロセス、認証情報の四つを、カーネルの仕組みで強制する部分を担います。そのうえで何を許すかを書くのは、導入する組織自身です。

では、クラウド型の実行環境で足りる場面はないのかというと、そうではありません。すでにクラウド上でAIが書いたコードを動かしている企業が、社内の機密に触れる一部のエージェントだけを、自社の統制下の環境へ移す、という使い分けは現実的です。逆に、まず手軽に隔離実行を始めたい段階では、クラウド型のほうが向いています。

もう一つ、「開発初期の製品を業務に使ってよいのか」という問いもありそうです。見るべきは、版の進み方と、更新の案内が整っているかです。OpenShellは更新の手順や対応する環境の一覧を文書として公開しており、少なくとも変化を利用者に伝える形は整いつつあります。そのうえで、検証用の環境で自社の業務に当てて確かめてから、本番へ広げる判断をするのが現実的です。

• OpenShellの機能・版・対応環境は、GitHubのリポジトリとその中の文書、公式ドキュメント、PyPIの記録を2026年10月16日に確かめた範囲に基づきます。内容は変わる可能性があります
• E2Bに関する記述は、E2Bのリポジトリの説明と公開情報の範囲です。両者の比較は、それぞれの一次情報で確認できる範囲に限っています
• この記事は防御と評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

OpenShellは、自律型のAIエージェントを隔離した環境で動かし、ファイル、通信、プロセス、認証情報という四つの入口を、宣言したポリシーとカーネルの仕組みで制限するOSSです。エージェントに本物の認証情報を渡さず、ポリシーの変更を形式検証にかけて危険な権限の拡張を人の確認待ちにする。この二点が、単に箱へ入れるだけの道具との違いです。

一方で、開発の段階はアルファで版の進みが速く、利用状況の送信が既定で有効であり、動かす環境には前提があります。そして、何を許すかを書くのは人です。E2Bのようなクラウド型と比べたときの強みは、権限の細かさと、データが自社の外へ出ない構成を選べることにあります。道具を選ぶ基準は、機能の数ではなく、守りたい対象と、誰が何を決めるかに置く。エージェントに仕事を任せる時代の実行環境は、そこから選ぶのが確かです。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。