AIエージェントの外への通信と鍵の扱いをOSS「Containarium」はどう管理するのか

「AIエージェントに作業用の環境を丸ごと渡したい。でも、中で何をされても社内や他の部署に被害が広がらない作りにできるのか」「エージェントが使うAIの鍵を環境に置いたら、騙されたときに持ち出されないか」——AIエージェントを複数の部署やチームで動かそうとしている情報システム部門で、よく話題に上る心配です。こうした心配は「箱に閉じ込めれば片付く」と考えられがちですが、そうではありません。本当は、箱の外へ何を通すか、鍵を誰が持つか、そして箱を管理する窓口が正しく本人を確かめているかまで含めて、ようやく守りになります。この記事では、AIエージェントごとに隔離した箱を渡す実行基盤のOSS「Containarium」について、外への通信の許可制と鍵の預かりの仕組み、既定では有効になっていない守り、公開済みのセキュリティ勧告2件とそこから読み取れる運用の教訓を、一次情報をもとに整理します。導入や操作の手順は扱いません。

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

Containarium は、GitHub上で公開されているAIエージェント向けの実行基盤です。READMEは自らを自社の環境に置いて運用できる、オープンソースのエージェント実行基盤と説明しています。エージェント一つごとに、SSH（暗号化した遠隔接続の方式）でつなげる長く使い続けられる作業環境（以下、箱）を、権限を持たないコンテナの中に用意するとされます。エージェント自体は利用者が持ち込む前提で、READMEは Cursor、Claude Code、OpenCode などを例に挙げています。

公開の時期と規模を確かめておきます。リポジトリは2025年12月28日に作られ、2026年10月22日時点でスターは310、複製（フォーク）は54、本流の変更の記録は2,000件を超えています。リリースは非常に頻繁で、確認時点の最新版は10月21日公開の0.113.0です。10月15日から21日までの1週間だけで10の版が出ています。ライセンスはOSI（オープンソースの定義を管理する団体）が承認する Apache-2.0 で、READMEには貢献者に別の契約を求めないとも書かれています。この記事では「OSS」と呼びます。

公開元は FootprintAI という組織のアカウントで、2020年4月に作られ、公開しているリポジトリは50あります。会社名や公式サイトの欄は空ですが、プロジェクトの専用サイトがあり、自分で運用する形とは別に、事業者が運用する有料の可能性があるクラウド版も案内されています。READMEは、画面の作り込みや複数の利用者の扱いの一部は別のクラウド向けのリポジトリの話だとしており、オープンソースの部分と商用のクラウド版が分かれていることがうかがえます。クラウド版の料金や条件は、確認した範囲では書かれていませんでした。

なぜ今、エージェントの実行基盤が話題なのか

AIエージェントは、文章を返すだけでなく、自分で部品を入れ、命令を実行し、作ったものを公開するところまで進みます。READMEは、エージェントが開発の環境の主な使い手になりつつあるという見立てから書き始め、人の端末で動かすのは騒がしく危険で、手元に閉じすぎるとしています。そのうえで、作業の状態が残り、隔離され、本物の環境に近く、決まった形の道具で操作でき、被害の範囲が限られた場所が要る、と述べています。

このラインでは前日に、AIエージェントを隔離環境で動かす道具を続けて取り上げました。それらが主に一人の開発者の手元で一回の作業を閉じ込めることに重心を置いていたのに対し、Containarium は多くのエージェントと多くの利用者を一つの基盤に載せる、共用の運用を前提にしている点が違います。共用になると、箱の壁だけでなく、利用者どうしの境目、管理の窓口の本人確認、外への通信の出口といった、基盤側の守りが問われます。

もう一つの背景が、プロンプトインジェクション（読み込んだ文書やウェブの情報に紛れた命令にAIが従ってしまう攻撃）です。騙されたエージェントが箱の中の鍵を読み出して外へ送る、という筋道は、隔離環境を語るときの典型的な心配です。Containarium が通信の許可制と鍵の預かりを前面に出しているのは、この筋道を断つためだと読み取れます。

