“無料LLMエンドポイント”がエージェントの制御平面になる — SANSがハニーポットで観測したコーディングエージェントのセッション漏えい

SANS Internet Storm Center（ISC）は2026年8月31日、インターネットに公開した推論用ハニーポットが第三者に発見され、別のモデル名で再ラベルされた上で“無料LLMバックエンド”として流通し、実在のコーディングエージェントのセッションが同ハニーポットへ送られてきた事例を報告した。報告を執筆したのは同センターのハンドラーであるRenato Marinho氏で、ハニーポットが受信した会話履歴とツール実行の痕跡から、エージェントの制御平面としての危険性を詳述した。SANS ISCは、この観測が特定の攻撃の実証ではなく、悪意あるエンドポイント運営者が同じ位置に立てば何が可能かを示す一例だと説明している。

何が観測されたか — ハニーポットに届いた88メッセージのエージェント履歴

SANS ISCのハニーポットは、/v1/modelsや/v1/chat/completions、Ollama互換の/api/tags、MCPサーバなど複数の推論インタフェースを認証なしで公開し、4つの小規模なローカルモデルを広告する構成で2026年7月18日に稼働を開始した。同センターによると、ハニーポットは稼働直後からスキャンを受け、7月22日には115件の要求で/v1/modelsの応答に含まれるモデル名がそのまま要求へ貼り付けられる自動的な棚卸しが観測された。

転機は2026年8月26日から30日にかけて訪れた。opencode/0.2.0を名乗るクライアントが、同ハニーポットが広告していないauto/best-codingやauto/claude-opusといった別名を順に試し、SANS ISCのハニーポットが全てにHTTP 200で応答した。続いてNodeHealthCheck/1.0 (+local-lab)がfofa-opus-NNNNNを要求し、エンドポイントが監視対象のバックエンドプールに登録された可能性を示した。8月30日早朝には同じopencode/0.2.0がfofa-sol-NNNNNやfofa-ds-NNNNNなど3つの別名を3秒以内に試す“バックエンド検証”とみられる挙動を示した。

そして2026年8月30日08時07分（UTC）、中国Unicom（河北）のアドレスからGo-http-client/2.0が、91秒間に210回、同一の224KBの要求本文を送信した。本文はオープンソースのターミナル型コーディングエージェントopencodeの88メッセージに及ぶ会話履歴で、Windows環境で動作するエージェントがユーザのDownloadsフォルダにある2つの小説の文体を分析するよう依頼された経緯を記録していた。履歴には、エージェントがGet-ChildItemでフォルダ一覧を取得し、ファイルを%TEMP%へコピーして展開し、Pythonスクリプトでテキストを抽出して章を読み進める過程で実行された複数のPowerShell呼び出しと、その出力が含まれていた。ユーザが最後に「继续（続けて）」と入力したところで、履歴全体とエージェントのローカルツールマニフェストが添えられてハニーポットへ送られた。

SANS ISCによると、要求はmodel: fofa-ds-NNNNNとラベルされ、FOFA（中国のインターネット全体検索エンジン）で発見されたことを示すfofa、DeepSeekを示すds、そしてエンドポイント自身の公開IPアドレスのオクテットを組み合わせた命名規則で管理されていた。同じ3つの別名がVultrホスト、Cloudflareの出口、中国Unicomのリレー、別のヘルスチェッカーという4つの観測点から同じエンドポイントへ向けられ、248件中247件でAuthorization: Bearer ***のトークンが同一だった。SANS ISCは、トークンの実体が「無料（free）」という言葉そのものだったと説明している。

エンドポイント運営者が受け取る情報と、悪用された場合のリスク

SANS ISCは、ハニーポットが受信した要求の構造を公開し、運営者が何を平文で受け取るかを明確にした。要求にはsystemプロンプト（「あなたはopencodeという対話型CLIツールである」）、ユーザの依頼文、過去のassistantのtool_calls（例: bashツールのGet-ChildItem -LiteralPath "C:\Users\<redacted>\Downloads"）、そしてtoolロールの実行結果（フォルダ一覧やファイル内容の一部）がそのまま含まれていた。Windowsのユーザ名、ディレクトリ構成、ツール出力、読み込まれたファイルの断片が、認証の検証なしにハニーポットのデータベースへ記録された。

SANS ISCは、このハニーポット自体がツール実行を要求したり誘発したりしたわけではないと強調している。問題は、ツール実行機能を持つエージェントにとって、モデルエンドポイントが単なるテキストの供給元ではなく、**制御平面（control plane）**として機能する点にある。エージェントは推論結果を次のツール呼び出しに変換するため、エンドポイントが返す指示次第で、エージェントが動作するマシン上でファイルの読み書きやシェル実行が実行され得る。攻撃者がこの位置を占めれば、正規のユーザのセッションを横取りして機微な情報を収集するだけでなく、意図的にツール呼び出しを指示して端末を操作する経路になり得る。

今回の観測でクライアントとなったのは攻撃者ではなく、セッションが意図せず外部へルーティングされた一般のユーザだった。SANS ISCは、これを「古典的な水飲み場型攻撃ではない」と整理し、不正なモデルエンドポイント（rogue model endpoint）、さらに実在プロバイダの双子として人気モデル名を掲げて待つ**邪悪な双子（evil twin）**という概念で説明した。無料のAPIキーを追い求める行為自体は以前からあるが、現在のエージェントは自らファイル操作やシェル実行の道具を携えてエンドポイントへ接続するため、宛先の取り違えが従来以上に重大な結果を招くと同センターは指摘している。

日本の組織が取るべき対策 — エンドポイントの検証を前提にする

SANS ISCは今回の事例を踏まえ、エージェントの運用でモデルエンドポイントの身元検証を必須とするよう呼びかけている。推奨は、信頼できるプロバイダの正規エンドポイントのみを許可リストで指定し、未知の“無料モデル”や検証されていないリレー経由のエンドポイントへエージェントを接続しないことである。エージェント側では、ツール実行の権限を最小化し、ファイルアクセスやシェル実行の範囲を制限する、実行前にユーザの明示的な承認を求める設定を徹底することが有効だ。

SANS ISCが示すように、エンドポイント側での認証検証の欠如（今回のハニーポットはBearer ***を検証しなかった）が、セッション漏えいの温床になった。組織は、エージェントが送信する会話履歴に機微なファイルパスや内容が含まれることを前提に、ログの取り扱いやネットワークの egress 制御を見直す必要がある。同センターは、モデルエンドポイントを「テキストの供給元」ではなく「エージェントの制御を担う基盤」と捉え直すことが、エージェント導入時のリスク評価の出発点になると結論づけている。

出典

• SANS Internet Storm Center, Renato Marinho氏「The Coding-Agent Trap: When a “Free” LLM Endpoint Is the Adversary」（2026年8月31日公開） — https://isc.sans.edu/diary/rss/33298