AIエージェントに鍵を渡さず要求ごとに認可する接続基盤OSS「Octelium」とは

「AIエージェントに社内の仕組みを触らせたいが、そのために長く使える鍵をエージェントの設定に書き込むのは怖い」「生成AIの利用キーを部署ごとに配ったら、誰がどれだけ使っているのか追えなくなった」——AIの業務利用を広げ始めた企業の、情報システム部門から聞こえてくる声です。どちらも鍵の管理の手間に見えますが、問題の芯はそこではありません。本当は、鍵を持たせた時点で、その鍵でできることすべてを、相手に期限なく任せてしまっていることが問題です。この記事では、利用者やAIエージェントに鍵を渡さずに、要求ごとに認可して接続を中継する自前運用の基盤OSS「Octelium」を取り上げ、一次情報で確かめられる仕組み、AIとMCPの中継機能、ライセンスと商用版の違い、導入前に確かめることを整理します。導入や設定の手順は扱いません。

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

Octeliumは、GitHubで公開されているOSSです。READMEは自らを「無料のオープンソースで、自社で運用する、統合型のゼロトラスト（社内か社外かで信用せず、接続のたびに確かめる考え方）の接続基盤」と説明しています。用途として挙げられているのは、リモート接続用の VPN の置き換え、ゼロトラスト型のネットワーク接続の基盤、自社の仕組みを外へ安全に公開する中継、API の入口（ゲートウェイ）、AIの提供元への入口、MCPの入口、コンテナで作ったアプリケーションの配備の土台などです。一つの仕組みで、人とプログラムの両方の接続をまとめて扱うことを狙っています。

配布の形を確かめます。リポジトリは組織のアカウントで2025年5月18日に作られました。組織のアカウント自体は2022年9月に作られ、公開しているリポジトリは20件あります。2026年10月22日時点でスターは4,110、派生は157、最後の更新は10月21日でした。一日あたりのスターの伸びは約7.9件で、作ったばかりのアカウントが急に注目を集めている形ではないことが分かります。

版の付け方は0から始まる番号で、確かめた時点の最新の付番は0.46.0（10月18日の変更に付いたもの）でした。READMEのよくある質問は、設計・機能・API はおおむね固まり、「まもなく1.0版の準備に入る」と書いています。つまり、活発に更新されている一方で、正式版の前の段階にあるOSSです。仕組みの土台には、コンテナをまとめて動かす基盤の Kubernetes を使います。

なぜ今「鍵を渡さない接続」が求められるのか

AIエージェントが業務で使われるようになり、エージェントに社内の仕組みやクラウドサービスを操作させる場面が増えました。そのとき多くの現場では、API の利用キーやデータベースの合言葉を、エージェントの設定や環境に書き込んで渡しています。READMEも、長く使えて権限の広すぎる利用キーを管理し配って回る必要をなくす、という狙いを掲げています。

鍵を直接渡す方式には、構造的な弱さがあります。鍵は一度渡すと、取り消すまで有効です。エージェントが悪意ある指示の紛れ込み（プロンプトインジェクション）で誤動作したり、設定ファイルがどこかに写されたりすれば、鍵でできることのすべてが、相手の手に渡りうる状態になります。しかも、同じ鍵を複数の人やエージェントで使い回していると、記録を見ても誰が使ったのかを区別できません。

Octeliumが示すのは、鍵を利用者の手元に置かず、接続の入口で預かるという考え方です。利用者やエージェントは自分の身元を入口に示し、入口は要求ごとに「この相手が、この操作を、いま行ってよいか」を判断します。鍵の配布をやめ、判断と記録を入口に集めるという発想は、AIエージェントの権限をどう絞るかに悩む企業にとって、検討する価値のある選択肢です。

仕組み：入口の代理役が要求ごとに判断する

公式の文書「Octeliumの動き方」によると、一つの導入単位は「クラスター」と呼ばれ、Kubernetes の上で動きます。守りたい接続先は一つずつ「サービス」として登録され、それぞれの前に身元を確かめる代理役が立ちます。代理役は接続先のネットワーク上の所在を隠し、利用者は代理役としかやり取りしません。

通してよいかの判断は、代理役とは別の判断役が担います。文書は、判断する役と実際に止める役を分けることで、それぞれを独立して増やせると説明しています。判断は要求ごとに行われ、通信の中身の種類（どの窓口のどの操作か、どんな問い合わせか）まで見て、利用者の属性や状況に応じて決まります。規則は、コードとして書いて管理する方式（ポリシーのコード化）です。一度通したら終わりではなく、要求のたびに判断し直す点が、従来の VPN との大きな違いです。

