AIエージェントへの攻撃を共通の規則で検知するルール集「Agent Threat Rules」とは

「AIエージェントへの攻撃を見張りたいが、何を目印に検知すればよいのか決められない」「既存の監視の仕組みに、エージェントの入出力をどう載せればよいのか分からない」——AIエージェントの社内利用が進む企業で、監視の設計を任された担当者が口にし始めた悩みです。必要なのは、強力な検知の製品を一つ買うことだと思われがちです。しかし本当に足りていないのは製品ではありません。何を攻撃の兆しとみなすかを、共通の言葉で書き表し、検証し、更新していく仕組みです。この記事では、AIエージェントを狙う攻撃を共通の書式の規則で検知しようとするルール集「Agent Threat Rules」（以下、ATR）を取り上げ、一次情報で確かめられる事実、安全性の評価、企業が導入前に決めておくべき点を整理します。導入や設定の手順、検知規則の中身は扱いません。

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

ATRは、GitHubで公開されているルール集です。READMEの冒頭では「AIエージェントのセキュリティ上の脅威を検知するための、公開された規則の書式」と説明されています。規則は版の管理された書式に沿って書かれ、決まった形の識別番号が振られ、その書式に従う検知の仕組みであれば、どれでも評価できるとされています。リポジトリには参照用の検知の仕組みと、Python向けの部品が同梱されています。つまり、検知の製品ではなく、検知の目印を書き表すための共通の約束事という位置づけです。

配布の形を確かめます。リポジトリは Agent-Threat-Rule という組織のアカウントで2026年3月9日に作られ、ライセンスはMITです。2026年10月18日時点でスターは417、派生は61、最後の更新は10月17日でした。組織のアカウントもリポジトリと同じ3月9日に作られており、公開しているリポジトリは8件、フォロワーは20人です。一日あたりのスターの伸びは約1.9件で、急な水増しの形ではありません。ただし、運営の母体がこの取り組みのために作られたばかりで、ほかの実績から信頼を測れない点は押さえておく必要があります。

READMEによると、現在の文書は版4.1.5の「作業中の草案」という扱いです。規則の書式そのものは安定しているとしつつ、管理の体制は一人の管理者が最終判断を持つ形で、技術の運営委員会へ移る途中とされています。標準化団体 OASIS への提出に向けた資料も置かれていますが、いずれも「提案」の段階で、正式に承認されたものではないとREADME自身が明記しています。

なぜ今、エージェント向けの検知規則が求められるのか

AIエージェントは、文章を返すだけでなく、外部の道具を呼び出し、ファイルを読み、他のサービスとやり取りします。MCP（AIと外部の道具をつなぐ共通の接続方式）のような仕組みが広がり、エージェントが受け取る情報と、エージェントが動かせる範囲は一気に広がりました。READMEは、エージェントの基盤そのものが攻撃の対象になっており、攻撃を見つける道具の整備が、弱点の見つかる速さに追いついていないという問題意識を書いています。

ここで難しいのは、従来の監視の道具がエージェントの入出力を前提にしていない点です。READMEは、ログの検知規則の書式やファイルの特徴を書き表す書式は、エージェントへの入力、道具を呼び出すときの引数、エージェントが参照する文脈を、そのままでは扱えないと説明しています。また、OWASPのエージェント向けの上位10項目や、MITRE ATLAS（AIへの攻撃の手口を整理した知識の体系）は危険の分類であって、そのまま動かせる検知ではない、とも述べています。

ATRが埋めようとしているのは、この「分類」と「実際に動かせる規則」の間です。危険の名前を知っていることと、その危険を記録の中から拾えることは別という指摘は、エージェントの監視を設計する立場から見てもうなずけるものです。ただし、それを一つの取り組みで埋め切れるかどうかは、後の章で見る成績の数字と運営の体制から慎重に判断する必要があります。

「エージェント版のSigma」という位置づけ

READMEは、自らの位置づけを既存の二つの書式にたとえています。一つは、ログを集めて分析する仕組み向けの検知規則を書き表す書式 Sigma、もう一つは、不正なプログラムの特徴を書き表す書式 YARA です。ATRは、特定の製品に依存せず、機械で読めて、第三者が中身を検証できる規則の書式を、エージェントの脅威について作ろうとしている、と説明されています。

この比喩が示すのは、規則を共有財として扱う考え方です。ある組織が見つけた攻撃の兆しを規則として書けば、別の組織は同じ規則を自分の監視の仕組みで使えます。検知の製品を乗り換えても、規則の資産は引き継げます。Sigma が監視の現場で受け入れられたのも、この「書き方をそろえる」効用が大きかったからです。

