AIエージェントのコードに潜む弱点をOSS「Agent Audit」はどこまで見つけられるのか

「社内でAIエージェントを作り始めたが、いつものコード検査で何も出ないのは、本当に安全だからなのか分からない」「MCPの設定ファイルに鍵がそのまま書かれていないか、全部を人の目で確かめるのはもう無理だ」——AIエージェントの開発を見守る立場になった、セキュリティ担当や開発管理の方からよく聞く声です。こうした悩みは、検査ツールを一つ足せば片づくように見えます。しかし本当の課題は道具の数ではありません。検査の結果が「何を確かめ、何を確かめていないのか」を、使う側が分かっているかどうかが分かれ目です。この記事では、AIエージェントのコードを動かさずに読んで弱点を探すOSS「Agent Audit」を取り上げ、検査の仕組みと、作者自身が公表した精度の訂正や限界の文書から見える使いどころを、一次情報に基づいて整理します。導入や設定の手順は扱いません。

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

Agent Auditは、GitHubで公開されているOSSです。READMEでは「本番に届く前に、AIエージェントのコードにある弱点を見つける」道具とされ、AIエージェント向けのセキュリティの文法検査にたとえられています。種類としては静的解析（プログラムを動かさずに、書かれた中身を読んで問題を探す方法）の道具です。

配布の形を確かめておきます。リポジトリは個人の開発者のアカウントで2026年2月3日に作られ、ライセンスはMITです。2026年10月16日時点でスターは238、フォーク（派生）は28、最後の更新は9月13日でした。GitHubのリリース欄の最新は9月13日の0.20.0で、Pythonの公開パッケージ置き場であるPyPIにも同じ日に0.20.0が登録されています。PyPIの記録では最初の版0.1.0が2月4日で、これまでに15の版が公開されています。

作者のアカウントは2024年9月の作成で、公開リポジトリは36件あります。貢献者の一覧では、コミット（変更の記録）の大半を作者が占めており、実質的には一人で保守されているOSSとみてよいでしょう。リポジトリの説明文は検査規則を51としていますが、READMEとPyPIの説明は66です。この食い違いには後の章で触れます。

なぜAIエージェントのコードに専用の検査が要るのか

READMEは、問題意識をはっきり書いています。AIエージェントはただの会話の道具ではなく、プログラムを実行し、道具を呼び出し、実際のシステムに触れます。そのため、危ない入力の通り道が一つあるだけで、本番の事故につながりうるという指摘です。

READMEが例に挙げる危険は三つです。利用者が書き込める文章を通じてAIの目的を書き換えるプロンプトインジェクション（文章に紛れ込ませた命令でAIを操る攻撃）、道具に渡った入力がそのまま命令の実行につながること、そしてMCP（AIと外部の道具をつなぐ取り決め）の設定の誤りで認証情報が漏れたり権限が広がったりすることです。どれも、ふつうのウェブアプリの検査で長く見てきた問題と地続きですが、AIが入力を受けて自分で道具を選ぶぶん、入口と出口の距離が短くなります。

従来のコード検査ツールは、一般的なプログラムの危ない書き方を広く見るように作られています。一方で、AIエージェント特有の部品、たとえば道具として登録された関数の入口や、MCPの設定ファイルの中身は、READMEによれば既存の道具の多くが読めないとされます。Agent Auditは、このAIエージェントに特有のすき間を埋めることをねらっています。

検査の芯：道具の入口から危ない処理までのデータの流れを追う

READMEの技術の説明によると、Agent Auditの中心は、データの流れの追跡（汚染の追跡とも呼ばれ、外から来た値がどこへ流れるかをたどる方法）です。AIエージェントが道具として登録した関数の引数を出発点にして、その値が、命令の実行やデータベースへの問い合わせ、文字列をそのままプログラムとして実行する処理に、チェックを通らずに届くかどうかを見ます。

ここで工夫されているのが、出発点を道具の入口に絞っている点です。READMEは、道具の入口であることが確かで、かつ検証されていない引数が危ない処理に流れる場合にだけ指摘する、と説明しています。どこからでも危ない処理を探すと指摘が多すぎて現場が疲れてしまうため、AIが外から受け取った値に的を絞ることで、指摘の数を抑える考え方です。