仕組み1：エージェントごとに隔離した箱を渡す

READMEによると、箱は既定では LXC（軽量の仮想環境を作る仕組み）を土台にし、Kubernetes（コンテナをまとめて動かす仕組み）を土台にすることもできます。ただし Kubernetes 版は試験段階と書かれています。どちらの土台でも、操作の道具・認証・窓口は共通とされ、Kubernetes 版の箱は管理用の通行証を持たず、厳しめの標準の安全設定を満たすと説明されています。画像処理用の半導体（GPU）を箱に割り当てる機能もあります。

READMEは、被害の範囲を限るという考え方を、エージェントが持つのは箱に入るための SSH の鍵だけで、基盤全体を操る強い通行証ではない、と表現しています。その結果、エージェントは基盤の制御面、土台の基本ソフト、他の利用者の箱に届かないというのがREADMEの主張です。

ただし、作者自身がまとめた安全性の主張の文書（以下、主張の文書）を読むと、この説明には条件が付きます。箱は既定で権限を持たないものの、箱の中でコンテナを動かす機能を有効にすると、その箱は強い権限を持ち、守りの設定も外れた状態になるとされています。しかも既定の方針では、箱を作る権限を持つ人なら誰でもこれを求められるとされ、複数の利用者で使う場合は管理者だけに絞るか無効にするよう勧めています。

仕組み2：外への通信を許可制にする

Containarium の特徴の一つが、利用者ごとに外への通信を絞る仕組みです。READMEは、eBPF（基本ソフトの中核で小さな処理を安全に動かす技術）を使い、利用者ごとの外への通信の方針を、基本ソフトの中核の段階で強制すると説明しています。中核の段階で止めるため、箱の中のエージェントが自分で設定を書き換えて抜け出すことは難しい、という設計の狙いが読み取れます。

一方で、主張の文書はこの仕組みを「自分で有効にするもの」に分類しています。必要な部品を入れ、強制の動かし方にしたときだけ働き、箱の外への通信が既定でどう扱われるかは、まだ定まっておらず、確かめられてもいないと明記されています。READMEの冒頭は「拒否した通信を監査の記録に残す」とうたっていますが、主張の文書ではこの点も「確かめられていない」とされ、拒否の記録が監査の記録まで届く経路は確認できていない、と書かれています。

利用者どうしの通信の境目についても、主張の文書は既定では成り立っていないとしています。利用者は一つの網を共有しており、運用者がこの仕組みを有効にし、利用者ごとに強制の方針を書いた場合にだけ分かれる、という説明です。外への通信の許可制は、入れれば自動で効く守りではなく、運用者が設計して有効にしてはじめて効く守りだと理解しておく必要があります。

仕組み3：モデルの鍵を箱の外に置く

もう一つの特徴が、AIのモデルを使うための鍵の扱いです。設計の文書によると、以前は箱ごとに、モデルの提供元の長く使える鍵を環境の設定として置いていました。その結果、騙されたエージェントを含め誰でも鍵を読み出せること、利用者ごとの使用量を数えられないこと、鍵を替えるたびにすべての箱に手を入れる必要があることなどが問題として挙げられています。

そこで、基盤の側に中継役（以下、中継口）を置き、本物の鍵は中継口だけが持ち、箱には利用者・作業・実行の単位で縛った短い期限の通行証だけを渡す作りにした、と説明されています。中継口は通行証を確かめ、その作業に使ってよいモデルかを判断し、本物の鍵を差し込んで提供元へ送り、使用量を記録します。箱が乗っ取られても漏れるのは使い捨ての通行証で、利用者・作業・期限で範囲が限られる、というのが設計の考え方です。

使用量の記録は、利用者・作業・実行・モデルの単位で残り、監査の記録も兼ねるとされます。利用者ごとの上限や、普段の使い方からの外れを見つける仕組みもあり、異常のときは見守る、絞る、知らせる、止める、取り消すの段階で対応するとされています。設計の文書はこの中継口を実装済みとしています。ただし主張の文書では、これも中継口を使うように設定した箱にだけ効く、自分で有効にする守りとされ、鍵を環境の設定として渡された箱は、当然その鍵を持っている、と注記されています。

