ボットはスクリプトどおりに動きます。一方、AIエージェントは目標の達成に向けて、自ら手順を選びながら行動するため、見抜くのは容易ではありません。Help Net Securityのインタビューで、Resemble AIのCEOであるZohaib Ahmed氏は、エージェントが「自己申告型」「非申告型」「偽装型」のトラフィックとして到来すると説明しました。さらに、二値的なボット検知では後者の2つを見逃してしまう理由も語っています。
Ahmed氏は、クリックのタイミングや、単一の目標を追う一連のセッションなど、エージェントの存在を示すシグナルを解説しました。従業員が独自に導入したエージェントについては、まずOAuthの同意ログと外向きのトラフィックから調べるよう勧めています。
数年前まで「ボット」といえば、ログインページに猛攻をかけるスクリプトのことでした。いま検知会議で「AIエージェント」と聞いたとき、あなたは何を思い浮かべますか。また、多くのセキュリティチームは今も何を思い浮かべているのでしょうか。
ボットはスクリプトに従って動きます。クローラーやスクレイパーのようにコンテンツを読み取る場合もあれば、フォーム入力やログインのような決まったタスクを実行する場合もありますが、いずれもスクリプトの範囲を超えることはありません。これに対してAIエージェントは、航空券の予約や購入の完了といった目標に向かって動き、どの手順を踏むかを途中で自ら判断します。ブラウザ操作（browser-use）を通じて、クリックやスクロールも行います。さらに、AIエージェントが自らをどう見せるかによって複雑さが増します。「自己申告型（Declared）」「非申告型（Undeclared）」「偽装型（Disguised）」の3種類があります。
自己申告型（Declared）：ユーザーエージェントや署名付きヘッダーで自らの身元を示すため、識別は容易です。
非申告型（Undeclared）：身元を明かしませんが、隠そうともしません。ブラウザ自動化ツール特有の痕跡を残しますが、検知するにはその痕跡を識別するための学習データが必要となるため、見つけるのはより難しくなります。
偽装型（Disguised）：身元やブラウザのフィンガープリントを書き換えて通常の訪問者になりすますため、フィンガープリントに頼る従来のツールではほぼ検知できません。
ボット検知は大半が二値的（人間かそうでないか）であるため、非申告型のエージェントはしばしば見逃され、偽装型のエージェントはほぼ確実に見逃されます。動作の仕方から、人間のように見えてしまうからです。
エージェントが少しせっかちな人間のように振る舞うなら、どのような手がかりが残りますか。ダッシュボードにはどのシグナルを載せますか。
どれも基本的にはシグナルに基づく手法です。ポインターの動き、クリックの順序と速さ、タイピングの流れ、スクロールの挙動などに加え、先ほど触れたブラウザや環境の手がかりがあります。たとえばリクエストヘッダー、自動化フラグ、そして自らを名乗るエージェントが付けるWeb Bot Authの署名です。
さらに、セッション単位の層があります。複数のユーザーが同じように振る舞っていたり、同じ目標に向かって動いていたりする場合、それはスワーム（群れ）の兆候かもしれません。セキュリティチームがいま最も懸念しているのは、まさにこの点です。すべてのシグナルを識別できたら、次はそれらを結び付けてリアルタイムで読み取り、潜在的な攻撃を見極める段階に進みます。
従業員が個人のAPIキーやOAuthの許可を使って、メールやカレンダー、SaaSツールにエージェントを接続しています。セキュリティ部門が把握していないエージェントは、どうすれば見つけられますか。最初にどのログを調べますか。
自分のエージェントについて、セキュリティ部門に伝える人はいません。とくに早期の導入者であればなおさらです。本人にとっては5分で設定できる生産性向上ツールにすぎず、正規の手続きを踏まないほうが得るものが大きいと考えています。問題は、そうしたエージェントが従業員自身の認証情報で動くことです。そのため、ほとんどのログでは、その人がとても忙しく働いているようにしか見えません。
私ならまずIDプロバイダーを確認し、OAuthの同意ログとアプリへの許可（グラント）のログを取得します。メールやカレンダーに触れるエージェントは、どこかの時点で必ずトークンを生成しているからです。そこで、メールボックス全体やドライブ全体へのアクセスといった広範なスコープを持ち、1人のユーザーだけが承認したサードパーティ製アプリを探します。
次に、主要なSaaSツールの監査ログから、個人のAPIキーやトークンが作成された記録と、その後の使われ方を確認します。続いて、業務上モデルプロバイダーのAPIやエージェントプラットフォームを呼び出す理由のない端末から、それらへ出ていくトラフィックを、エグレスログやプロキシログで調べます。許可の一覧がそろえば、あとは行動が教えてくれます。人間の従業員が、午前3時に2分間で400通のメールを読んだり、届いた1秒後にカレンダーの招待を承諾したりすることはありません。先ほど挙げた速度やタイミングのパターンを探すことになります。
現実的には、従業員にAIを活用してほしいと考える企業は、こうした利用を容認すべきです。ポリシーも、利用を探し出して禁止しようとするのではなく、安全に支える方向へ適応させる必要があります。
CISOが来四半期に、エージェント検知への投資を1つだけ選べるとしたら、どこに予算を振り向けるべきでしょうか。また、何を後回しにするよう助言しますか。
先ほど挙げた非申告型と偽装型のセッションという課題に対処できる、エージェント検知に予算を振り向けるよう勧めます。私たちはこれを3段階の課題と捉えています。第1に、自社の資産（WebやアプリのProperty）へのトラフィックのうち、どれだけがエージェントによるものかを正確に把握することです。
第2に、機密データやログインなど、リスクにさらされるあらゆる領域についてポリシーを定め、最初は広めの網をかけてアクセスを制限します。第3に、自動化されたルーティングを加えます。これは、正規のエージェントを含めてすべてのエージェントをブロックすることに伴う、セキュリティリスクと収益機会の損失の両方に対処するものです。収益を落とさずに安全性を確保し、顧客や取締役会を納得させたいのであれば、CISOは今後12か月以内にここまでの実現を目指すべきです。
18か月以内に役に立たなくなると見込んでいるシグナルのうち、現在あなたが頼りにしているものはどれですか。
あらゆる種類のメタデータです。位置情報やIPアドレスなど、人間のユーザーであることを示すとされる要素に頼るのは、すでに心もとない状況です。これらは簡単に偽装したり隠したりできます。18か月どころか、6か月以内にシグナルとして成り立たなくなるでしょう。
翻訳元: https://www.helpnetsecurity.com/2026/11/05/zohaib-ahmed-resemble-ai-detecting-ai-agent-traffic/