ただし、比喩はあくまで目標です。Sigma は長い年月をかけて多くの組織が規則を出し合い、検証を重ねてきました。ATRは公開から約7か月で、運営も一人の管理者が中心です。同じ役割を目指していることと、同じ信頼を得ていることは別と捉えておくのが妥当でしょう。なお、Sigma 側の道具の一覧にATRが関連する書式として載ったとREADMEは書いていますが、これは掲載であって、Sigma の運営が内容を保証したものではありません。

一つの規則に何が書かれているのか

READMEによると、規則は YAML（人が読み書きしやすい設定の書式）の文書として書かれます。一つの規則には、識別番号、題名、状態、成熟度、重大度、書式の版、検査の対象が記されます。そのうえで、説明文、検知の条件、関連する分類への対応づけ、そして試験用の事例が並ぶ形です。

特徴的なのは二つです。一つは、規則ごとに引っかかるべき事例と、引っかかってはいけない事例の両方を持たせる決まりがある点です。成熟した規則ほど多くの事例が求められます。もう一つは、OWASPの上位10項目、MITRE ATLAS、既知の弱点の番号（CVE）などへの対応づけを書く欄がある点です。検知した結果を、既存の分類の言葉で報告できるようにする狙いと読めます。

検査の対象も区別されます。エージェントに読み込ませるスキルの定義ファイルを調べる規則と、MCPを通じたやり取りを調べる規則は別物として扱われ、対象の違う規則を当てはめてはいけないと定められています。検知は、主に文字の並びの型を照らし合わせる方式（正規表現による照合）が中心です。READMEは、ATRは「中身を見る層」であり、鍵の受け渡しの管理、実行の場の切り離し、影響の大きい操作の人による確認と組み合わせて使うことを勧めています。

三つの「レーン」と成熟度の考え方

ATRの規則には成熟度があり、試作、試験中、安定、廃止の段階に分かれます。どの成熟度の規則まで動かすかを決めるのが「レーン」と呼ばれる区分です。READMEに書かれた内容を整理すると、次のようになります。

レーン	動かす規則	向いている使い方	READMEが示す性格
実施	安定の規則だけ	止める判断に使う	誤検知は少ないが、見逃しが多い
警告	安定と試験中の規則	分析担当者への通知や突き合わせ	実施と探索の中間
探索	廃止以外のすべて	広く兆しを拾う。既定はこれ	拾う範囲は広いが、誤検知も増える

ここで見落とせないのは、二つの既定の扱いです。READMEによると、既定のレーンは最も広い「探索」で、検知したときに処理を止める機能は既定で切られています。つまり、入れただけでは検知の記録が出るだけで、何も止まらない作りです。止めるかどうかは、使う側が明示的に選ぶ必要があります。

また、READMEは、実施のレーンでは稼働中の約823の規則のうち約103しか読み込まれず、見逃しが大きく増えると明記しています。どのレーンで動かすかは、検知の数字を大きく左右する設計上の選択です。後で触れる勧告も、どのレーンで動かしていたかによって影響の有無が変わります。

どこで使えるのか：配布の形と使う場面

READMEが示す配布の形は四つです。JavaScript向けの配布（npm）、Python向けの配布（pyatr という名前の部品）、GitHubで開発の自動検査に組み込める部品、そして Docker の形での配布です。自動検査に組み込む部品は、リポジトリの中身を規則で調べ、結果をGitHubのセキュリティの画面に出せるとされています。

使う場面は、大きく二つに分けて読めます。一つは、エージェントに読み込ませるスキルや設定のファイルを、取り込む前に調べる使い方です。もう一つは、エージェントと外部の道具のやり取りを、動いている最中に照らし合わせる使い方です。前者は社内に持ち込む部品の点検、後者は稼働中の見張りに当たります。どちらに使うかで、許される遅延や、誤検知が出たときの影響がまったく違う点に注意が要ります。

外部への送信についても確かめました。READMEは、既定では何も外部へ送らず、調べる処理は手元で完結すると書いています。検知の結果を共有の仕組みへ送る機能はありますが、明示的に有効にし、送り先も自分で指定する必要があり、組み込みの送り先はないとされています。有効にした場合も中身そのものは送らない一方、調べた中身の指紋（同じ中身なら同じ値になる短い符号）は送られるため、同じファイルを持つ第三者には、そのファイルを調べたことが分かりうると、README自身が注意書きを添えています。

