OpenShell - ポリシー宣言とカーネル制御でAIエージェントの権限を絞るランタイム

自律型エージェントにコードや環境を扱わせるには、ファイルの読み取り、パッケージの導入、APIの呼び出しなどを許す必要がある。READMEが示す課題は、その能力を与える際に、データ、秘密情報、ネットワークへの無制限のアクセスまで渡してしまうことだ。OpenShellは、各エージェントが触れてよい範囲をポリシーとして宣言し、実行時に強制すると説明する。

取得資料は既存製品との詳細な比較を示していない。比較の出発点として読めるのは、エージェントに認証情報やホスト上のデータ、ネットワークへのアクセスを直接与える運用である。これはREADMEの「無制限のアクセスを与えずに」という説明からの編集上の推論だ。どの権限を作業に必要とし、どこから先を追加承認に回すかを明示できることが、OpenShellを理解する前提になる。

認証情報をエージェントの実行環境へ直接渡すと、エージェントがその値自体を扱える。OpenShellは、実際の認証情報をエージェントに見せず、承認済みエンドポイント宛のリクエストにだけ付与すると説明する。これは、APIを使う能力と秘密の値へのアクセスを分ける設計だ。ただし、認証情報をどの経路で付与するかは取得資料から分からない。

もう一つの問題は、作業の途中で権限が足りなくなる場合だ。新しいホストへの接続やAPIメソッドの追加をその場で許せば、最初に決めた境界は広がる。READMEによれば、OpenShellは変更を適用する前に新たなアクセスを形式検証で確認し、リスクのある変更を人間のレビュー待ちにする。したがって、ポリシーを書くことだけでなく、変更を誰がいつ承認するかも運用設計に含まれる。

取得時点の記録では、GitHubスターは10,622、直近1日の増加は990、フォークは1,422で、GitHub Trendingの日次一覧では2位だった。エージェントの実行境界に関心が集まっていることを示す材料ではある。一方、スターや順位から隔離の強度、継続利用の規模、運用時の性能は判断できない。

検討すべき対象は具体的だ。OpenShellはリポジトリ上で公開され、取得したリリース一覧の最新のタグ付きリリースは2026年9月28日公開のv0.1.2である。しかし、今回の資料はREADME、リポジトリのメタデータ、リリース一覧が中心で、詳細な設計ページや公開コードの動作検証結果は含まれていない。以下ではREADMEが説明する機構と、確認できていない境界を分けて追う。

操作の入口は小文字のopenshellというCLIだ。READMEのQuickstartでは、インストーラがCLIとローカルGatewayを導入し、openshell sandbox create --name demoでサンドボックスを作る。Gatewayはサンドボックス、ポリシー、アクセスのコントロールプレーンと説明される。アプリケーションからはPython、TypeScript、Go、RustのSDKでGatewayに接続できるが、SDK自体はCLIを導入しない。

作成される既定イメージは最小構成のUbuntuで、エージェントは入っていない。利用者が実行するエージェントを用意し、必要なアクセスを定義する。READMEはGateway、Supervisor、Sandboxの三者を挙げるものの、取得資料にその内部設計は含まれない。Supervisorを通信のどの段階に置くかなど、三者の正確な責務分担をここで確定することはできない。

Policyが扱う領域はファイルシステム、ネットワーク、プロセスだ。READMEによれば、各エージェントは隔離されたSandboxで動き、カーネルの制御によってアクセスできるファイルと発行できるシステムコールが制限される。ネットワーク接続は、サンドボックスを出る前にポリシーチェックを通るとされる。宣言した許可範囲を、エージェントの動作中にも確認するのがこの設計の中核である。

ここで説明できるのは制御の位置と対象までだ。READMEは利用するカーネル機能、ポリシーの記述形式、各プラットフォームで制御を実施する層を明記していない。特にApple SiliconのmacOSやWSL 2で、どのカーネルに対して何を強制するかは取得資料から追えない。「カーネルレベル」という表現だけで、環境をまたいだ同一の隔離特性を前提にするべきではない。

外向きの接続をポリシーチェックへ通すことと、秘密情報をエージェントから隠すことは連動する。READMEの説明では、OpenShellが承認済みエンドポイント宛のリクエストにだけ認証情報を付与する。エージェントは実際の値を見ないとされる。Providersはこの認証情報の扱いを担う概念として挙げられ、推論向けの扱いも含む。

ただし、接続先の判定方法、認証情報を付与する具体的な経路、回避可能性を評価した結果は取得資料にない。v0.1.2のリリースノートにはSupervisorのネットワーク処理とmediated CONNECTヘッダに関する修正があるため、Supervisor側に通信仲介があると読む余地はある。これはPRタイトルからの推論にとどまり、通信経路の仕様を示す証拠ではない。