接続のしかたは二通りあります。一つは利用者の端末に専用の道具を入れ、暗号化した経路で社内の資源に私的につなぐ方式です。もう一つは、道具を入れずにブラウザなどから公開の入口を通ってつなぐ方式です。接続先は、外から直接届かない社内の網の中にあってもよく、READMEは受け付け用の口を外に開けずに済むことも特徴に挙げています。

鍵を渡さない接続（シークレットレス）の中身

この基盤の中心にあるのが、公式の文書が「シークレットレス（秘密を持たない）接続」と呼ぶ機能です。接続先が求める鍵や合言葉は、クラスターの中に「シークレット」として保管されます。利用者は短い有効期限の通行証で入口に身元を示し、入口の代理役が要求ごとに本物の鍵を差し込んで接続先へ渡します。文書は、この方式の狙いを「利用者に鍵を配ることをなくす」ことだと説明しています。

対応する接続の種類は、文書によるとウェブの API（利用キー、通行証、クラウドの署名方式など）、SSH での接続（合言葉や秘密鍵）、二種類の主要なデータベース、Kubernetes の操作、ブラウザ経由の遠隔画面、証明書で相互に確かめる通信などです。人もAIエージェントも、本物の鍵を一度も見ずに接続先を使えるのが、この機能の価値です。

ただし、押さえておきたい点が二つあります。一つ目は、鍵そのものが短命になるわけではないことです。文書の例には長く使える利用キーや秘密鍵がそのまま登場し、入口が鍵を定期的に作り替えるとは書かれていません。利用者が鍵を持たなくなるだけで、入口の中の鍵は長く有効なままです。二つ目は保管のしかたです。READMEは、保管した秘密を暗号化して守る機能を企業版の機能として挙げています。無償版で秘密がどう守られるかは、確認した文書の範囲では確かめられませんでした。

管理者を置かない設計と、短い有効期限

公式の文書とREADMEは、Octeliumには「管理者」という特別な利用者が存在しないと明記しています。何でもできる最上位の権限をあらかじめ持つ人を置かず、常に持っている権限はゼロ、が初期の状態だという設計です。誰が何をできるかは、すべて規則で決まります。

身元の確かめ方も確認できます。人は、社内の認証基盤（ID基盤）や外部の認証の仕組みと連携してログインし、追加の確認として生体認証や専用の鍵、時刻で変わる確認番号などを使えます。プログラムやAIエージェントなどの「仕事をする側」の利用者は、専用の通行証や、別の認証基盤が発行した証明を使います。認証に成功すると「セッション」が作られ、短い有効期限の通行証が結びつけられます。文書によると、その有効期限は初期設定で4時間で、全体の設定で変えられます。

企業の目線で言い換えると、AIエージェントにも一人の利用者として身元を与え、その身元に対して規則で権限を付ける形になります。人と同じ表の上で、エージェントの権限を見直したり止めたりできるのは、エージェントの棚卸しを人の棚卸しと同じ手順で回せるという意味で扱いやすい点です。

AIゲートウェイとしての機能

公式の手引きによると、Octeliumは生成AIの提供元への入口として使えます。対応する提供元として、OpenAI、Anthropic、Gemini、Amazon Bedrock が挙げられ、同じ形式の窓口を持つほかの提供元や、自社で動かすモデルにもつなげます。提供元の利用キーは入口に保管され、利用者は自分の身元で入口に接続するため、社員やエージェントが提供元の利用キーを見ることはないと説明されています。

入口では、要求の中身に応じた規則をかけられます。手引きによると、使うモデル、出力の上限、道具を呼ぶかどうか、画像を渡すかどうかといった項目を、提供元ごとの書式の違いを吸収した形で判断に使えます。さらに、決まった指示文を必ず差し込む、利用者が送る指示文を拒む、呼べる道具を名前で絞る、といった機能もあります。送る内容や返ってきた内容から秘密や個人情報らしきものを見つけて止めたり伏せたりする仕組み（ガードレール）も用意されています。利用量の上限を利用者ごとに決める機能もあり、誰がどのモデルをどれだけ使ったかを入口で数えられるようになります。

記録についても書かれています。誰が、どのモデルを求め、実際にどのモデルが使われ、どれだけの量を消費したか、といった項目が記録されます。一方で、指示文と回答の本文は、初期設定では記録しないと明記され、本文を記録すると監査の記録に機密が残りうると注意書きがあります。返答側のガードレールは止めることしかできず、流しながら返す方式の回答は生成が終わるまでためてから判断する、という制約も書かれています。

MCPゲートウェイとしての機能

