2026年10月8日に、OWASP GenAI-LLM-Top10の現行READMEとLLM03:2026の正本を再読しました。READMEは2026年版の正本を2026/final/に置き、一覧のLLM03をExcessive Agencyとしています。個別原稿は過大な機能・権限・自律性を分け、高影響操作ではモデル外の認可、独立した検証、承認を求めます。入力・出力の消毒だけでは権限制御の代わりにならず、プロンプトインジェクションや不適切な出力とは別の論点です。これは現行正本の確認であり、事故統計や自社の対策優先度を独立に証明するものではありません。
2026年10月4日の確認では、OWASPの公開正本に「LLM03:2026 Excessive Agency」と記載されています。 初稿では、9月11日時点に取得できた発表文とスポンサーのコメントを手掛かりに、公式一覧の取得を保留していました。その留保を現在の結論として残すと、読者を誤らせます。
今回は公式リポジトリの一覧と、そこから指定される2026年版の個別原稿まで確認しました。「3位」という言い方を採る場合も、2026年版の第3項目であることと、あなたの会社で最初に対策すべきことは分けてください。 本記事では、旧稿の検証過程を残しながら、現在の確認結果と実務への読み替えを整理します。
30秒で要点
- 現行の公開正本で、Excessive AgencyはLLM03:2026と確認できます。
- 初稿の未取得留保、スポンサーの発言、現在の正本を分けて読みます。
- 資料の表示日は異なり、差の原因は今回確認できていません。
- 自社の対策は順位だけで決めず、機能・権限・実行経路を点検します。
確認した資料と、そこから言えること
表が収まらない場合は、横にスクロールできます
| 資料 | 実際に確認した内容 | この資料だけでは決まらないこと |
|---|---|---|
| 公式リポジトリのREADME | 現行版は2026、正本は2026/final/。一覧の第3項目はExcessive Agency | 自社の損害額、事故頻度、対策の優先順 |
| 2026年版のLLM03個別原稿 | 定義、機能・権限・自律性の3つの原因、対策と例示 | 個別の製品が安全であるという認定 |
| 2025年版の個別原稿 | 同じ名称はLLM06:2025 | 番号の移動だけでどれほど危険が増えたか |
| 9月の公式発表文 | 更新した順位、実インシデントを参照したという発行者の説明、スポンサーのコメント | 事件データの独立再分析、スポンサー発言の全解釈 |
比較の根拠は2025年版LLM06と2026年版LLM03です。版数を外して「LLM03＝過剰な権限」と覚えると、別年の資料を読むときに取り違えます。 名称、年、番号を一組で記録すると再確認しやすくなります。
スポンサーの発言は、今も発言者を付けて読む
OWASPの発表文には、Zenity共同創業者兼CTOのMichael Bargury氏によるコメントがあります。専門家の判断と事件記録がExcessive Agencyについてよく一致し、第3項目になった、という趣旨です。これは発表文内のスポンサー・支持者のコメント欄にあります。初稿の「このコメントは公式一覧そのものではない」という区別は引き続き必要です。ただし、現在は別途取得した公開正本でも第3項目を確認できるので、コメントしか根拠がないとは書けません。 発言の出所を確かめる工程と、発言内容を一次成果物で照合する工程の両方が必要でした。
この一致から、スポンサーが順位を決めたとは推測できません。逆に、スポンサーのコメント欄にあるから内容が誤りだとも言えません。発言者の立場を示し、確認できる部分を別の成果物と照合します。
「実インシデントを取り入れた」の読み方
正本READMEは、2026年版が専門家の判断と実際のインシデントの分析を組み合わせたと説明しています。9月の発表文も、多数の専門家と実インシデントに基づく研究を説明しています。ここまでは発行者が公表している作成方法の説明です。
本記事では元の事件データを再集計していません。事件の選び方、重複の除去、報告されなかった事件、企業別の母数まで検証したという意味ではありません。また、旧版が事件を全く参照していなかったという結論も、この説明だけからは出せません。
発表文には最初の48時間で1万件以上ダウンロードされたとの説明もあります。これは発行者の報告で、編集部が独立に数えた数字ではありません。資料への関心を示す説明と、対策の効果や採用企業の安全性の証明を混同しないようにします。
日付の差は、原因が分かったことにしない
今回の閲覧で、次の表示がありました。
- 公開物の案内ページは2026年8月3日を表示。
- 公式リポジトリのREADMEは、2026年版の公開日を8月4日と記載。
- 9月の告知ページは9月1日を表示し、本文の発表文は9月2日の日付。
公開物の掲載、正本の公開、後日の告知は別の時点であり得ます。ただし、今回の資料だけで日付差の理由を確定したわけではありません。 時差や更新処理が原因だと決めつけず、引用した資料の表示日と閲覧日を分けて残します。告知が9月だから、2026年版自体が9月まで存在しなかったとも断定しません。
Excessive Agencyは「権限が多い」だけではない
2026年版の定義は、モデルの予期しない、曖昧な、操作された出力に応じて、システムが損害を伴う操作をできてしまうことを扱います。原因は3つに分けられます。
表が収まらない場合は、横にスクロールできます
| 観点 | 編集部の架空例 | 確認する場所 |
|---|---|---|
| 過大な機能 | メール要約だけの用途に、送信・削除機能も渡す | モデルへ提供するツールと、その内部機能 |
| 過大な権限 | 本人の文書だけ読む用途に、全員の文書を書き換えられる共有アカウントを使う | 接続先の認可、利用者の範囲、書込み権限 |
| 過大な自律性 | 下書きの内容や宛先を人が確認する前に、外部へ送信する | 実行経路、承認内容、承認後の変更検査 |
この表は実在企業の事故報告ではありません。公式原稿が区別する原因を、業務設計で点検できる形に置き換えた例です。モデルへの「送信しないで」という指示だけに頼らず、送信機能を渡す必要があるか、接続先でも許可を制限できるかを調べます。
公式原稿は、出力の検証不足を扱うImproper Output Handlingとの違いも説明しています。JSONの形を検証しても、送信を許可された利用者か、宛先や対象が承認範囲内かは決まりません。反対に、認可が正しくても、画面への危険なHTML出力を防ぐ検証は別途必要です。
公開資料を、実務の点検に落とす手順
例えば、公開FAQを読んで問い合わせ回答の案を作る小さな検証なら、最初に必要なのはFAQの読取りと下書きの保存です。顧客名簿、管理者用DB接続、メール送信は、その検証に必要かを個別に判断します。
- 版と成果物を固定する。 資料名、年、個別番号、正本のURL、閲覧日を記録します。
working/の作業原稿を、公開済みfinal/と混ぜません。 - 操作の一覧を作る。 読む、検索する、下書きを作る、送信する、削除する、のように具体的な動詞に分けます。使わない機能は提供しません。
- モデルの外で範囲を検査する。 利用者、対象データ、接続先、実行条件をアプリまたは接続先で検査します。影響の大きい操作は、確定した内容を承認対象にします。
- 拒否と停止を試す。 範囲外の文書、未承認の宛先、承認後に変わった内容を合成データで試し、実行前に拒否されるかを確認します。ログと回数制限は、認可の代わりにせず損害を制限する仕組みとして設けます。
ここで挙げた試験は設計の入口です。記事を読んだだけで安全が保証されるわけではなく、実際の接続先と利用者の権限で検証する必要があります。具体的な境界と停止・復旧の例はAIシステムのセキュリティ対策で整理しています。
Agentic ApplicationsのTop 10とは別の資料
Top 10 for LLM ApplicationsとTop 10 for Agentic Applicationsは、資料名も識別番号も別です。2026年版LLM03の原稿は、エージェントのツール悪用、ID・権限の悪用、連鎖する失敗というASI側の項目との対応を示しています。対応表があることは、同一の一覧だという意味ではありません。
部署のチェックリストに取り込むなら「LLM03:2026」と「ASIのどの項目を参照したか」を別欄にします。AIエージェントのセキュリティやエージェントSSOと資格情報の違いへ進むときも、元の文書と対象システムの範囲を確認してください。
読み終えたら、1つの操作から照合する
現在の公開正本については、Excessive AgencyがLLM03:2026であることを確認できます。次に必要なのは、数字をそのまま優先順位にすることではなく、あなたのシステムが何を読み、何を実行できるかの照合です。まず1つの業務を選び、不要な機能、広すぎる権限、未承認の実行がないかを確かめてください。