もう一つの柱は、プロンプトの組み立て方の検査です。READMEの検出の一覧には、利用者の入力をシステムプロンプト（AIに最初に与える基本の指示）に直接つなぎ込んでいる書き方を見つける規則が挙げられています。また、道具として登録された関数が文字列を何の確認もなく受け取っている書き方や、繰り返しの上限や人の承認なしでエージェントを動かしている書き方も、指摘の対象になっています。

MCPの設定ファイルと秘密情報の検査

企業の担当者にとって分かりやすいのが、MCPの設定ファイルの検査です。READMEによると、Agent AuditはMCPの設定を読み、出どころが確かめられていない接続先、広すぎるファイルの読み書きの許可、認証の欠如、版を固定していない部品の取り込みを見つけます。さらに、道具の説明文に隠れた指示が仕込まれていないか（ツールポイズニングと呼ばれる手口）、複数の接続先が同じ名前の道具を登録して、本物を上書きしていないかも調べるとされます。

加えて、最初に確かめた後で接続先の道具の中身が変わっていないかを、記録した基準と比べて調べる仕組みもあります。READMEはこれを、後から中身を差し替える手口（ラグプル）への備えとして説明しています。MCPの接続先は外部の人が作ったものを使うことが多く、一度確かめたら終わりにならない点を道具の側で支える発想です。

秘密情報の検出は三段階とされます。まず決まった形の文字列で候補を拾い、次に既知の鍵の形や文字のばらつき、見本用の値かどうかで絞り、最後にファイルの種類や試験用のコードかどうかといった文脈で調整します。READMEの出力例では、見つかった鍵の値は一部が伏せ字で表示されています。それでも、検査の結果そのものが「どこに鍵があるか」の一覧になることは押さえておきたい点です。結果の扱いについては対策の章で改めて触れます。

OWASPのエージェント向け10分類とどう対応しているか

Agent Auditの検査規則は、OWASP（ウェブの安全を扱う国際的な非営利のコミュニティ）が2025年12月に公開した、エージェント型のAIアプリの10大リスクをまとめた2026年版の一覧に対応付けられています。OWASPの公式ページによれば、これは計画を立てて行動するAIエージェントの重大な危険をまとめた枠組みで、100人を超える専門家の協力で作られたとされます。

READMEの対応表では、目的の乗っ取り、道具の悪用、識別と権限の乱用、供給網、コードの実行、記憶の汚染、エージェント同士の通信、連鎖する障害、人の信頼の悪用、制御を外れたエージェント、の10分類それぞれに規則が割り当てられています。規則の数が多いのは供給網（17）と識別と権限（12）、道具の悪用（11）で、エージェント同士の通信は1つだけです。

ただし、数え方には注意が要ります。表の分類ごとの規則数を足すと72になり、READMEが掲げる66と合いません。0.20.0のリリースノートによれば、6つの規則を取り下げて72から66にしたとされるので、表の内訳が取り下げ前のまま残っている可能性があると考えられます。10分類すべてを覆うという点は作者が確認したとしていますが、分類ごとの厚みには差があることは読み取っておきたいところです。

開発の流れに組み込む使い方

READMEが想定する主な使い方は、開発の流れ（CI：コードを変えるたびに自動で検査や試験を走らせる仕組み）への組み込みです。指摘の重大度に段階があり、どの段階以上が見つかったら検査を失敗扱いにするかを選べます。これにより、重大な指摘が残ったままのコードを本番に出さない関門として使えます。GitHubの自動実行の仕組みに組み込むための部品も用意されています。

ほかに、ある時点の指摘を基準として保存し、その後に増えた指摘だけを報告する仕組みや、検査の結果をGitHubの安全性の画面に送れる共通の形式で出す仕組みもあります。設定ファイルでは、検査から外す場所や、特定の規則を特定の場所で無視することを、理由とあわせて書けます。例外に理由を残せるのは、後で人が見直すときに役立ちます。

また、動いているMCPの接続先に問い合わせて、登録された道具の説明を調べる機能もあります。READMEは、この機能は読み取りだけで道具を呼び出さない、と説明しています。ただしREADMEの例では、調べたい接続先をその場で起動して問い合わせる形になっています。起動する以上、その接続先のプログラムは手元で動くことになると考えられ、中身の分からない接続先を調べるときは隔離した環境で行うのが無難です。

既存の検査ツールと何が違うのか

READMEは、Python向けの代表的な検査ツールであるBanditと、多くの言語に対応するSemgrepとを比べた表を載せています。下の表は、READMEの比較表と、作者が試験データで測った数値を整理したものです。数値はいずれも作者が自ら測ったもので、第三者による検証は確認できていません。