仕組み4：管理の窓口と、箱の中の窓口を分ける

READMEによると、Containarium は MCP（AIが外部の道具を呼び出すための共通の約束事）の窓口を二つ持ちます。一つは基盤の側で動く管理用の窓口で、操作の道具がおよそ100あり、通行証に与えた権限の範囲によって、見える道具が変わるとされます。もう一つは箱の中で動く窓口で、命令の実行、ファイルの読み書き、一覧、移動、削除といった道具をエージェントに渡します。

この分け方は、エージェントには箱の中の作業だけを任せ、箱を作る・消す・公開するといった基盤の操作は別の権限に分ける、という考え方に沿っています。READMEは、画面に命令を打ち込ませる操作ではなく、決まった形の道具で操作させることを、範囲を区切った安全なやり方と位置づけています。

ただし、管理用の窓口に約100もの操作があるということは、その窓口が本人を正しく確かめていなければ、基盤全体が危険にさらされるということでもあります。後で扱う重大の勧告は、まさにこの管理の窓口に関わるものでした。窓口を分けることは良い設計ですが、窓口ごとの本人確認が正しく働いていることが前提です。

既定で有効な守りと、自分で有効にする守り

Containarium の文書で評価できる点は、作者自身が守りの一つひとつを「裏付けあり」「自分で有効にする」「範囲が限られる」「確かめられていない」「既定では成り立たない」に分けて公開していることです。主張の文書は、コードや試験や設計の記録で裏付けられた主張だけを繰り返すべきだ、と自ら書いています。導入を検討する側にとっては、宣伝の言葉と実態の差を確かめる手がかりになります。主な項目を表にまとめます。

守り	主張の文書での扱い	読み取れること
箱は権限を持たないコンテナ	範囲が限られる	箱の中でコンテナを動かす機能を有効にすると強い権限になる。既定では作る権限があれば誰でも求められる
利用者どうしの網の境目	既定では成り立たない	通信の仕組みを有効にし、利用者ごとに方針を書いたときだけ分かれる
外への通信の許可制	自分で有効にする	既定の扱いはまだ定まっていない
拒否した通信の監査記録	確かめられていない	監査の記録まで届くかは未確認
モデルの鍵を箱の外に置く	自分で有効にする	中継口を使う設定の箱にだけ効く
改ざんに気づける監査記録	範囲が限られる	記録の保管先に書き込める者は書き換えられる。外部への固定は自分で有効にする
配布物への署名	まだ成り立たない（文書の記載）	10月の0.110.0版のリリースノートには署名を始めたとの記載があり、文書と食い違う

表のとおり、READMEの冒頭でうたわれる守りの多くは、既定では効いていないか、運用者の設定次第です。「入れれば安全になる道具」ではなく、「安全に組み立てるための部品が揃った基盤」と見るのが実態に近いと言えます。なお、配布物への署名は主張の文書とリリースノートで記載が食い違っており、文書の更新が開発の速さに追いついていない可能性があります。これは推測で、どちらが現状かは導入前に確かめるべき事項です。

安全性の評価：注意付きとした根拠

このラインでは、OSSを取得・導入・実行せず、公開されている情報と精査の記録をもとに安全性を判定しています。Containarium の判定は「注意付き」です。紹介してよい根拠と、注意が要る根拠を分けて示します。

紹介してよい根拠は、ライセンスがOSI承認の Apache-2.0 であること、公開元が2020年に作られた組織のアカウントで、50のリポジトリを公開していること、精査の範囲で、導入の際に自動で動く不審な処理は見つかっていないことです。スターの伸びも1日あたり1程度で、不自然な急増はありません。さらに、セキュリティ方針の文書があり、非公開で報告を受ける窓口、受け付けの連絡は3営業日以内、最初の評価は10営業日以内、公表までは原則90日の猶予、という手順が明記されています。

