AIエージェントに鍵を渡したくない企業が知っておきたい隔離用OSS「Cordium」の使いどころ

「コーディング用のAIエージェントに社内のデータベースを触らせたいが、接続用のパスワードを渡すのは怖い」「AIエージェントが動く環境に、いつの間にか鍵や認証の情報が何本も置かれている。誰が何を持っているのか把握できない」——AIエージェントを業務に組み込み始めた企業の、情報システムやセキュリティの担当者から上がってくる声です。AIエージェントの守りというと、まず「隔離された箱の中で動かす」ことに目が向きます。しかし箱に入れるだけでは足りません。本当は、箱の中から社内のシステムへつなぐときに、鍵そのものを箱の中に置かないことが、情報の持ち出しや鍵の流出を防ぐ要になります。この記事では、AIエージェントや開発者の作業場所を隔離し、鍵を渡さずに社内システムへつなぐOSS「Cordium」について、一次情報で確かめられる仕組み、似た手段との違い、ライセンスの書き分け、企業が使う前に決めることを整理します。導入や設定の手順は扱いません。

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

Cordium は、GitHub上で公開されている、開発者とAIエージェントのための作業場所（サンドボックス、つまり外から切り離された実行環境）を自社で運用するための仕組みです。READMEは自らを、自社で運用する、本人確認に基づく汎用のサンドボックスの基盤と説明しています。コンテナ（アプリを周りから切り離して動かす技術）を管理する Kubernetes の上で動き、同じ組織が開発する Octelium という接続管理の仕組みを土台にしています。

公開の時期と規模も押さえておきます。リポジトリは2026年3月1日に作られ、2026年10月20日にも更新されています。2026年10月21日時点でスターはおよそ84、複製（フォーク）は10です。公開している組織のアカウントは2022年9月に作られ、公開リポジトリは19あります。土台の Octelium のリポジトリはスターがおよそ4,100あり、README によると Octelium Labs社を通じて開発されています。

版の公開も続いています。リリースの一覧では、2026年10月16日に公開された0.17.1が最新で、10月だけでも三つの版が出ています。版番号はまだ1.0に達しておらず、変化の速い段階のソフトウェアと見ておくのが妥当です。機能や仕様は今後も変わりうるため、この記事の内容は確認した日付の時点のものとして読んでください。

AIエージェントに鍵を渡す運用の何が問題か

AIエージェントにコードを書かせたり、テストを流させたりする場面が増えると、エージェントが社内のデータベースや内部の仕組み、別のサーバーへ接続する必要が出てきます。手っ取り早いのは、接続用のパスワードやトークン（認証の合言葉にあたる文字列）を、エージェントが動く環境に置いておくことです。しかしこれは、エージェントが読めるものは、エージェントが外へ出せるものでもあるという問題を抱えます。

AIエージェントは、読み込んだ文書やウェブの情報に紛れた命令に影響される可能性があります。紛れ込んだ命令によって、手元にある鍵を外部に送ってしまう、という流れは、守る側が最も避けたい筋書きの一つです。また、作業場所を作るたびに鍵を配ると、どこに何の鍵があるのかが分からなくなる「鍵の散らばり」が起きます。README はこの散らばりを減らすことを第一の設計目標として掲げています。

つまり、問われているのは「エージェントを箱に入れるかどうか」だけではありません。箱の中から外へつなぐとき、誰の権限で、何の鍵を使って、どこまで許すのか。この線引きをどこで行うかが、AIエージェントを社内で動かすときの守りの中心になります。Cordium は、この線引きを作業場所の外に置く設計をとっています。

主な仕組み1：隔離された作業場所と、繰り返し作れる環境

README によると、Cordium の作業場所（ワークスペース）は、管理者権限を持たないまま動くコンテナ型の隔離環境で、標準的な Kubernetes の上で動きます。ブラウザの端末、遠隔ログインの仕組み（SSH）、専用の命令の道具、プログラムから呼び出す窓口のどれからでも使えるとされています。作業場所は、中身を残し続ける使い方と、使い終わったら消える使い方の両方ができ、作業が終わると自動で止めることもできます。

環境の中身は設定ファイルに宣言的に書く形で、使う土台の環境、取り込むリポジトリ、起動時の処理、資源の上限などを決めます。同じ設定を「テンプレート」として使い回せるため、人ごと・作業ごとに同じ条件の環境を何度でも作り直せるのが特徴です。準備の済んだ状態を写しとして保存し、起動を速める仕組みもあると説明されています。

公式ドキュメントでは、作業場所から外への通信を、既定ですべて拒否したうえで許す宛先だけを開ける規則を書けることや、中身を書き換えられない読み取り専用の土台を選べること、資源の上限を作業場所・テンプレート・組織単位などの段階で決められることも挙げられています。一方で、作業場所の中では管理者の権限が使えるとも書かれており、隔離の強さは後で見るように過信しないほうがよい点です。