見る点	Agent Auditの場合	Banditの場合	Semgrepの場合
エージェント向けの脅威の分類に沿った規則	あり	なし	なし
MCPの設定ファイルの検査	あり	なし	なし
道具の入口からのデータの流れの追跡	あり	なし	なし
一般的なPythonの安全性の検査	一部	あり	あり
対応する言語	Python中心	Python	多言語
作者の試験での再現率（見つけた割合）	84.32%	29.7%	27.0%

表のとおり、Agent Auditの強みはAIエージェントに特有の部分です。READMEも、自らを汎用の検査ツールを置き換えるものではなく、補うものと位置づけています。なお、BanditとSemgrepの数値は、作者によれば両者が表せる範囲（注入や秘密情報など）に限った試験での値で、両者の適合率はいずれも100%とされています。指摘の正しさでは既存の道具が上回り、見つける範囲ではAgent Auditが上回る、という読み方が妥当でしょう。

READMEには、AIエージェントの開発部品を含む九つの公開プロジェクトを検査し、10分類すべての指摘が出たという結果も載っています。ただし、その指摘が本当の弱点だったかどうかの確認結果までは示されていません。指摘の件数は、そのまま弱点の数ではない点に注意が要ります。

公表された精度の数字をどう読むか

Agent Auditを評価するうえで最も大事なのが、この章です。2026年9月の0.20.0について、作者はリリースノートの冒頭で「これは訂正の版である」と書いています。以前このプロジェクトが載せていた適合率98.51%、再現率100%といった数字は取り下げられました。

取り下げの文書によると、これらの数字は実際に測ったものではなく、開発の指示書にあった目標の値が成果として載ってしまったものだったとされます。同じ時期に保存されていた測定結果では、再現率は47.46%でした。代わりに示されたのが、81の試験ファイル・238の正解の印に対する適合率68.86%、再現率84.32%という数字で、作者は再現の方法も添えています。90件の誤検知のうち少なくとも21件は、試験データに印がないだけで正しい指摘だとも説明しています。

さらに作者は、規則の数も整理しています。リリースノートによれば、同じ規則の集まりについて40、49、53、60以上、72と五つの異なる数を公表していたとし、動く仕組みのなかった6つの規則を取り下げて66に統一したとされます。リポジトリの説明文に残る51という数は、この整理から漏れたものとみられます。

こうした訂正を自ら公開する姿勢は、評価できる点です。同時に、以前の数字を見て導入を決めた組織は、判断の前提を見直す必要があるということでもあります。取り下げの文書は、論文や外向けの資料への訂正はまだ出していないとも書いています。

作者自身が書いた「できないこと」

リポジトリには、この道具が何をしないかを書いた文書があります。冒頭で作者は、読み込みに失敗したファイルがなく何も見つからなかったという結果は、安全のお墨付きのように見えるが、そうではないと書いています。

文書によると、Agent Auditは一つのファイルを一度読んで判断する道具です。ファイルをまたいだデータの流れは追わず、どの関数がどこから呼ばれるかも分からず、読み込んだ部品の中身も見ません。変数の型も分からないため、名前が同じ別の処理を危ない処理と取り違えることがあり、これが誤検知の最大の原因だとされます。言語で見ると、深く読めるのはPythonだけで、ほかの言語は文字の並びの照合にとどまり、シェルスクリプトは一切読まないと明記されています。

いちばん重い事実は、作者が「最も役に立つ数字は失敗の数字だ」と紹介している試験です。独立に確かめられた不具合が六つある実際のコードを、場所を教えずに検査したところ、見つけられた不具合はゼロでした。見逃したのは主に、ファイルや部品をまたぐ不具合だったとされます。作者はこの道具を「保証ではなく、ふるい」と表現しています。

加えて、0.20.0より前の版では、MCPの設定ファイルを探す処理が下の階層まで降りていなかったため、MCPに関わる六つの規則が、ふつうのフォルダ全体の検査では一度も働いていなかったとリリースノートは書いています。設定ファイルが下の階層にあるプロジェクトを以前の版で検査して何も出なかった場合は、新しい版で検査し直すよう勧めています。

安全性の評価：紹介可とした根拠

このラインでは、紹介するOSSを、公開されている事実だけを基に精査しています。OSSをダウンロードしたり動かしたりはしていません。Agent Auditの判定は「紹介可」です。