注意が要る根拠は、2026年9月24日に、重大と中程度のセキュリティ勧告が1件ずつ公開されていることです。どちらも共用の運用で利用者の境目や本人確認が崩れる種類の問題で、このOSSの中心となる約束に関わります。加えて、多くの守りが既定で無効であること、1.0版に達しておらず古い版は保守されないことも注意点です。なお、問題が見つからなかった部分があっても、それは安全の保証ではありません。注意付きは「記事として紹介してよいが、注意点を明記する」という意味で、業務で使ってよいという判断ではありません。

重大の勧告：管理の窓口が利用者の申告で本人を判定していた

一つ目の勧告は、重大度が「重大」、CVSS（脆弱性の深刻さを数値で表す共通の尺度）の値は10点満点で9.8です。勧告の題は「gRPC の制御面が、呼び出し元の身元を利用者が送ってきた付帯情報から導いていた」というものです。gRPC は、機械どうしが決まった形で命令をやり取りするための通信の方式で、Containarium の管理の窓口に使われています。影響を受けるのは0.87.1以前の版と書かれています。

勧告によると、既定の受け口では呼び出し元の認証が行われておらず、権限の確認は、要求に添えられた利用者名や役割や権限の範囲といった、送り手が自由に書ける情報をそのまま信じていたとされます。相互に証明書を確かめる方式を使っていた場合も、証明書は確かめるものの、身元の根拠には使っていなかったとされています。その結果、受け口に網の上で届く者が、箱の作成や停止、秘密の情報、通信の方針といった管理者向けの操作に届きえた、と説明されています。具体的な手口はこの記事では扱いません。

修正の内容として、勧告は、身元を通信の経路に結び付け、外からの接続は相互に証明書を確かめる方式に限り、身元は確かめた証明書から取り、送り手が添えた身元の情報は捨てる、と説明しています。注意したいのは、勧告の「修正版」の欄が空欄であることです。勧告の回避策は、修正版に上げるまでの間、管理の受け口に届く相手を信頼できる機械に限ることでした。一方、勧告と同じ9月24日に公開された0.88.0版のリリースノートには、外からの gRPC の接続を相互に証明書を確かめる方式だけに限る変更と、通信の段階での認証を強める修正が書かれ、早めの更新が呼びかけられています。影響範囲が0.87.1以前とされていることと合わせると、0.88.0版で修正されたと読むのが自然ですが、勧告そのものには明記されていないため、この対応関係は推測を含みます。

中程度の勧告：他の利用者の通信中継を止められた

二つ目の勧告は、重大度が「中程度」、CVSS の値は6.5です。対象は、箱から外へ出る通信を中継する仕組みを始めたり止めたりする操作でした。勧告によると、この操作は経路を書き換える権限を持っているかだけを確かめ、対象の箱がその人のものかを確かめていなかったとされます。この権限は、標準的な利用者の通行証によく含まれるものだと書かれています。

その結果、その権限を持つ利用者なら、別の利用者の動いている中継を止めて、通信を使えなくすることができた、とされます。勧告は影響を可用性（使い続けられること）に限っており、他人の箱で中継を始めることもできたものの、それで中継を乗っ取れるかは確かめられていないと書いています。影響を受けたのは0.46.0以上0.81.1未満の版で、0.81.1版で、箱への接続の権限を他の操作と同じく確かめるよう修正されています。

この勧告は外部の報告者の名前が明記されており、報告を受けて修正し公表する流れが実際に働いたことを示しています。勧告の回避策は修正版への更新だけで、それまでは信頼できない利用者にその権限を持つ通行証を渡さないこと、とされていました。どちらの勧告も、該当する範囲より新しい版がすでに出ていますが、古い版のまま動かしている環境は、今も影響を受ける点に注意が要ります。

勧告から読み取れる運用上の教訓