エージェントが作業中に新しい宛先やAPI操作を必要としたら、ポリシーの変更が必要になる。READMEによれば、OpenShellは変更を承認する前に形式検証を使い、変更によって新たに許されるアクセスを確認する。例として、認証情報を伴う新しいホストへの到達や、新しいAPIメソッドの呼び出しが挙げられている。リスクのある変更は人間のレビュー待ちになる。

Policiesの案内には、変更のレビューを支えるadvisorとproverも登場する。ただし、取得資料は両者の役割や、どの構成要素がどの性質を証明するかを説明していない。形式検証という語から、ポリシーのあらゆる抜け道を検出できると考えることはできない。現時点で確認できるのは、メンテナが事前検証と人間のレビューを変更フローとして説明していることまでだ。

全体の流れは、Gatewayを介してSandboxを用意し、エージェントごとのPolicyを定め、実行中のファイル、システムコール、通信を制限し、権限の追加時には適用前の検証とレビューへ戻す、というものだ。実行時の制御は現在の行動に、変更前の検証は将来許される行動に向けられている。認証情報の扱いは、許可した通信先で必要なAPI利用を続けるための別の境界を作る。

この流れはREADMEに基づく設計の説明である。取得資料には、カーネル強制の突破耐性、形式検証の対象範囲、性能オーバーヘッドを測った値や第三者の検証結果がない。導入判断では、宣言した境界が実環境でどのように強制されるかを、対象の構成と負荷で確かめる必要がある。

OpenShellが合うのは、エージェントにファイル、パッケージ、APIを使わせながら、エージェントごとに許可範囲を宣言してレビューしたいチームだ。とりわけ認証情報を直接渡したくない運用や、新しいアクセスを人が確認してから許したい運用と設計上の方向が一致する。READMEの最初のエージェント例も、OpenCodeを動かし、必要になった新しいアクセスを承認する流れを示している。

この承認は運用コストでもある。リスクのある変更が人間のレビュー待ちになる以上、権限の追加まで完全に無人で進めたい処理には合いにくい。既定イメージにはエージェントが入っておらず、利用者は実行環境の準備も担う。権限を細かく絞るほど、必要なアクセスの見極めと変更審査が日々の作業に入ってくる。

ローカルでの要件は、Linux、Apple SiliconのmacOS、または実験的対応のWSL 2上のWindowsのいずれかに、Docker、Podman、ホスト仮想化のいずれかを組み合わせることだ。これらはREADMEが挙げるOpenShellの前提であり、OpenShellがコンテナや仮想化基盤そのものを置き換えるという説明ではない。KubernetesではHelmでGatewayをデプロイできるが、利用するCNIがNetworkPolicyを強制する必要がある。

直接エージェントへホスト上のアクセスや認証情報を渡す運用と比べると、OpenShellはSandbox、Policy、Gatewayを実行経路に加える。代わりに、許可範囲と変更時の判断を明示できる可能性がある。既存のサンドボックス製品との隔離強度や性能の優劣については、比較資料がないため結論を出せない。

WindowsはWSL 2経由の実験的対応として記載される。WindowsネイティブとIntel MacはREADMEの要件に記載がないため、それらを前提とするチームは対応状況を別途確認する必要がある。KubernetesでNetworkPolicyを強制できない構成も、記載された要件を満たさない。

リリースは0.1.x系で、READMEはこの系列で新しい隔離プリミティブ、拡張面、APIが導入されたと説明し、アップグレードガイドへ案内している。1.0前の変更に合わせて、SDK、Gateway、設定を見直せる運用が望ましい。SDKとGatewayは可能な限り同じリリースを使うよう案内されている。mainから作られるdevビルドは不安定な場合があるため、再現性が必要な検証では使用するリリースを明確にしておきたい。

最も大きな判断材料の欠落は、隔離を破る試みに対する検証結果、形式検証が扱う性質の範囲、性能オーバーヘッドである。READMEが述べるカーネル制御と認証情報の非露出は重要な設計意図だが、取得資料だけで高保証の環境に適すると認定することはできない。READMEの免責事項も、外部素材の安全性、完全性、適合性の確認は利用者の責任だと述べる。

匿名テレメトリについては、運用カテゴリと件数を収集すると説明され、サンドボックス名、ホスト名、ファイルパス、プロンプト、認証情報、ユーザーコンテンツなどは収集しないとされる。無効化設定も用意されている。機密性を重視する導入では、この説明と実際の運用設定を確認したい。OpenShellを採用する価値は、必要な権限の管理が明確になる利益と、Gatewayの運用、環境要件、人間の承認作業を合わせて評価して決まる。