根拠にした事実は次のとおりです。作者のアカウントは2024年9月に作られ、ほかにも多くのリポジトリを公開しており、作ったばかりの使い捨てのアカウントではありません。スターの伸びは1日あたり0.9件ほどで、不自然な水増しの兆候は見られませんでした。GitHub上にこのリポジトリのセキュリティ勧告は登録されておらず、ライセンスはMITで、リポジトリの直下に取り込み時に自動で動く処理を含むファイルも見当たりませんでした。

セキュリティの方針の文書では、この道具は検査対象のコードを実行も読み込みもせず、検査中に外部へ通信しないとされています。弱点の報告は非公開の窓口で受け、48時間以内に受領を返すと定めています。そして先に見たとおり、作者は自らの数字の誤りを訂正し、限界を文書にしています。弱いところを隠さない運営は、守りの道具を選ぶうえで前向きな材料です。

なお、ここで問題が見つからなかったことは、安全の保証ではありません。このラインの精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。導入するかどうかは、自社の確認の手順に沿って判断してください。

導入前に知っておきたい注意点

紹介可とはいえ、一次情報を読むと気になる点もいくつかあります。一つ目は、外部への送信が起きる条件です。0.20.0のリリースノートによれば、スキルの説明文を判定する一つの規則は、追加の部品を入れ、AnthropicのAPIキーが環境に設定されていると、ふつうの検査の途中でスキルの説明文をClaudeのモデルに送るとされます。これを止める切り替えはなく、機密のコードを検査するなら、その工程ではキーを外すよう作者自身が勧めています。

二つ目は、文書どうしの食い違いです。セキュリティの方針の文書は「外部への通信をしない」と書いていますが、その文書は0.15系の時点の内容とされ、サポート対象の版の表も0.15系と0.14系のままです。最新は0.20.0なので、方針の文書が今の版の動きを正しく表していない部分があると読むべきでしょう。

三つ目は、配布元の記載です。PyPIの登録では作者の名義がチーム名になっており、連絡先のメールアドレスは説明用に予約された見本のドメインのものでした。PyPIの案内先のリンクはこのGitHubのリポジトリを指しています。配布物の出どころを確かめるときは、PyPIの名義ではなく、リポジトリとのつながりで確かめる必要があります。四つ目に、更新は9月13日で止まっており、保守が一人に集中している点も、長く使う道具としては考えておきたい点です。

悪用されうるリスク

Agent Auditは守りのための道具で、直接に攻撃に使う道具ではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、「検査で何も出なかった」が安全の証明として独り歩きすることです。作者の試験で実際の不具合を一つも見つけられなかったように、この道具の外にある問題は、検査を通っても残ります。

次に、推測であることを断ったうえで挙げます。検査の規則とその判定の考え方は公開されているため、攻撃する側が規則の型を避けたコードを書くことは難しくないと考えられます。特に、ファイルをまたいだ流れは追わないと明記されているので、危ない処理を別のファイルに分けるだけで指摘を逃れる可能性があります。悪意のある部品が混ざっていないかの確認に、この道具だけを頼るのは向きません。

また、検査の結果の扱いにも危険があります。結果は、どのファイルの何行目に注入の弱点や鍵があるかの一覧です。これが外に漏れれば、攻撃する側にとっての地図になりかねません。セキュリティの方針の文書も、結果を外部の仕組みに送る前に中身を確かめるよう勧めています。なお、この道具が実際に悪用された事例は、2026年10月16日時点で一次情報からは確認できませんでした。

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

Agent Auditのような検査ツールを検討するとき、機能の多さより先に確かめたい点があります。下の手順は、OSSを動かす前の段階で、資料と社内の取り決めで確かめられることに絞っています。

この手順の要は、道具を入れる前に、道具が見ない範囲を誰が見るかを決めておくことです。検査ツールは入れた瞬間から「通った」という印を出し始めます。その印が何を意味するかを先に決めておかないと、印だけが信頼を集めてしまいます。

企業が取るべき対策

Agent Auditを入れるかどうかにかかわらず、AIエージェントのコードの検査について、企業として決めておきたい対策を挙げます。一つ目は、AIエージェントのコードとMCPの設定を、検査の対象として明示することです。既存の検査の決まりがウェブアプリを前提にしていると、エージェントの道具の入口やMCPの設定ファイルが抜け落ちがちです。