二つの勧告は、どちらも箱の壁ではなく、基盤の管理の側で、誰が何をしてよいかの確かめ方に問題がありました。隔離環境の評価では、箱から抜け出せるかどうかに目が向きがちですが、共用の基盤では、管理の窓口の本人確認と、利用者ごとの持ち物の確認が同じくらい重要だということを示しています。

ここから企業が取り入れたい教訓は三つです。一つ目は、管理の窓口を、社内の網の中でも誰でも届く場所に置かないことです。重大の勧告の回避策が「届く相手を限る」だったように、網の上での隔てが最後の守りになります。二つ目は、権限の範囲（何をしてよいか）と持ち物（どれに対してか）を分けて確かめているかを、調達の際に問うことです。三つ目は、利用者に渡す通行証の権限を、標準のまま配らず必要な分に絞ることです。

もう一つの教訓は、更新の速さです。Containarium は1週間に10の版を出すことがあり、古い版は保守されず、最新版への更新が求められます。これは修正が早く届く利点である一方、更新を追い続ける体制がない組織にとっては負担になるということです。リリースノートを誰が読み、どの間隔で上げるかを決めずに導入すると、勧告の対象の版のまま残るおそれがあります。

悪用されうるリスク

Containarium は守りのための基盤ですが、性質上、悪用の余地がまったくないわけではありません。一つ目は、箱が外の世界に公開できることです。READMEは、箱の中で動かしたものを独自の住所で公開する流れを示しています。エージェントが作ったものが、確認を経ずに社外から見える状態になる可能性があり、騙されたエージェントが不適切な内容を公開する危険は、隔離では防げません。

二つ目は、計算資源の不正利用です。主張の文書には、脅威を見つける仕組みの説明として、計算の負荷を一定の値より低く保つ暗号資産の採掘は、決まりの一つを避けられる、という限界が率直に書かれています。共用の基盤に悪意のある利用者が入った場合、気づかれにくい形で資源を使われる可能性があると読み取れます。

三つ目は、導入の経路です。READMEには、配布元のスクリプトを取得してそのまま強い権限で実行する導入の方式が示されています。手軽な一方、配布元が乗っ取られた場合の影響を受けやすい方式です。また、監査の記録は改ざんに気づける作りですが、主張の文書は、記録の保管先に書き込める者や土台の機械の管理者は書き換えられる、と限界を明記しています。内部の強い権限を持つ人による悪用は、この基盤だけでは防ぎきれないと考えておくのが無難です。

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

Containarium を社内で試すかどうかを決める前に、少なくとも次の順で確かめておくと、後からの手戻りを防げます。

企業が取るべき対策

Containarium を使うかどうかにかかわらず、AIエージェントを共用の基盤で動かす企業が取るべき対策は共通しています。第一に、基盤の管理の窓口を、利用者やエージェントが届く網から切り離すことです。窓口の本人確認に弱点が見つかっても、届かなければ悪用されません。

第二に、モデルの鍵を箱に置かないことです。中継口のように基盤の側で鍵を持ち、箱には短い期限で範囲を縛った通行証だけを渡す作りにすれば、箱が乗っ取られても被害を小さくできます。中継口を使う設定になっていない箱が残っていないかも、定期的に確かめます。第三に、外への通信は許可したものに限り、既定の扱いを思い込みで決めず、実際の通信を外側で記録して確かめることです。

第四に、利用者ごとの権限と持ち物の確認を、調達の要件に入れることです。共用の基盤を選ぶときは、権限の範囲だけでなく、対象がその人のものかを確かめる作りかを問います。第五に、監査の記録を基盤の外の書き換えられない保管先へ送り、基盤の管理者でも手を入れられない形で残すことです。守りの道具そのものも、他の道具と同じく調達と更新の管理の対象にします。

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

Containarium はエージェントが箱を作り、部品を入れ、公開するところまで道具として渡せる作りです。だからこそ、どの守りを有効にするか、誰にどの権限を渡すか、何を社外に公開してよいかを、AIに判断させてはいけません。エージェントは作業を進めるために「この通信先も必要です」「公開すれば確認できます」と提案してきますが、その提案をそのまま通せば、基盤の守りは形だけになります。

