Mysteriumが露呈させたAIエンドポイント、セルフホスティングは「安全」の言い訳を失った
Mysteriumが露呈させたAIエンドポイントの規模は、単なる設定ミスを業界全体への警告へと変えるものだ。同社の研究者は、到達可能なシステムを36,769件特定した一方、HTTP認証チャレンジを返したのはわずか741件だった。
9月10日の調査は、モデルサーバー、チャットインターフェース、エージェントビルダー、ベクトルストアのコンソールを対象とした。これらのコンポーネントは、AIモデルと、その周囲にある人、文書、認証情報、アプリケーションをつなぐ運用レイヤーを構成している。
これはセルフホスト型AIにとって厄介な矛盾を生む。企業はしばしば、プロンプトや機密データの管理を維持するためにモデルをローカルで稼働させる。しかし、多くの導入環境はネットワークレベルのゲートなしに到達可能とみられ、信頼の重心はアプリケーションセキュリティ、パッチ適用、正しい設定へと移っている。
この件数は、36,769件のすべてが非公開情報を露出していたことを証明するものではない。一部のアプリケーションでは、読み込み後にユーザーのサインインを求める可能性もある。それでもこの調査結果は、数千に上るAIサービスがインターネットスキャナーに直接その存在を示していることを浮き彫りにした。
この違いは重要だ。ログインページが見えているだけでも、そこには新たな脆弱性、盗まれたパスワード、弱いデフォルト設定、自動化された探索行為に耐えなければならない公開アプリケーションが存在する。プライベートネットワークや認証済みゲートウェイの背後にあるサービスは、攻撃対象がより小さい。
したがって比較すべきなのは、単純なローカルAI対ホスト型AIではない。原理上の管理と、導入時の管理との対比である。Mysteriumの結果は、組織がセルフホスティングの価値を支えるセキュリティ境界を一貫して運用しないまま、セルフホスティングを選択していることを示唆している。
稼働中のAIスタック全体に広がるMysteriumが露呈させたAIエンドポイント
中心的な発見は、単一の脆弱な製品ではない。パブリックインターネットから把握できる、認識可能なAIスタックの存在だ。
Mysteriumによると、研究者は特定したマシンを直接プローブするのではなく、第三者のスキャンインデックスを利用した。元の調査では、一般的なAIソフトウェアに関連するページタイトル、レスポンステキスト、ポートなどのサービスフィンガープリントを検索した。
最終データセットには、36,769件の自己識別可能なエンドポイントが含まれていた。この大半を占めたのはモデル提供製品で、18,529件のOpen WebUIインスタンスが先頭に立った。Open WebUIは、ローカルでホストされた言語モデルと対話するためのブラウザベースのインターフェースを提供する。
調査期間中にHTTP認証チャレンジを返したOpen WebUIエンドポイントは、そのうち1件だけだった。これは、残りのアプリケーションが無制限のアカウントアクセスを許可していたことを示すものではない。しかし、アプリケーションの前段に検出可能なHTTPゲートを配置していたものが、ほぼ存在しなかったことは示している。
ローカルハードウェアでモデルをダウンロード・実行するためのサービスであるOllamaも、確認済みエンドポイント6,935件を占めた。Mysteriumによると、各エンドポイントは匿名のまま製品のルートレスポンスを返した。このうち、認証チャレンジを返したのは729件だった。
研究者はさらに4,880件のvLLMエンドポイントを特定し、チャレンジを返したのは3件だった。vLLMは推論サーバーであり、リクエストを受け付け、言語モデルで処理して応答を生成する。
より小規模なグループには、150件のLocalAIエンドポイント、69台のllama.cppサーバー、63件のXinference導入環境が含まれていた。これらの製品は対象ユーザーこそ異なるが、運用上の目的は共通している。すなわち、アプリケーションやユーザーがモデルを利用できるようにすることだ。
データセットは推論の範囲を超えていた。Mysteriumは、Flowise、RAGFlow、Dify、ComfyUI、n8n、Langflow、Open WebUI Pipelinesを含む、エージェントビルダーおよびワークフローツールに関連する5,223件のエンドポイントを数えた。
このカテゴリーには異なるリスクプロファイルがある。推論サーバーはプロンプトを処理するが、エージェントビルダーは多くの場合、モデルをデータベース、メッセージングシステム、クラウドサービス、社内アプリケーションへ接続する。トークンを保存したり、実際の権限を伴うツールを呼び出したりする場合もある。
Flowiseは到達可能なエンドポイント1,341件を占めたが、認証チャレンジを返したものはなかった。調査では、891件のRAGFlow導入環境、792件のDifyエンドポイント、788件のComfyUIエンドポイント、675件のn8nインスタンスも確認された。
ベクトルストアの可視性はかなり低かった。研究者が見つけたのは914件のMilvus Attuコンソールと6件のWeaviateエンドポイントだった。ベクトルストアはコンテンツの数値表現を保持し、AIアプリケーションが会話中に関連文書を取得できるようにする。
これらの数値を、ベクトルデータベースが公開されることはまれだという証拠と読むべきではない。Mysteriumによると、同社の情報源は主要2製品のネイティブポートをスキャンしていなかった。この調査は主に可視化されたWebコンソールを捉えており、最もデータセンシティブなカテゴリーは十分に測定されていない。
レポートでは、Ollamaのデフォルトポートで22,024件の追加レスポンスも確認された。研究者は、ポートレスポンスだけでは認識可能な製品バナーよりも証拠として弱いため、これらを確認済み合計から除外した。
この保守的な除外は、主な結論を強める。36,769という数字は、1つのスキャンインデックス内で確認された下限であり、公開AIインフラの完全な棚卸しではない。
セルフホスト型AIのセキュリティが境界で破綻する理由
セルフホスティングがデータを保護するのは、組織がホストへ到達できる主体も管理している場合に限られる。
ローカルモデルを導入する根拠は通常、データ保管の管理から始まる。プロンプト、アップロードされた文書、取得された文章、生成された回答は、組織が管理する機器内に留められる。この構成により、外部モデルプロバイダーへの依存を減らせる可能性がある。
しかし、配置場所だけで機密性が生まれるわけではない。企業のハードウェア上で動作するモデルであっても、そのサービスがインターネットに面したアドレスで待ち受けていれば公開状態になり得る。内部導入環境が、ファイアウォールルール、クラウドセキュリティグループ、コンテナ設定、急ごしらえのトンネルを通じて外部化されることもある。
多くのローカルAI製品は、デフォルトではループバックアドレスだけで待ち受ける。ループバックは、同じマシン上で動作するソフトウェアからの接続に限定する。運用担当者は、別のデバイスからアクセスするために、このアドレスを0.0.0.0へ変更することがある。これにより、サービスは利用可能なすべてのネットワークインターフェースを通じた接続を受け付けられるようになる。
この変更は、開発者が別のデバイスからアクセスする必要がある場合には有用だ。しかし、周辺ネットワークがインターネットからの受信トラフィックも許可している場合、危険になり得る。
リバースプロキシは、リクエストがAIアプリケーションに到達する前に認証レイヤーを提供できる。仮想プライベートネットワークは、サービスをパブリックアドレス空間の外に置ける。IP許可リストは、承認済みネットワークへアクセスを限定できる。
Mysteriumは、こうしたHTTPレベルの保護がほとんど見られなかったとしている。調査全体で、認証チャレンジを返したエンドポイントはわずか2.02%だった。情報源のレート制限により5つの製品クエリが不完全だったため、研究者はそれらのグループにチャレンジ件数を割り当てなかった。
限定的な解釈が重要である。HTTPチャレンジだけが可能なセキュリティ管理ではない。アプリケーションは公開状態で読み込まれても、独自のログイン、セッション、認可ルールを適用できる。
それでも、アプリケーション認証への依存は脅威モデルを変える。アプリケーションはスキャナーや攻撃者から継続的に到達可能になる。見落とされたパッチ、認可エラー、露出した管理ルート、デフォルト認証情報のすべてが、より重大な意味を持つ。
最近の脆弱性記録は、この懸念が具体的である理由を示している。Tenableの2026年のセキュリティアドバイザリには、Open WebUIおよび複数のFlowiseコンポーネントに影響する高深刻度の問題が記載されている。
Flowiseに関するアドバイザリには、パストラバーサル、グラフクエリインジェクション、NVIDIA NIMエンドポイントにおける認証欠如、個人情報の漏えいが含まれていた。別のアドバイザリでは、他のAIツールにまたがる認証情報の露出、認可失敗、任意ファイル書き込みが扱われている。
これらの記録は、インターネットから可視化されたすべての導入環境が脆弱であることを意味しない。バージョン、設定、補完的な管理策はそれぞれ異なる。ただし、ネットワーク分離に代わる恒久的な手段として、アプリケーション層を使うことはできないという点を示している。
パッチ適用のタイミングも別の問題を生む。開発者は数分で有用な概念実証を立ち上げ、その後数か月にわたり動作させたままにすることがある。そのサービスは、セキュリティチームやインフラチームが利用する資産台帳に登録されない可能性がある。
このライフサイクルは、通常の組織的監督なしに導入または構築されるシステム、すなわちシャドーAIを生み出す。プロジェクトは作成者には見えていても、アクセスレビュー、更新、ログ、インシデント対応を担うチームには見えないままとなる。
結果として、仮定の上に築かれたセキュリティ境界が生まれる。データサイエンティストはクラウドファイアウォールがトラフィックを遮断すると考える。インフラチームはアプリケーションが認証を要求すると考える。アプリケーションの所有者は導入環境が一時的なものだと考える。
インターネットスキャナーは、組織的な文脈を必要とせずにこうした仮定を検証する。製品が応答し、自らを識別し、アプリケーションの攻撃面を提示しているなら、それはセルフホスティングが維持するはずだった境界をすでに1つ越えている。
エージェントビルダーは露出をサプライチェーンリスクへ変える
最も深刻な露出AIエンドポイントは、単に質問へ回答するだけではない。認証情報と接続済みシステムを通じて行動できるからだ。
AIサプライチェーンには、結果を生み出すために使われるモデル、ソフトウェアパッケージ、提供インフラ、検索データベース、プラグイン、ツール、外部サービスが含まれる。接続されたコンポーネントのどこかに弱点があれば、システムに影響を与えたり、攻撃者のアクセスを拡大したりする可能性がある。
従来のソフトウェアサプライチェーンにも、すでに継承リスクがある。アプリケーションは外部開発者が保守するパッケージ、別の場所で構築されたコンテナイメージ、デプロイ認証情報を保持する自動化ワークフローに依存している。
AIアプリケーションでは、プロンプト、モデルファイル、検索コンテンツ、エージェント指示、ツール定義がこの連鎖に加わる。これらのアーティファクトの一部はデータのように見えるが、エージェントの行動を変え得る。
Fortinetは、コーディング支援ツールにおけるエージェントスキルを新たな依存関係レイヤーとして説明した。同社のスキル分析では、スキルが自然言語による指示を用い、エージェントにファイルへのアクセス、シェルコマンドの実行、情報送信を指示できると指摘している。
この挙動に、従来型のソフトウェア脆弱性が常に必要とは限らない。悪意ある指示は、エージェントがそれを信頼し、要求されたツールを使う権限を持っている場合、実際の動作につながり得る。
インターネットに露出したワークフロービルダーは、これらのリスクを組み合わせる。組織が利用する統合先を明らかにし、信頼できない入力を受け付け、保存済み認証情報とやり取りするルートを露出させる可能性がある。ワークフローが侵害されれば、元のAIサーバーをはるかに超えたシステムへ到達するおそれがある。
たとえば、エンジニアリングチームが利用する検索支援アシスタントを考えてみよう。このアプリケーションは、ソースコードリポジトリ、ドキュメントストア、課題追跡ツール、モデルエンドポイントへ接続している可能性がある。ベクトルデータベースには、社内文書の断片が含まれているかもしれない。
公開インターフェースに認可上の欠陥があれば、攻撃者が得るものは無料のモデル推論にとどまらない。製品と設定に応じて、攻撃者は取得済みコンテンツ、ワークフロー定義、接続メタデータ、トークンにアクセスできる可能性がある。
カスタマーサポート用エージェントにも同様の経路がある。メール、注文記録、メッセージングツール、顧客データベースへ接続している可能性がある。ワークフローが複数サービスにまたがる情報を組み合わせられる場合、限定的な権限の認証情報でさえ価値を持つ。
これが、5,223件のエージェントビルダーエンドポイントをモデルサーバーとは分けて注視すべき理由だ。数はより少なくても、運用上の影響範囲はより大きくなり得る。
Tenableの2月のクラウドリスクレポートは、企業環境の文脈を示している。同社のテレメトリーによると、分析対象となった組織の70%が、少なくとも1つのサードパーティ製AIパッケージまたはModel Context Protocolパッケージを統合していた。
Model Context Protocol（MCP）は、AIアプリケーションをツールやデータソースに接続するための標準だ。その有用性は、モデルに外部機能への構造化されたアクセスを与えられる点にある。
Tenableはまた、組織の18%が、監査されることの少ない管理者権限をAIサービスに付与していたと報告した。同社は、エージェントやサービスアカウントを含む人間以外のアイデンティティが、人間のユーザーよりも高い測定リスクを示していたことを確認した。
これらの調査結果は、Mysteriumのインターネット調査ではなく、Tenableの顧客およびクラウドのテレメトリーに基づくものだ。両データセットを単一の普及率推計に統合すべきではない。ただし、両者は同じ運用上の問題の異なる側面を示している。
Mysteriumが測定したのは到達可能なサービスであり、Tenableが測定したのは企業環境内の権限、サードパーティ製パッケージ、アイデンティティの状態だ。到達可能なサービスが特権を持つ人間以外のアイデンティティも制御している場合、公開状態の影響はより重大になる。
負担は開発者とセキュリティチームの双方にかかる。開発者にはモデルと統合機能へ迅速にアクセスする必要がある。一方、セキュリティチームには、インベントリー、明確な責任者、最小限の権限、そして公開サービスがそれぞれ意図的に存在することを示す証拠が必要だ。
どちらの目標も、モデルポリシーだけでは達成できない。有害なプロンプトを拒否するモデルでも、公開された管理コンソールは修復できない。プロバイダーのガードレールは、漏えいしたトークンをローテーションしたり、放置されたコンテナを削除したりはしない。
社内ナレッジを扱うためにAIを利用する組織は、検索・取得システムに入る情報も分類する必要がある。検索可能なナレッジベースは技術資料へのアクセスを改善できるが、そのストレージとコネクターは、対象資料の機密性を引き継ぐ。
したがって、セキュリティの問いはより上流へ移る。エージェントがプロンプトを受け取る前に、誰かが取得可能なデータ、呼び出せるツール、到達可能なネットワークを決めなければならない。
36,769という数字が証明していないこと
この調査は公開到達可能性を示しているが、36,769件の侵害成功やデータ漏えいを裏付けるものではない。
インターネット測定では、すべてのセキュリティ上の疑問に答えることなく、目を引く数字が生じることがある。製品フィンガープリントはサービスを特定し、HTTPレスポンスはその外周について何らかの情報を明らかにする。しかし、どちらもアプリケーション内部の認可状態を自動的に示すものではない。
データセット内の一部のエンドポイントは、ログイン画面を表示していた可能性がある。他のエンドポイントでは、インターフェースの読み込み後に重要な機能を制限していたかもしれない。研究システム、ハニーポット、意図的に公開されたデモ、あるいは空のテスト環境だった可能性もある。
Mysteriumはこの境界を認めている。同レポートは、可視化されたすべてのアプリケーションが匿名ユーザーによる非公開機能へのアクセスを許していたとは主張していない。ネットワークまたはHTTPのゲートがないことを、共通する露出状態として説明した。
この制約があるため、侵害されたレコード、脆弱な組織、影響を受けたユーザーを直接算出することはできない。研究者らは対象所有者のリストを公表しておらず、そのような公開は追加のリスクを生み得る。
認証の測定も製品ごとに異なる。17の製品カテゴリのうち、課題数が確定したのは12カテゴリのみだった。データセット中のダッシュは、認証が存在しないことの確認ではなく、クエリが未完了であることを示していた。
地理的分析も限定的だった。Mysteriumは、デフォルトポートで応答したOllamaの一部についてのみ国別の帰属を報告した。どの国や業界が最も露出しているかについて広範な主張を行うことは、証拠の範囲を超える。
エンドポイント数には、1つの組織が運用する複数のサービスが含まれる場合もある。逆に、1つのエンドポイントがより大きな共有環境の前段に置かれている場合もある。到達可能なアドレスの数は、影響を受けた企業の数ではない。
スキャナーのカバレッジも不確実性を伴う。別のインデックス、クエリのスケジュール、またはフィンガープリントでは、異なる母集団が返される可能性がある。サービスはオンラインとオフラインを繰り返し、バナーを変更し、プロキシの背後へ移動し、パッチを適用する。
こうした制約が調査結果を無効にするわけではない。結論を「36,769件の侵害済みシステム」から、より正確な表現へ変えるものだ。つまり、識別可能な数千のAIサービスが、1つの公開スキャンインデックスを通じて到達可能だったということである。
この状態は、悪用が始まる前から攻撃者にとって価値がある。製品の特定は脆弱性照合の自動化に役立つ。スキャナーは既知のインターフェースを検索し、バージョンを推定し、適用可能なルートを大規模にテストできる。
露出と侵害の違いは、通りに面した施錠されていないドアに似ている。ドアが見えることは、誰かが侵入した証拠ではない。しかし、残されたすべての内部統制への依存度が高いことは示している。
レポートの2.02%という数字にも注意が必要だ。Basic HTTP認証が、あらゆるアーキテクチャにおいて最新のアプリケーション認証より本質的に優れているわけではない。管理不十分なプロキシは、それ自体が脆弱性を持ち込む可能性がある。
より重要な原則は多層防御だ。機密性の高いAIサービスは、プライベートネットワーク、認証済みゲートウェイ、アイデンティティ認識プロキシ、制限された受信ルールが利用可能であるにもかかわらず、単一のアプリケーションログインに依存すべきではない。
AIの露出に関する広範な論評の一部には、商業的な動機もある。組織が検出、スキャン、アイデンティティ、監視製品を購入すれば、セキュリティベンダーは利益を得る。その推奨は技術的証拠に照らして評価すべきだ。
Mysterium自体はVPN企業であり、ネットワークプライバシーは同社の事業に関連する。このことは同社のデータセットを無効にしないが、透明性の高い手法、再現可能なフィンガープリント、独立した確認をより重要にする。
この調査はフィンガープリントを公開し、除外結果、レート制限による欠落、過少計上されたカテゴリを説明している。こうした選択により、非公開テレメトリーだけに基づく主張よりも、中核的な測定結果を検証しやすくなっている。
次に有用な研究段階は、統制された検証だ。独立チームはクエリを再現し、機密コンテンツにアクセスすることなくエンドポイントの挙動をサンプリングし、公開後に母集団がどう変化するかを追跡すべきである。
件数が減少すれば、運用者またはソフトウェア保守者が対応したことを示唆する。件数が安定していれば、安全でないデプロイが一時的ではなく構造的な問題であることを示すだろう。
真のトレードオフはデプロイ速度と検証可能な統制の間にある
Mysteriumによる露出したAIエンドポイントの調査は、セルフホスティングが自動的にプライバシーをもたらすという考えに疑問を投げかける。
ホスト型AIでは、信頼がプロバイダーに集中する。顧客は契約、サービス分離、保持管理、アクセスポリシー、そしてプロバイダーのセキュリティプログラムに依存する。
セルフホスティングでは、その信頼が再配分される。組織はハードウェアとデプロイを制御する一方で、パッチ適用、アイデンティティ管理、ネットワーク設計、ログ、バックアップ、インシデント対応も引き継ぐ。
これは規制対象情報や特殊なワークロードにとって適切な選択となり得る。ただし、初期設定でより容易な選択肢ではない。ローカルサーバーは、たまたま共有されるようになったデスクトップ実験ではなく、機密性の高いインフラとして運用しなければならない。
スピードが中核的な緊張関係を生む。AIフレームワークは、アイデアと動作するアプリケーションの距離を縮めるよう設計されている。研究者はインターフェースを立ち上げ、モデルを接続し、文書をつなぎ、その結果をすばやく共有できる。
あらゆる利便性の裏には、運用上の判断が隠れている可能性がある。ポートを公開すれば共同作業は容易になる。ワークフローにトークンを保存すれば統合は速くなる。広範な権限を付与すれば、繰り返される認可エラーを避けられる。
こうした判断は、誰もセキュリティ境界を定義しないまま動作する環境へと積み重なる。アプリケーションは有用になり、ユーザーを集め、実験用の統制を保ったまま本番環境に近づいていく。
従来のセキュリティプロセスも、この隔たりに寄与し得る。承認済み環境の取得に数週間かかるなら、従業員はそのプロセスを回避して構築する。利用可能な経路を提供せずにすべてのAIサービスをブロックすれば、管理されない代替手段を促すことになる。
組織には、シャドーインフラと競争できるほど迅速なデプロイルートが必要だ。そのルートは、プライベートネットワーク、管理されたアイデンティティ、シークレットストレージ、ログ、パッチの責任者、期限日をデフォルトで提供すべきである。
短命な実験には期限日を設定すべきだ。なぜなら、一時的なシステムが自らを削除することはほとんどないからだ。デモ用に作成されたクラウドインスタンスは、所有者が役割を変えたりプロジェクトを忘れたりした後も、オンラインのまま残る可能性がある。
インベントリーには運用チェーン全体を含める必要がある。モデルサーバーだけを見つけても、そのベクトルストア、ワークフローエンジン、コンテナホスト、サービスアカウントを把握できなければ、防御側の状況認識は断片的なままだ。
アイデンティティも同等の注意を払うべきだ。エージェントには、そのタスクに必要な最小限の権限を与えるべきである。統合に失敗したとき、管理者認証情報が標準的な答えになってはならない。
公開済みまたは過去に露出したワークフローに保存された認証情報はローテーションすべきだ。インターネットからのアクセスを取り除けば一つの経路は閉じられるが、攻撃者がすでに保有している可能性のあるトークンが無効になるわけではない。
ログは会話だけでなく、アクションも対象にしなければならない。チームは、エージェントがどのツールを呼び出し、どのアイデンティティを使用し、どのリソースに到達し、そのアクションが承認済みワークフローと一致していたかを把握する必要がある。
これは、エージェントへの指示が第三者から提供される場合に特に重要だ。インポートされたテンプレート、プラグイン、またはスキルは、実行可能コードのように見えなくても動作を変え得る。レビューでは、従来型のパッケージと自然言語の制御ファイルの両方を検査しなければならない。
ソフトウェア保守者にも対応の圧力がかかる。安全なデフォルト設定は、意図しない露出を起こしにくくするべきだ。製品は、サービスが公開インターフェースにバインドされる際に警告を出し、初回起動時の認証情報を必須とし、管理ルートをユーザー向けエンドポイントから分離できる。
ドキュメントも重要である。なぜなら、チュートリアルはしばしば本番アーキテクチャになるからだ。ネットワーク上の影響を説明せずにサービスを公開するクイックスタートガイドは、同じ誤りを数千のインストール環境へ広げかねない。
クラウドプロバイダーとモデルプロバイダーも比較の一部であり続ける。マネージドプラットフォームは設定作業を減らせるが、プロバイダー集中とアカウント権限のリスクをもたらす。どちらか一方のホスティングモデルが常に勝るという話ではない。
防御可能な選択とは、統制を検証できる選択だ。組織は、モデルがどこで実行され、誰が到達でき、どのデータを処理し、どのアイデンティティを使用し、アクセスをどれだけ迅速に取り消せるかを把握すべきである。
露出が縮小するかを示す3つのシグナル
次の検証点は、保守者と運用者が広く報じられた調査結果を測定可能な是正へ変えるかどうかだ。
最初のシグナルは、同じフィンガープリントを用いたインターネットの再スキャンである。最も示唆的な指標は、確認済みエンドポイントの総数と、ネットワークレベルの認証で保護された割合だ。
エンドポイント数の減少は、運用者が不要な公開アクセスを削除したことを示唆する。認証率の上昇は、サービスが有用性を維持しながら外周防御を得たことを示すだろう。
ただし、どちらか一方の変化だけでは十分ではない。エンドポイントは、バナーが変わったためにフィンガープリントから消える一方で、到達可能なままであることがある。したがって研究者は、クエリの変更を文書化し、比較可能な測定を維持すべきだ。
2つ目のシグナルは、主要な保守者による対応である。Open WebUIは特に注目に値する。Mysteriumが確認した母集団の約半分に当たる18,529のエンドポイントを占めていたからだ。
公開バインディングへの警告、必須の初期認証情報、より安全なデプロイテンプレート、そしてより明確なリバースプロキシの指針があれば、本レポートの主張はさらに強まるだろう。沈黙や表面的なバナー変更では、運用上の問題はほとんど解決しない。
エージェント構築ツールは、さらに厳しい精査を受けるべきだ。Flowise、RAGFlow、Dify、n8n、Langflow、および類似ツールには、シークレットや外部システムへのアクセスを踏まえたセキュアなデフォルト設定が必要である。
3つ目のシグナルは、脆弱性とインシデントの証拠だ。認可、認証情報の漏えい、リモート実行、またはエージェントによるツールアクセスに関する新たなアドバイザリは、公開状態が攻撃経路になり得ることを示すだろう。
悪用が確認されれば緊急性は増すが、防御側はその確認を待つべきではない。資産所有者にログや可視性が欠けている可能性がある以上、公開されたインシデントが存在しないことは安全性の証明にならない。
組織は、こうしたシグナルが現れる前に行動できる。AIサービスを棚卸しし、どのインターフェースが公開到達可能かを検証し、各デプロイメントの責任者を特定すべきだ。
公開アクセスを必要としないものは、プライベートなインターフェースにバインドすべきである。到達可能な状態を維持する必要があるサービスは、限定されたIDと最新パッチを備えた認証済みゲートウェイの背後に配置すべきだ。
エージェント構築ツールは、シークレット基盤として追加の対策を要する。チームは保存済みの連携設定を見直し、露出した認証情報をローテーションし、インポートされたワークフローを検査し、接続先システムに対するエージェントの操作を記録すべきである。
Mysteriumによる露出したAIエンドポイント数は、いずれ古くなる。それは想定内だ。重要なのは、次回の集計が管理の改善を反映するのか、それとも見過ごされたサービスの集合が拡大しただけなのかという点である。
開発者、エンタープライズの購入者、そしてAIユーザーにとって、実務上の検証はシンプルだ。組織は、各システムに誰が到達でき、そのシステムが何を実行できるかを示せるだろうか。答えが前提条件に依存するなら、そのデプロイメントはセルフホスティングが約束した統制を提供していない。