二つ目は、検査の結果を秘密情報として扱うことです。結果には弱点の場所や鍵のありかが含まれます。結果を送る先、見られる人、残す期間を、ソースコードと同じ水準で決める必要があります。三つ目は、検査を走らせる環境の分離です。セキュリティの方針の文書も、隔離した環境で動かし、読めるファイルを検査対象に絞り、版を固定するよう勧めています。

四つ目は、MCPの接続先の棚卸しです。検査ツールは設定ファイルに書かれたものしか見られません。社内でどの接続先が使われているかを一覧にし、許可したもの以外を使わせない決まりと組み合わせて、初めて検査の結果が意味を持ちます。五つ目は、調達の段階での確認です。保守の体制、更新の頻度、弱点の報告への対応の約束、外部への送信の有無を、導入前に文書で確かめておきます。

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

Agent Auditには、追加の部品とAPIキーがあるときだけ、AIのモデルにスキルの説明文を判定させる規則があります。AIに判定を任せる部分が増えるほど、その判定がなぜそうなったかは分かりにくくなります。AIに判断させない部分を先に決め、AIに判定させるときは根拠を書かせて人が確かめるのが基本です。

取り下げられた精度の数字の一件も、同じ教訓を示しています。目標の値が成果として載ってしまったのは、数字に「どうやって測ったか」が添えられていなかったからです。人でもAIでも、数字を出させるときは測り方と再現の方法を書かせ、人が確かめる。やってはいけない向き合い方を挙げておきます。

• 検査で何も出なかったことを、安全の証明として報告書に書く
• 以前の版で何も出なかった結果を、版を上げた後も当てにし続ける
• 誤検知が多いからと、理由を残さずに規則を次々と無効にする
• 機密のコードを検査する工程に、AIのAPIキーを設定したままにする
• 公表された精度の数字を、測り方を確かめないまま導入の根拠にする
• 道具が見ない範囲を誰も担当しないまま、検査を通ったコードを本番に出す

裏を返せば、人が決める範囲ははっきりしています。どの重大度で止めるか、例外を誰が認めるか、道具が見ない範囲を誰が見るか、結果をどう守るか。この四つはAIにも道具にも委ねず、人が決めます。道具に任せてよいのは、人が決めた範囲で、決まった形の問題を速く広く拾う部分です。

よくある質問：検査で何も出なければ、そのエージェントは安全なのか

答えは「それだけでは分からない」です。作者自身の限界の文書が、何も出なかった結果の正しい読み方を書いています。それは、66の規則のどれにも当てはまる一つのファイルの中の書き方が、道具が読める言語の中で見つからなかった、という意味であり、コードが安全だという意味ではない、と。

では入れる意味がないのかというと、そうではありません。道具の入口から危ない処理への直接の流れ、MCPの設定に書かれた鍵、権限の広すぎる設定といった、決まった形の問題を人の手を使わずに毎回拾えることは、レビューの負担を確かに減らします。大切なのは、検査を守りの完成ではなく、守りの一枚と捉えることです。

もう一つ、「精度の数字を取り下げた道具を使ってよいのか」という問いもありそうです。見るべきは、誤りが見つかったときに公開の場で訂正し、再現の方法とともに数字を出し直したかという対応の流れです。今回はその流れが確認できます。そのうえで、自社のコードでどの程度の指摘と誤検知が出るかを、検証用の環境で確かめてから判断するのが現実的です。

• Agent Auditの機能・規則の数・版・精度の数字は、GitHubのリポジトリとその中の文書、PyPIの記録を2026年10月16日に確かめた範囲に基づきます。内容は変わる可能性があります
• 精度や他の道具との比較の数値は、作者が自ら測ったものです。第三者による検証は確認できていません
• この記事は防御と評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Agent Auditは、AIエージェントのコードとMCPの設定を動かさずに読み、道具の入口から危ない処理への流れや、設定に書かれた鍵、広すぎる権限といった、エージェントに特有の弱点を拾うOSSです。OWASPのエージェント向け10分類に沿った規則を持ち、開発の流れに関門として組み込めます。既存の検査ツールが読めない部分を補う道具として、検討する価値はあります。

一方で、作者自身が、過去の精度の数字を取り下げ、実際の不具合六つを一つも見つけられなかった試験の結果と、一つのファイルの中しか見ないという限界を公開しています。使うなら、0.20.0以降の版に固定し、外部への送信が起きる条件を外し、検査の結果を秘密情報として扱う。そして、道具が見ない範囲を誰が見るかを人が先に決めたうえで、ふるいの一つとして使うことが、AIエージェントの時代の検査との付き合い方です。

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