エージェントが通信先の追加や公開を求めてきたら、なぜ必要なのか根拠を書かせ、人がその根拠を読んで判断する手順を入れます。管理用の窓口の道具がエージェントから見える状態にするかどうかも、人が先に決めます。人が確認する範囲を先に決めておくことが、自由度の高い基盤を安全に使うための要点です。避けたい使い方を挙げます。

• READMEの冒頭の説明を読んだだけで、外への通信の許可制や利用者どうしの境目が既定で効いていると思い込む
• エージェントに管理用の窓口の強い権限を持たせ、箱の作成や公開まで任せる
• 経路を書き換える権限を含む標準の通行証を、すべての利用者に配る
• 管理の受け口を社内の誰でも届く網に置いたまま運用する
• 更新の担当を決めず、勧告の対象の版のまま動かし続ける

どの例も、道具が悪いのではなく、人が決めるべきことを既定の設定やAIに委ねたことで起きる失敗です。基盤の安全は、何を有効にし、何を許したかで決まります。

よくある質問：勧告が出たOSSは使わないほうがよいのか

答えは「勧告が出たこと自体で判断せず、中身と対応の仕方で判断する」です。勧告が公開されているということは、問題が見つかり、修正され、利用者に知らされたということでもあります。Containarium の場合、外部の報告者の名前が載った勧告があり、セキュリティ方針の文書には報告から公表までの手順が明記されています。勧告が一つもないOSSが、調べられていないだけという場合もあります。

一方で、重大の勧告の中身は、管理の窓口の本人確認という、共用の基盤の根幹に関わるものでした。中心の約束に関わる問題が出たという事実は、他にも似た問題が残っていないかを自社で確かめる理由になります。導入するなら、管理の窓口を網の上で隔てる、通行証の権限を絞る、といった多重の守りを前提にするのが現実的です。

もう一つ、「前日に紹介された隔離環境の道具と何が違うのか」という問いもありそうです。Containarium の違いは、多くの利用者とエージェントを一つの基盤に載せる共用の運用と、利用者ごとの外への通信の方針、鍵の中継口と使用量の記録にあります。そのぶん基盤の管理の側に守るべき点が増える、というのがこの記事の見立てです。

• Containarium の機能・土台・窓口・ライセンス・リリースの状況は、GitHubのリポジトリ（README・安全性の主張の文書・鍵の中継口の設計の文書・セキュリティ方針の文書・リリースの一覧）を2026年10月22日に確かめた範囲に基づきます。版の更新が非常に速いため、内容が変わる可能性があります
• 二つの勧告の影響範囲・修正版・回避策は、GitHubの勧告ページの記載に基づきます。重大の勧告は修正版の欄が空欄で、0.88.0版で修正されたという対応関係は、同じ日のリリースノートの記載からの推測を含みます
• 配布物への署名は、安全性の主張の文書とリリースノートで記載が食い違っており、この記事では断定していません
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順や、勧告の悪用の方法は扱いません

まとめ

Containarium は、AIエージェントごとに隔離した箱を渡し、利用者ごとの外への通信の許可制と、モデルの鍵を箱の外で預かる中継口を備える、共用の運用を前提にした実行基盤のOSSです。ライセンスは Apache-2.0 で、作者自身が守りの一つひとつを裏付けの有無で分けて公開している点は、評価の手がかりとして貴重です。

一方で、多くの守りは既定で無効で、2026年9月には管理の窓口の本人確認と利用者の境目に関わる勧告が2件公開されました。重大の勧告は修正版の欄が空欄で、問題が見つからない部分があっても安全の保証ではありません。動かす版を確かめ、管理の窓口を網の上で隔て、有効にする守りと渡す権限を人が決め、AIには根拠を書かせたうえで、更新を追う担当を置くことが、Containarium との現実的な付き合い方です。

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