MCPは、AIと外部の道具をつなぐ取り決めです。公式の手引きによると、OcteliumはMCPの利用者側と道具の提供側の間に立ち、MCPのやり取りの中身を理解したうえで中継します。判断に使えるのは、どの種類の呼び出しか、どの道具・資料・指示文の名前か、どんな引数が渡されたかです。道具の名前や引数の単位で、呼んでよいかを利用者ごとに決められるということです。

身元の扱いについて、手引きは重要な線を引いています。認可は、Octeliumが確かめた身元（利用者、セッション、端末、所属する集団）に結びつけられ、利用者側が自分で申告する情報（自称の名前や対応機能、セッションの番号）は身元として使わないと明記されています。また、道具の提供側が求める鍵は入口が差し込み、利用者側の通行証は道具の提供側へ渡さないと書かれています。道具の提供側に、利用者の身元の証明が流れていかない設計です。

返ってくる内容の側にもガードレールをかけられ、手引きは道具の説明や結果に紛れ込む悪意ある指示（ツールポイズニング）への備えを目的に挙げています。記録については、MCPのやり取りの種類や道具の名前などが残ります。ここで注意したいのは、MCPの入口では、要求と応答の本文が初期設定で記録されることです。AIゲートウェイの初期設定とは逆なので、道具の結果に個人情報や機密が含まれる業務では、記録の保管先と閲覧できる人を先に決めておく必要があります。

既存の手段との違い

Octeliumが置き換えの対象として挙げるのは、商用の VPN、クラウド型のゼロトラスト接続のサービス、API の入口の製品などです。ここでは、AIエージェントに社内の仕組みを使わせる場面に絞って、企業がよく取る手段と比べました。製品ごとの優劣ではなく、鍵と判断がどこにあるかの違いとして見てください。

見る点	鍵を直接渡す	VPN でつなぐ	Octelium（自社で運用）
鍵の置き場所	エージェントの設定や環境	エージェントの設定や環境	入口の中（利用者には渡さない）
判断の単位	鍵の権限の範囲で一律	網に入れるかどうか	要求ごと・操作の種類ごと
誰が使ったかの記録	鍵を共有すると区別しにくい	接続の記録が中心	利用者・セッション単位で要求ごと
止めたいときの手段	鍵を作り直して配り直す	接続の権限を外す	身元や規則を止める
運用の負担	小さいが漏れたときの影響が大きい	中程度	基盤そのものの運用と保守が要る

表のとおり、Octeliumは鍵と判断を入口に集めることで、細かな認可と記録を手に入れます。その代わり、入口そのものを自社で動かし、更新し、守り続ける負担を引き受けることになります。クラウド型のサービスなら提供元が負う運用を、自社で負う選択です。社内に Kubernetes を運用できる人がいるか、障害のときに誰が対応するかは、機能より先に確かめておくべき点です。

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

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

根拠にした事実は次のとおりです。ライセンスは、中核部分がAGPL第3版、利用者側の道具がApache 2.0で、どちらも広く認められたオープンソースのライセンスです。組織のアカウントは2022年9月に作られ、リポジトリは2025年5月から1年以上更新が続いています。GitHub上にこのリポジトリのセキュリティ勧告は登録されていませんでした。弱点の報告先を書いた文書（セキュリティポリシー）はあり、専用の連絡先が示されています。取り込みのときに自動で動く処理を含む設定は見当たらず、目についたのは組み立て用の定義ファイルだけでした。

ただし、勧告がないことや自動実行がないことは、安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身や認可の判断が正しく働くかを検証したものではないからです。しかも、この基盤は社内のあらゆる接続の入口になり、鍵を一か所に集めます。入口の弱点は、そのまま社内全体の弱点になる性格の道具なので、勧告の登録状況と更新は導入後も追い続ける必要があります。

ライセンスの注意：AGPLと商用ライセンス・企業版の書き分け

Octeliumのライセンスは、部分ごとに分かれています。READMEによると、利用者側の道具、開発用の部品、共通の部品はApache 2.0で、クラスター側の中核部分はAGPL第3版です。そのうえで、開発元の Octelium Labs は、AGPL第3版の条件に従いたくない企業向けに、別の商用ライセンスを用意していると書いています。さらに、有償の企業版の機能は、別のリポジトリでソースを公開する独自のライセンス（自由なオープンソースのライセンスではない）で提供されています。