主な仕組み2：鍵を作業場所に置かずに社内システムへつなぐ

Cordium の一番の特徴は、README が「シークレットレス」と呼ぶ、鍵を持たない接続です。README によると、作業場所からデータベース、SSH のサーバー、内部の仕組みの窓口、Kubernetes の環境などへ接続するとき、接続用の鍵やパスワードは作業場所には届かず、手前に置かれた Octelium の関所（本人確認を行う中継役）が持っています。

作業場所からの要求が関所に届くと、関所は作業場所の身元を確かめ、許可された相手であれば、通信の段階で鍵を付け足して接続先へ取り次ぐ、という流れです。公式ドキュメントでは、言語モデルの提供元の窓口への接続も同じ扱いの対象として挙げられています。作業場所の中のエージェントから見ると、鍵を一度も手にしないまま、必要な接続だけができることになります。

この設計の意味は、仮にエージェントが紛れ込んだ命令に操られても、手元に盗める鍵がないことです。もちろん、許可された範囲の接続はできてしまうため、被害がゼロになるわけではありません。ただ、鍵そのものが外へ出て別の場所から使い回される、という最悪の筋書きは起きにくくなります。なお README の設定例には、保管した秘密の値を作業場所の環境変数として渡す例も含まれており、鍵を置かない運用は自動で実現するものではなく、設計の選び方次第だと読み取れます。

主な仕組み3：要求ごとの許可判断と、すべての操作の記録

README によると、それぞれの作業場所には Octelium 上の「セッション」という身元が与えられ、社内システムへの接続は要求ごとに許可の判断が行われます。判断は、通信の中身の段階まで見たうえで、利用者や作業場所の属性に応じて決める方式で、方針はプログラムのように書いて管理する形（ポリシー・アズ・コード）をとり、CEL や OPA という方針を書くための言語に対応しています。

既定の考え方は、常に持っている権限をなくし、必要なときだけ許すというものです。公式ドキュメントでは、Octelium には何でもできる管理者という利用者の概念そのものがない、とも説明されています。人の本人確認には、社内の認証基盤とつなぐ一般的な方式や、パスキー、ワンタイムパスワード、多要素の認証などが使えるとされています。

記録の面では、すべての要求が身元と通信の中身の情報付きで記録され、OpenTelemetry という記録の受け渡しの標準的な形式で、ログの管理や SIEM（セキュリティの監視基盤）へ送れると書かれています。どのエージェントが、いつ、どのシステムに、何を要求したかを後から追えることは、問題が起きたときの調査にも、日々の点検にも欠かせない材料です。

企業での使いどころ：三つの場面

README は使い道として、遠隔の開発環境、AIエージェントや自動処理のための作業場所、開発者とAIエージェントの鍵を持たない社内システムへの接続の三つを挙げています。企業の視点で言い換えると、次のような場面が考えられます。

一つ目は、コーディング用のAIエージェントを、社員の手元の端末ではなく管理された作業場所で動かす場面です。エージェントが端末上の他の情報に触れる心配を減らし、終わったら環境ごと消せます。二つ目は、テストや検証の自動処理で、試験用のデータベースや内部の窓口に接続する必要がある場面です。鍵を処理の設定に埋め込まずに済む点が利点になります。

三つ目は、外部の協力会社や新しく加わった開発者に、限られた範囲の社内システムを使わせる場面です。鍵を配らず、身元と方針で範囲を決め、記録を残せます。ただし、これらは README の説明から想定される使い方であり、自社の規模や既存の仕組みで同じ効果が出るかは、試してみないと分からない点に注意が必要です。とくに Kubernetes を運用する体制がない企業には、導入の負担が大きくなる可能性があります。

似た手段との違い

README には、ほかの作業場所の仕組みと比べた表が載っています。比べられているのは、AIエージェント向けのサンドボックスの基盤や、遠隔の開発環境のサービスです。表は Cordium の開発元が作ったもので、各製品の評価は開発元の見方であることを前提に、防御側に関係する項目だけを抜き出して並べます。

製品	鍵を持たない社内システムへの接続	隔離の方式	自社での運用	事業者が運用するサービス
Cordium	あり	管理者権限なしの入れ子のコンテナ	できる	なし
Daytona	なし	コンテナ（追加の隔離層を使う方式）	できる	あり
E2B	なし	軽量の仮想マシン（Firecracker）	限定的	あり
GitHub Codespaces	なし	仮想マシンまたはコンテナ	できない	あり
Coder	なし	コンテナまたは仮想マシン	できる	あり