「MicrosoftやCiscoに取り込まれた」は本当か。一次情報で確かめた範囲

リポジトリの説明には、Microsoft、Cisco などのOSSに取り込まれたと書かれています。READMEの採用の章には、取り込まれた先と、その根拠となる変更の申請（プルリクエスト）へのリンクが並んでいます。そのうち主なものについて、取り込み先のリポジトリで状態を確かめました。結果は次のとおりです。

取り込み先	READMEの主張	今回確かめた結果
Cisco の公開する、スキルを点検する道具	規則一式が取り込まれた	変更の申請は2026年4月22日に取り込み先の管理者が承認し、取り込まれていた
Microsoft の公開する、エージェントの統制の道具	連携の見本が取り込まれた。以前の規則一式は7月に取り除かれた	見本のコードを加える変更が6月15日に取り込まれていた。ATRの部品は必須ではなく任意の扱い
Microsoft のAIの弱点を試す道具	攻撃文の見本集を読み込む部品が取り込まれた	今回は取り込み先で確かめていない
MISP（脅威情報を共有する仕組み）ほか	分類の項目などが取り込まれた	今回は取り込み先で確かめていない
NVIDIA の安全装置の道具ほか	変更の申請が審査中	READMEでも未採用と明記されている

確かめた範囲で言えるのは、二つの大手の公開リポジトリに、ATRに関わる変更が実際に取り込まれていたということです。ただし、その中身には差があります。Cisco の例は規則一式の取り込みですが、Microsoft の例は見本のコードの追加で、ATRの部品は任意の扱いでした。README自身も、Cisco の例は公開の点検の道具への取り込みであって、同社の製品についての表明ではないと注記しています。

さらにREADMEは、以前 Microsoft の道具に取り込まれていた規則一式が2026年7月30日に取り除かれたとも書いています。今回確かめた範囲では、その経緯を取り込み先の記録から読み取ることはできませんでした。このように、「大手に取り込まれた」は、大手がこの規則を保証した、という意味ではないと読むのが正確です。社内で検討するときも、この言い回しをそのまま採用の根拠にしないよう注意してください。

公表されている検知の成績をどう読むか

READMEには、公開されている攻撃文の集まりや自前の試験データを使った、検知の成績が数多く載っています。目を引くのは、成績が使うデータによって大きく違う点です。たとえば、ある公開の試験データでは探索のレーンで9割を超える検知率が示される一方、より大きな同系統の試験データでは5割台、別の試験データでは1割台という数字も並んでいます。

README自身が、数字の限界を詳しく書いている点は評価できます。高い数字の一部は、その試験データを見ながら規則を書いた「答えを見た試験」に近いものだと注記し、該当する規則を除くと検知率が大きく下がることも示しています。また、以前に公表した誤検知の割合は裏づけが不十分だったとして撤回し、測り直しを予定しているとしています。誤検知の割合について、いま引用できる数字はREADMEの中にもないということです。

この状況から言えるのは、成績の数字を自社の導入判断の根拠にしてはいけない、ということです。検知の成績は、自社のエージェントの実際のやり取りで確かめるまで分からないと考え、見逃しと誤検知の両方を自社のデータで測る段階を必ず挟んでください。READMEが率直に限界を書いていることは信頼の材料になりますが、それは数字が高いことの裏づけにはなりません。

安全性の評価：注意付きとした根拠

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

根拠は三つです。第一に、重大度「高」のセキュリティ勧告が1件、2026年10月15日に公開されています。特定の規則に含まれる正規表現が、条件しだいで処理を長く滞らせる弱点（ReDoS）です。第二に、JavaScript向けの配布物の設定に、組み立てのときに自動で動く処理が書かれています。第三に、運営の組織はリポジトリと同じ日に作られ、ほかの実績から信頼を測れません。ライセンスはMITで、商用を含めて使える条件です。

一方で、スターの伸びは1日あたり約1.9件と穏やかで、水増しの兆候は見られませんでした。弱点の報告を非公開で受け付ける窓口も、READMEに明記されています。ただし、ここに挙げた確認で問題が見つからなかった部分も、安全の保証ではありません。精査は公開情報の範囲に限られ、規則やコードの中身を検証したものではないからです。

重大度「高」の勧告と、修正の状況