区分	ライセンス	企業として押さえる点
利用者側の道具・共通の部品	Apache 2.0	改変や再配布の自由度が高い
クラスター側の中核部分	AGPL第3版	改変してネットワーク越しに使わせると、その相手にソースを示す義務が生じうる
中核部分の商用ライセンス	開発元との個別契約	AGPLの条件に従わずに使いたい場合の選択肢。条件と価格は公開されていない
企業版の機能	ソース公開の独自ライセンス	個人の非商用は無償。業務や本番での利用には企業版の契約が要る

AGPL第3版の本文（第13条）は、プログラムを改変し、ネットワークを通じて利用者がそれと関わる場合、その利用者に対応するソースを入手できるようにすることを求めています。社内の利用だけか、取引先や顧客にも使わせるか、改変するかしないかで、負う義務の範囲が変わるため、取引先に接続させる計画や、自社で手を加える計画があるなら法務の確認を先に取ってください。ここでの整理は条文の要点で、個別の判断は専門家に委ねるべきものです。また、企業版の案内には、画面での管理、ログの分析基盤への送り出し、秘密の暗号化、期限付きの承認の流れなどが並びます。無償版でどこまで足り、どこから企業版が要るかを、自社の要件で切り分けておく必要があります。

運営体制と成熟度：一人の開発者と正式版の前

READMEのよくある質問によると、Octeliumは Octelium Labs という会社の唯一の所有者である一人の開発者が開発しています。外部からの資金は受けておらず、企業向けの支援、商用ライセンス、企業版の機能で成り立っていると説明されています。また、現時点では外部からの変更の提案（プルリクエスト）は受け付けておらず、不具合の報告や機能の要望は受け付けるとしています。

この体制には、利点と注意点の両方があります。設計の一貫性を保ちやすく、商用の収益で開発が続く筋道も示されています。一方で、一人の事情しだいで更新や弱点の修正が止まる可能性は、複数の組織が支えるOSSより高いと見ておくのが妥当です。社内のあらゆる接続の入口に置く道具としては、保守が止まったときの影響が大きくなります。

成熟度についても、README自身が慎重に書いています。一台で動かす構成は開発、個人の利用、負荷の小さい本番向けとされ、複数台の本番の構成も可能だとしています。ただし版の番号はまだ1.0に達していません。本番の主要な入口に据えるなら、正式版の到来と、それまでの変更の多さを前提に計画するのが現実的です。商用の支援を受けるかどうかも、この判断と一緒に考えます。

悪用されうるリスク

Octeliumは守りのための基盤で、攻撃に使うためのものではありません。それでも、設計の性格から生まれうる危険はあります。最も大きいのは、鍵と判断が一か所に集まるため、入口を乗っ取られると影響が社内全体に及ぶことです。管理者を置かない設計でも、規則を書き換えられる立場の人や仕組みがあれば、そこが実質的な最上位の権限になります。

次に挙げるのは推測ですが、検討の材料として無視できません。一つは、外へ公開する中継の機能を、現場が手軽な公開手段として使ってしまうことです。READMEは身元を確かめない公開の使い方にも触れており、規則の書き方しだいで、社内の仕組みが外から誰でも届く状態になりえます。もう一つは、接続先の証明書の確認を止める選択肢があることです。文書自身が通信の安全性を弱めると注記しており、検証の手間を省くために使われると、入口の先で通信をすり替えられる余地が生まれるおそれがあります。

さらに、記録に残る情報そのものも守る対象になります。MCPの入口では本文が初期設定で記録されるため、記録の保管先が新たな機密のたまり場になりえます。記録の閲覧権限と保存期間を、入口の規則と同じ重さで決めることが前提です。なお、Octeliumが実際に悪用された事例は、2026年10月22日時点で確認した一次情報からは見つけられませんでした。

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

実際に検討するときは、動かす前に、資料と社内の取り決めで確かめられる点から整理します。下の手順は、OSSを動かす前の段階で終えられるものに絞っています。

この手順の要は、機能を試す前に「鍵を集める重さ」と「ライセンスの条件」を確かめておくことです。入口の基盤は、一度社内の接続を集めると後から外しにくくなります。後戻りのしにくさを踏まえて、最初の判断に時間をかけてください。

企業が取るべき対策

一つ目は、AIエージェントに長く使える鍵を直接渡す運用を減らすことです。Octeliumを使うかどうかにかかわらず、エージェントごとに身元を分け、使える操作を絞り、短い期限で切れる通行証に寄せていく方針を立てます。鍵を配る運用から、要求ごとに認可する運用へという方向は、どの製品を選んでも共通です。

二つ目は、入口を最重要の資産として守ることです。鍵を集める基盤を入れるなら、規則を書き換えられる人を最小限にし、規則の変更を記録と承認の対象にします。入口の中の鍵が長く有効なままであることを踏まえ、接続先の鍵の作り替えの周期も別に決めます。三つ目は、記録の活用です。要求ごとの記録を、ログの分析の仕組みで見られるようにし、想定外のモデルや道具の呼び出しを見つけられるようにします。