表から読み取れるのは、Cordium の強みが「鍵を持たない接続」と「自社での運用」にある一方、隔離の方式は仮想マシンを使う製品よりも軽い仕組みだということです。一般に、仮想マシンによる隔離はコンテナによる隔離よりも境界が強いとされます。どちらを重く見るかは、作業場所で何を動かすかによって変わります。また、事業者が運用するサービスはなく、自社で運用する前提になります。

土台のOctelium と、ライセンスの書き分け

ライセンスは、Cordium と土台の Octelium とで分けて考える必要があります。README によると、Cordium 自身のソースはApache-2.0で、OSI（オープンソースの定義を管理する団体）が承認した緩やかなライセンスです。README は、事業者が管理する中枢の仕組みも機能の段階分けもないと説明しています。

一方で、README は、Cordium の部品や一式の配備には Octelium の中核部分が含まれうるとし、その部分はAGPL第3版で公開されていると書いています。AGPL第3版も OSI 承認のライセンスですが、ネットワーク越しに使わせる場合にもソースの公開を求める条件を持つため、社内での利用と、社外へ提供する場合とで読み方が変わります。

さらに Octelium の README によると、AGPL第3版に従いたくない企業向けに商用ライセンスが別に用意され、追加の機能は別のリポジトリで、ソースは読めるがOSSではない条件のもとで提供されているとされています。つまり中心は OSS だが、周辺に商用の選択肢がある構成です。Cordium の公式ドキュメントにも企業向けの案内への導線がありますが、その中身は確認した範囲では分かりませんでした。どの部分をどの条件で使うのかは、自社の法務に確かめてください。

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

このラインでは、OSSを取得・導入・実行せず、公開されている情報と精査の記録をもとに安全性を判定しています。Cordium の判定は「紹介可」です。根拠は次のとおりです。

一つ目に、ライセンスがOSI承認のApache-2.0で、土台の部分もOSI承認のAGPL第3版です。二つ目に、公開している組織のアカウントは2022年に作られており、作られたばかりのアカウントではありません。三つ目に、精査した2026年10月21日の時点で、リポジトリに公開済みのセキュリティ勧告はありませんでした。四つ目に、取り込んだときに自動で動く処理（導入の際に勝手に実行される仕組み）は見つからず、目に付いたのは開発用の手順をまとめたファイルだけでした。スターの伸びも1日あたり0.4程度で、不自然な急増は見られません。

ただし、問題が見つからなかったことは安全の保証ではありません。精査は公開情報の範囲にとどまり、ソースの中身を一行ずつ確かめたものではありません。Cordium は社内システムへの接続の関所という重要な役割を担う仕組みなので、導入するなら、他の重要な基盤と同じ水準で自社の確認を行うべきです。

注意点：成熟度と、報告窓口がないこと

紹介可とした一方で、使う前に知っておきたい点もあります。第一に、成熟度です。版番号は0.17で、2026年10月だけで三つの版が出ています。README は一台の機械で動かす構成について、「ほとんどの開発用途、個人用途、負荷の高くない本番用途には十分」と書いており、大規模な本番での実績については、確認した一次情報からは分かりませんでした。

第二に、セキュリティ上の問題の報告窓口を定めた方針の文書が、リポジトリに置かれていません。2026年10月21日時点で、リポジトリのセキュリティの欄には方針の文書がない旨が表示されていました。接続の関所という役割を考えると、問題が見つかったときの報告と修正の流れが見えにくい点は、導入の判断で記録しておくべき事項です。

第三に、運営体制です。Octelium の README によると、開発は一人の開発者が Octelium Labs社を通じて行っているとされています。小さな体制で活発に開発されているOSSは珍しくありませんが、開発が止まったときに自社で保守できるかを考えておく必要があります。自社で運用する仕組みである以上、更新の追従も自社の責任になります。

悪用されうるリスクと、隔離を過信する危うさ

Cordium は守るための仕組みですが、使い方を誤れば別の危険を生みます。もっとも大きいのは、関所そのものが狙われる危険です。鍵を作業場所から取り除くということは、鍵が関所に集まるということでもあります。関所が乗っ取られたり、方針が書き換えられたりすれば、多くの社内システムへの接続がまとめて開いてしまう可能性があります。

次に、隔離の過信です。表で見たとおり、Cordium の隔離はコンテナ型で、作業場所の中では管理者の権限が使えると公式ドキュメントに書かれています。一般に、コンテナの境界を越える手口は過去にも報告されてきました。Cordium について具体的な問題が報告されているわけではありませんが、信頼できないコードを動かす場面では、隔離の強さを別の手段で補うことも検討に値します。

さらに、許可の範囲が広すぎれば、鍵を持たないエージェントでも、許された接続を使って情報を読み出せてしまいます。鍵を持たないことは鍵の流出を防ぎますが、許可された操作の悪用までは防げません。外への通信を既定で拒否する設定や、接続先ごとの細かな許可と組み合わせて、初めて意味のある守りになります。これらは推測を含む一般的な注意であり、Cordium 固有の欠陥を示すものではありません。

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

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

