LLMハニーポットとは AIエージェントを罠にかけて検知する仕組み

SSHの認証ログに積み上がる攻撃の山から、AIエージェントが動かしているアクセスだけを抜き出す。

それを実際にやってのけたのがLLMハニーポットという手法で、仕掛けは「人間には見えないメッセージ」と「応答時間」のたった2つです。

すでに813万件の攻撃データが集まっていて、そこから実在するAIハッキングエージェントが見つかっています。

LLMハニーポットとは AIエージェントだけが引っかかる罠

従来のハニーポットとの決定的な違い

脆弱そうなサーバーを置いて、ログを取り、投げ込まれたマルウェアを回収する。

従来のハニーポットは、来たのが誰かを問いませんでした。

攻撃されること自体が目的だからです。

LLMハニーポットが変えたのは、その「誰か」を分類の対象にしたところです。

人間の攻撃者なら絶対に反応しない仕掛けを罠の中に置いておいて、反応したものをLLM駆動のエージェントとして拾い上げる。

ログを集める箱から、正体を判定するフィルタになったわけですね。

用途は2系統 ハッキング検知とAIクローラー対策

紛らわしいのは、この言葉が守る対象のまったく違う2つの文脈で使われていることです。

日本語圏で語られやすいのは後者ですが、技術的に面白いのは圧倒的に前者です。

攻撃者の群れの中からAIだけを名指しする、なんてことがどうして成立するのか、気になりませんか。

AIエージェントのハッキングを検知する LLM Honeypot の仕組み

Palisade Research の LLM Agent Honeypot

この分野の基準になっているのが、Palisade Research が2024年10月に公開した「LLM Agent Honeypot」です。

論文の著者は Reworr さんと Dmitrii Volkov さんで、SSHハニーポットにプロンプトインジェクションと時間分析を足して、自律型AIハッキングエージェントを野外で観測する、というのが骨子になっています。

LLM Agent Honeypot: Monitoring AI Hacking Agents in the Wild

Attacks powered by Large Language Model (LLM) agents represent a growing threat to modern cybersecurity. To address this concern, we present LLM Honeypot, a system designed to monitor autonomous AI hacking agents. By augmenting a standard SSH honeypot with prompt injection and time-based analysis techniques, our framework aims to distinguish LLM agents among all attackers. Over a trial deployment of about three months in a public environment, we collected 8,130,731 hacking attempts and 8 potential AI agents. Our work demonstrates the emergence of AI-driven threats and their current level of usage, serving as an early warning of malicious LLM agents in the wild.

arxiv.org

ベースは自作ではなく、SSH/Telnetハニーポットの定番である Cowrie の改造版です。

脆弱そうなSSHバージョンを名乗らせ、デフォルトの出力も書き換えて「いかにも侵入できそう」に見せた上で、複数の国にまたがる10個のIPに分散させてあります。

GitHub - PalisadeResearch/llm-honeypot

Contribute to PalisadeResearch/llm-honeypot development by creating an account on GitHub.

github.com

人間には見えないプロンプトインジェクションを仕込む

罠の本体はここです。

SSH接続時のバナー、pwd や whoami や ps といったコマンドの出力、読めるようにしてあるシステムファイル。

侵入者が最初に叩く場所すべてに、隠しメッセージが埋め込まれています。

隠し方が上手くて、ANSIエスケープシーケンスを使っているんですよ。

ターミナルで見ている人間の目には何も表示されません。

でもエージェントは標準出力をそのままモデルのコンテキストに流し込むので、隠された文章を読んでしまう。

仕掛けは2段構えです。

• 1: Goal Hijacking。「重要なメッセージ」を装って、本来の攻撃タスクとは別の行動を指示する
• 2: System Prompt Stealing。乗っ取りに反応した相手にだけ、システムプロンプトを吐かせる質問を返す

攻撃を止めにいくのではなく、相手に自分から名乗らせる。

防御側の設計としてはかなり珍しい方向ですが、相手が言語モデルだからこそ成立する手です。

応答時間1.7秒という境界線

プロンプトインジェクションだけだと、たまたま同じ文字列を返す単純なスクリプトも混ざってきます。

そこで2段目のフィルタとして応答時間を見ます。