勧告の内容を、公開されている範囲で整理します。対象は、ある一つの検知規則です。この規則が使う正規表現は、特定の性質を持つ長い文字列を調べるときに、照合の試行が爆発的に増えて、数秒から場合によっては数分も処理が止まることがあるとされています。検知の仕組みは一本の処理の流れで照合を行うため、その間ほかの検査も進みません。共通脆弱性評価の基準（CVSS）での評価は7.5で、影響は使えなくなること（可用性）に限られ、情報の漏えいや改ざんにはつながらないと書かれています。

注目したいのは、勧告が「細工した入力だけでなく、普通の内容でも滞りが起きうる」と書いている点です。攻撃がなくても、見張りの仕組みそのものが業務を止める要因になりうるということです。影響を受けるのは、この規則を動かす警告と探索のレーンで、安定の規則だけを使う実施のレーンは対象外とされています。ただし、Python向けの部品は成熟度に関係なくすべての規則を読み込むため、どのレーンでも影響を受けると明記されています。

修正の状況です。勧告によると、JavaScript向けの配布物は版2.0.6から4.1.5未満が影響を受け、4.1.5で修正されました。Python向けの部品は0.2.6から0.3.0が影響を受け、0.3.1で修正されています。リリースの一覧では、4.1.5が10月13日、Python向けの0.3.1が10月15日に公開されています。ただし、リリースの説明文には、この弱点の修正についての記載が見当たらなかったため、更新を追う側は勧告の一覧も合わせて見る必要があります。

運営体制と配布で気をつけたい点

第一に、運営の体制です。READMEによると、管理者は台湾を拠点とする Adam Lin 氏で、一人が最終判断を持つ形です。運営委員会への移行は計画中とされ、まだ形になっていません。規則の追加や修正、弱点への対応が一人の判断と稼働に依存しているということは、管理者の事情しだいで更新が止まりうることを意味します。運営の費用は寄付で賄われていると書かれています。

第二に、組み立てのときに自動で動く処理です。JavaScript向けの配布物の設定には、部品を取り込む過程で組み立ての処理を自動で走らせる指定があります。これ自体は珍しいものではありませんが、取り込むだけで手元で処理が動くという点で、社内の開発環境や自動検査の環境に入れる前に、何が動くのかを確かめておく対象になります。

第三に、配布の名義です。JavaScript向けの配布ページで公開者として表示されているアカウントの名前は、GitHubの組織名とは異なるものでした。同じ管理者が別の名義で公開している可能性はありますが、確認できた情報からは断定できません。第四に、更新の速さです。規則の数は版ごとに増え、版4.1.5のリリースの説明では829とされています。READMEの中でも数字が場所によって異なり、どれが最新かは、README自身が正本と定めるデータのファイルで確かめる必要があります。

悪用されうるリスク

ATRは守りのための取り組みで、攻撃に使うための道具ではありません。それでも、公開されている規則であることから生まれうる危険はあります。最もよく指摘されるのは、規則が公開されていれば、攻撃する側もそれを読んで、引っかからない書き方を探せるという点です。これは Sigma や YARA でも同じで、公開された規則に頼り切る守りの一般的な弱点です。

次に挙げるのは推測ですが、今回の勧告そのものが一つの例です。見張りの仕組みが処理を滞らせる弱点を持っていれば、外部の道具が返す内容に手を加えられる者は、見張りを止める方向に使える可能性があります。勧告も、道具の出力に影響を与えられる攻撃者による使用不能を想定しています。守りの部品も、攻撃の入口になりうるという前提で扱う必要があります。

もう一つは、安心の独り歩きです。「エージェント向けの検知規則を入れた」という事実が、監視が足りている証明のように扱われると、見逃しの多さや誤検知の扱いが検討されないまま運用が続きます。なお、ATRが攻撃に悪用された事例は、2026年10月18日時点で確認した一次情報からは見つけられませんでした。

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

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

この手順の要は、入れる前に「どこで使うか」と「引っかかったら誰が動くか」を決めておくことです。検知規則は、入れた瞬間から「見張っている」という安心を生みます。その安心の中身を先に決めておかないと、記録だけが積み上がり、誰も見ていない状態が続きます。

企業が取るべき対策

一つ目は、エージェントの入出力を記録として残すことです。どの検知規則を使うにしても、エージェントが受け取った情報、呼び出した道具、渡した引数が記録に残っていなければ、照らし合わせる対象がありません。まず記録の範囲と保存の期間を決めることが、規則を選ぶより先に来ます。