企業が取るべき対策

Cordium を使うかどうかにかかわらず、AIエージェントを社内で動かす企業が取るべき対策は共通しています。第一に、エージェントが動く環境に、長く使える鍵を置かないことです。どうしても渡す場合は、権限を最小にし、期限を短くし、どこに置いたかを台帳で管理します。

第二に、許可の判断をエージェントの外に置くことです。エージェントへの指示文で「〜してはいけない」と書くのではなく、接続の手前の仕組みで確実に止めます。Cordium の関所はその一つの形です。第三に、外への通信を既定で絞り、必要な宛先だけを開けます。紛れ込んだ命令で情報を外へ送られる筋書きへの、もっとも基本的な備えです。

第四に、エージェントの操作の記録を、既存の監視の仕組みに集めることです。誰の作業場所から、どのシステムへ、何を要求したかを後から追えるようにし、ふだんと違う動きを見つけられるようにします。第五に、社内のAI利用の規程に、エージェントに許す接続先、鍵の扱い、記録の保存期間、点検の頻度を書き込みます。仕組みと規程の両方に組み込むことが、守りを続ける前提になります。

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

Cordium には、利用者の作業場所の中で、その利用者の身元のもとで動く組み込みのAIエージェントもあると公式ドキュメントに書かれています。エージェントに作業を任せる仕組みが整うほど、何をAIに任せ、何を人が決めるのかの線引きが大切になります。

AIに任せてよいのは、許された範囲の中での作業そのものです。一方、どの接続先を許すか、方針をどう書くか、記録のどこを問題とみなすかは、AIに判断させず、人が先に決める範囲です。エージェントに方針の変更を提案させる場合も、変更の理由と根拠を書かせ、人が読んで承認する手順にします。避けたい使い方を挙げます。

• 鍵を持たせないから安全だとして、許可の範囲を広く取ったままにする
• 許可の方針の書き換えを、AIエージェント自身に任せて人が確かめない
• 作業場所の中で管理者の権限が使えることを知らずに、信頼できないコードを動かす
• 操作の記録を集めるだけで、誰も読まない
• ライセンスを確かめずに、社外向けのサービスに組み込む

記録についても同じです。AIで記録を要約させたり、怪しい動きを拾わせたりするのは効率的ですが、拾い上げた理由を必ず書かせ、最終的な判断は人が記録の原文を見て行うことを手順に入れておきます。人が確認する範囲を先に決めておけば、AIの見落としや思い込みに引きずられにくくなります。

よくある質問：鍵を渡さなければ、AIエージェントは安全なのか

答えは「鍵の流出という一つの大きな危険は減らせるが、それだけでは足りない」です。鍵を持たないエージェントでも、許された接続を通じて情報を読み出し、許された宛先へ送ることはできます。Cordium の設計が効くのは、鍵が別の場所から使い回される危険と、鍵の散らばりによる管理の難しさに対してです。

そのため、鍵を持たない接続は、外への通信の制限、接続先ごとの細かな許可、記録の点検と組み合わせて考える必要があります。「隔離」「鍵を持たない接続」「許可の方針」「記録」の四つがそろって初めて、エージェントに何が起きても被害の範囲を見積もれる状態に近づきます。

もう一つ、「事業者が運用するサービスと比べてどうか」という問いもありそうです。Cordium は自社で運用する前提で、事業者のサービスはありません。自社の基盤の中で完結させたい企業には利点になりますが、運用の負担を引き受けられるかが分かれ目です。運用の実績や大規模な本番での事例は、確認した一次情報の範囲では限られます。

• Cordium の機能・設計・ライセンスは、GitHubのリポジトリ（README・リリースの一覧・セキュリティの欄）、公式ドキュメント、土台の Octelium のリポジトリを2026年10月21日に確かめた範囲に基づきます。版の更新で内容は変わる可能性があります
• 企業向けの案内の中身、大規模な本番での運用の実績、隔離の方式の詳しい作りは、確認した一次情報の範囲では確かめられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Cordium は、開発者とAIエージェントのための隔離された作業場所を自社の Kubernetes の上で運用し、社内システムへの接続では鍵を作業場所に置かず、手前の関所が本人確認のうえで取り次ぐOSSです。要求ごとの許可判断と、すべての要求の記録を備えている点も特徴です。

一方で、版はまだ0.17で変化が速く、セキュリティの報告窓口の文書はなく、隔離はコンテナ型です。Cordium 自身はApache-2.0ですが、土台の Octelium の中核部分はAGPL第3版で、商用ライセンスや追加機能も別にあります。鍵を渡さない設計を活かしつつ、許可の範囲と記録の確認は人が先に決め、運用の体制とライセンスを確かめたうえで試すことが、Cordium との現実的な付き合い方です。

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