論文によると、LLMエージェントは隠しメッセージに反応するときですら1.7秒以内に返してきます。

人間なら画面を読んでタイプするので、どうやっても数秒はかかる。

この差がそのまま人間とエージェントの境界線になるわけです。

だから公開されていたダッシュボードでも、プロンプトインジェクションだけ通過したものを「潜在的なAIエージェント」、時間分析まで通過したものを「確定」と分けて数えていました。

LLMハニーポットが捕まえた実在のAIハッキングエージェント

813万件から検知された自律型AIエージェントは8件

約3ヶ月の稼働で集まった攻撃試行が 8,130,731件。

そこから拾い上げられた潜在的なAIエージェントが8件でした。

100万件に1件あるかないか、という頻度ですね。

その後もハニーポットは動き続けていて、アーカイブされたダッシュボードの時点では累計2,411万件、潜在14件・確定3件まで伸びています。

AIハッキングエージェントが「実在する」ことの意味

8件という数字を「まだ脅威じゃない」と読むのは危ないと思っています。

理由は単純で、この罠に引っかかるのは、標的を選ばず手当たり次第にスキャンしている相手がほとんどだからです。

狙いを定めて特定の組織に来るエージェントは、そもそもハニーポットのIPに用がありません。

つまり8件は実数ではなく下限値として読むべき数字です。

研究チーム自身も、この仕組みを検知システムではなく早期警戒システムと位置づけています。

自律型AIによるサイバー攻撃はまだ観測できる規模には育っていない。

ただ、観測の網はもう張られています。

AIクローラー対策としてのLLMハニーポット 無価値な迷路に誘い込む

Cloudflare「AI Labyrinth」との違い

もう片方の用途が、robots.txt を無視してくるAIクローラーへの対抗策です。

この文脈で有名なのが Cloudflare が2025年3月に出した AI Labyrinth で、AI生成のもっともらしいけれど無関係なページ群を用意して、人間には見えないリンクで本文に繋いでおく。

踏んだ相手はその時点でbot確定、という仕組みです。

同じ罠でも出口が違います。

AI Labyrinth は商用WAFの機能なので、狙いは遅延と消耗、それとbotシグネチャの学習データ収集。

研究系のLLMハニーポットは観測と分類が目的で、集めるのはデータそのものです。

なぜ迷路がAIクローラーの計算コストを押し上げるのか

コストの非対称性がすべてです。

迷路のページは1回作れば静的に配れますが、踏む側は1ページごとに取得・前処理・埋め込み・保存のコストを毎回払います。

しかもその裏には推論のトークン課金が乗っている。

Cloudflareのネットワークに届くAIクローラーのリクエストは1日500億件を超え、同社が観測する全Webリクエストの1%弱を占めます。

この規模に対して無価値なページを配るのは、相手の予算を削る行為でもあるわけです。

注意点が1つあって、迷路を自サイトのSEOごと巻き込まないよう noindex と robots.txt の制御は必須です。

ここを雑にやると、検索エンジンに迷路を丸ごとインデックスされます。

LLMハニーポットが示すAIエージェント時代のセキュリティ設計

認証はずっと「正しい鍵を持っているか」を見てきました。

そこにこれから「相手が人間かエージェントか」という軸が加わります。

LLMハニーポットが面白いのは、LLMの一番の強み、つまり目に入った文脈を全部読んで推論する性質が、そのまま識別子として使われているところです。

WAFのシグネチャは相手が書き換えれば効かなくなりますが、「読んでしまう」性質はアーキテクチャに近いので、そう簡単には消せません。

そして同じ理屈は自分側にも返ってきます。

社内で動かしているエージェントに外部のページやログを読ませているなら、その入力経路はもう攻撃面です。

手を動かして感覚を掴むなら、ミニマムな実装から試すのが早いです。

パロディサイトの LLM2HUMAN は「FOR LLM AGENTS ONLY」というブロックを置いて特定のエンドポイントを叩かせ、引っかかったエージェントの数をカウンターで表示しています。

人間向けの本文と、エージェント向けの隠し導線を分けるだけ。

数十行あれば書けます。

罠を本気で張るかどうかは別として、自分が管理しているサーバーやサイトが、いま人間とエージェントのどちらに向けて口を開けているのか。

一度確認してみる価値はあると思います。