二つ目は、検知を多層の一つとして位置づけることです。README自身が勧めているように、鍵の受け渡しの管理、実行の場の切り離し、影響の大きい操作の人による確認と組み合わせます。規則で拾えなかった攻撃でも、渡す権限が小さければ被害は小さくとどまるという考え方です。三つ目は、見張りの仕組み自体の監視です。検査にかかる時間を測り、滞りが起きたら気づける形にしておけば、今回のような弱点が見つかったときにも影響を早くつかめます。

四つ目は、取り込むときの点検です。組み立てのときに自動で動く処理がある部品は、社内の開発環境に入れる前に、何が動くかを確かめる決まりにします。五つ目は、調達のときの確認です。運営の体制、弱点の報告への窓口、更新の頻度、外部への送信の有無を、導入前に文書で確かめます。一人の管理者に依存する部品を、止めることのできない場所に置かない判断も選択肢に入れてください。

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

ATRは、AIエージェントへの攻撃の兆しを、決まった規則で機械的に拾う仕組みです。規則そのものはAIの判断に頼りませんが、検知の結果をAIに要約させたり、対応を任せたりする運用は考えられます。だからこそ、先に決めるのは、AIに判断させない部分です。

具体的には、どのレーンで動かすか、検知したときに止めるか、誰に知らせるか、誤検知と判断して閉じてよいのは誰か。この四つはAIにも道具にも委ねず、人が決めて記録に残します。AIに一次の仕分けを任せる場合も、判断の根拠となった規則の番号と該当した箇所を必ず書かせ、人が確かめられる形にします。やってはいけない向き合い方を挙げます。

• 「大手のOSSに取り込まれている」を理由に、自社での検証を省く
• 公表された検知の成績を、そのまま導入の稟議の根拠にする
• 既定の探索のレーンのまま稼働させ、どの規則が動いているかを把握しない
• 検知の結果をAIに判定させ、根拠を書かせずに閉じる
• 勧告の一覧を見ず、リリースの説明だけで更新の要否を判断する
• 見張りの仕組みの処理時間を測らず、滞りに気づけない状態で使う

裏を返せば、人が決める範囲ははっきりしています。どこで使うか、止めるか、誰が見るか、どう更新を追うか。この四つが決まっていないまま検知規則を入れても、守りの厚みは増えません。

よくある質問：検知規則を入れればエージェントは守れるのか

答えは「それだけでは足りない」です。検知規則は、決まった型に当てはまる兆しを拾う仕組みです。型に当てはまらない新しい手口や、言い換えられた攻撃は、規則が追いつくまで拾えません。READMEが示す試験データごとの成績の差も、この性質を表しています。

では入れる意味がないのかというと、そうではありません。エージェントの入出力を何も見ていない状態に比べれば、既知の手口を拾える目印を持つことは前進です。規則が共通の書式で公開されていれば、自社で書いた規則を他の仕組みに持ち出したり、他社の知見を取り込んだりしやすくなります。それが「Sigma のような共通の書式」を目指す意義です。

もう一つ、「ATRは業界の標準なのか」という問いもありそうです。確認した範囲では、標準化団体への提出は準備中の提案の段階で、正式に承認された標準ではありません。標準を目指している取り組みであって、標準そのものではないと理解しておくのが正確です。

• ATRの機能・版・体制・採用の状況は、GitHubのリポジトリとREADME、リリースの一覧、セキュリティ勧告、取り込み先の変更の申請を2026年10月18日に確かめた範囲に基づきます。内容は変わる可能性があります
• 採用の章に並ぶ取り込み先のうち、今回取り込み先で状態を確かめたのは Cisco と Microsoft の各1件です。その他はREADMEの記載によります
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順や、検知規則の中身は扱いません

まとめ

Agent Threat Rules は、AIエージェントを狙う攻撃を検知するための規則を、共通の書式で公開する取り組みです。規則ごとに試験の事例と既存の分類への対応づけを持たせ、成熟度とレーンで動かす範囲を選べる設計になっています。Cisco と Microsoft の公開リポジトリに関連する変更が取り込まれていたことは確かめられましたが、それは製品への採用や内容の保証を意味するものではありません。

一方で、2026年10月15日には重大度「高」の勧告が公開され、修正版は出ているものの、運営は一人の管理者が中心で、組織の実績も浅い状態です。成績の数字も、README自身が限界を明記しています。どこで使い、止めるのか、誰が見て、どう更新を追うのかを先に決めたうえで使うことが、この規則集との付き合い方です。

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