四つ目は、外への公開の扱いを規程に入れることです。身元を確かめない公開や、証明書の確認を止める設定は、原則として使わないと決め、例外は申請制にします。五つ目は、調達のときの確認です。ライセンスの区分、商用ライセンスの要否、運営体制、弱点の報告先、正式版までの見通しを、導入前に文書で残します。使い続けるかどうかを、半年ごとなど決めた間隔で見直すことも含めておきます。

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

Octeliumは、AIエージェントに仕事をさせるための入口を作る基盤です。企業版の案内には、自然な言葉でクラスターを管理できるAIの助手も挙げられています。便利な一方で、誰に何を許すかの判断をAIに委ねてしまうと、入口の線を引く人がいなくなります。

規則の下書きをAIに作らせることはあっても、AIに判断させてよいのは下書きまでです。規則の一つひとつに、なぜその許可が要るのかという根拠を書かせ、人がすべての許可を読み、根拠に納得できないものは外すという確認の段階を必ず置きます。人が確認する範囲（鍵を預ける接続先、外への公開、記録の扱い）を先に決めておくことが前提です。やってはいけない向き合い方を挙げます。

• 「鍵を渡していないから安全」として、エージェントに呼べる道具や操作を絞らずに広く許す
• AIが書いた認可の規則を、許可の中身と根拠を読まずにそのまま適用する
• MCPの入口で本文を記録していることを知らないまま、個人情報を扱う道具をつなぐ
• ライセンスの条件を確かめず、改変した入口を取引先に使わせる
• 検証の手間を省くために、接続先の証明書の確認を止めたまま本番で使う
• 入口の運用と更新の担当を決めず、勧告が出ても誰も気づかない

裏を返せば、人が決める範囲ははっきりしています。どの鍵を入口に預けるか、誰に何を許すか、何を記録してどこに残すか、どのライセンスで使うか。この四つを決めたうえで、決めた範囲の判断を入口に毎回確実に実行させるのが、仕組みとAIの正しい使い分けです。

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

答えは「それだけでは足りない」です。鍵を渡さない接続が防ぐのは、鍵そのものが持ち出されて別の場所で使われることです。エージェントが許された範囲の中で誤った操作をすることや、許された道具の結果に紛れ込んだ悪意ある指示に従ってしまうことは、鍵の有無とは別の問題です。要求ごとの規則で操作の範囲を絞り、記録で後から確かめることと組み合わせて、初めて守りの厚みが出ます。

では入れる意味がないのかというと、そうではありません。鍵の配布をやめられれば、鍵が漏れたときの影響を大きく減らせます。誰がどの操作をしたかが要求ごとに残るため、事故のときに範囲を絞り込む手がかりにもなります。もう一つ、「クラウド型のゼロトラスト接続のサービスと比べてどうか」という問いもありそうです。自社で運用することで鍵と記録を手元に置ける一方、運用の負担は自社が負います。どちらが合うかは、運用の体制と扱う情報の区分で決まります。

• Octeliumの機能・構成・ライセンス・運営体制は、GitHubのリポジトリとREADME、公式の文書と手引き、企業版の案内、AGPL第3版の本文を2026年10月22日に確かめた範囲に基づきます。内容は版によって変わる可能性があります
• 無償版で保管した秘密がどう守られるか、商用ライセンスの条件と価格は、確認した一次情報の範囲では確かめられませんでした
• ライセンスの整理は条文の要点で、法的な助言ではありません。個別の判断は法務や専門家に確認してください
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Octeliumは、人とAIエージェントの両方について、社内の仕組みやクラウドの窓口、生成AIの提供元、MCPの道具への接続を、要求ごとに認可して中継する自前運用の基盤OSSです。鍵は入口で預かり、利用者には渡しません。管理者を置かない設計、短い有効期限の通行証、要求ごとの記録を備え、AIとMCPの入口ではモデルや道具の単位で使える範囲を絞れます。

一方で、鍵と判断が入口に集まるため、入口を守る責任は重くなります。中核部分はAGPL第3版で、改変して社外に使わせる場合の義務や、商用ライセンス・企業版との切り分けを確かめる必要があります。開発は一人の開発者の会社が担い、正式版の前の段階です。預ける鍵、許す範囲、記録の扱い、ライセンスと保守の体制を先に決めたうえで使うことが、AIエージェントの権限に悩む企業にとってのOcteliumの使いどころです。

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