AIエージェントの設定ミスや鍵の漏れをOSS「AgentShield」はどう見つけるのか

「社員がClaude Codeを使い始めたが、設定の中身までは誰も見ていない」「MCPサーバーを足すたびに、AIエージェントに何を許したのか分からなくなる」——コード生成AIの導入を進める開発部門や情報システムの担当者が、口をそろえて挙げる悩みです。AIエージェントの危険というと、AIの答えの誤りや、外から送り込まれる攻撃に目が向きがちです。しかし、事故の入口になりやすいのはそれだけではありません。本当は、利用者自身が書いた設定の中に、鍵の書き込みや広すぎる許可がそのまま残っていることが見落とされやすい弱点です。この記事では、AIエージェントの設定を点検するOSS「AgentShield」を取り上げ、何をどう見つけるのか、外部のサービスにつながる部分はどこか、企業が使う前に何を決めるべきかを整理します。導入や操作の手順は扱いません。

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

AgentShieldは、GitHubの個人のアカウントで公開されているOSSです。READMEでは「AIエージェントの設定のための安全監査の道具」と位置づけられ、Claude Codeの設定から、書き込まれた秘密情報、権限設定の誤り、フックへの注入、MCPサーバーの危険、指示の文書を通じた乗っ取りの入口を探すと説明されています。フックとは、AIエージェントが道具を使う前後などに自動で動く処理のことです。

配布の形を確かめます。リポジトリは2026年2月11日に作られ、ライセンスはMITです。2026年10月27日時点でスターは1,329、派生は294、最後の更新は10月18日でした。リリースの一覧で確認できた最新版は9月10日の1.6.0です。READMEによると、2026年2月にAnthropicとCerebral Valleyが開いたClaude Codeの競技会（ハッカソン）で作られ、同じ作者のEverything Claude Codeという設定集の一部とされています。短期間の競技会から生まれ、その後も更新が続いているという経歴です。

作者のアカウントは2023年2月に作られ、公開リポジトリは28、フォロワーは約1.3万です。配布は、コマンドで動かす単体の道具、GitHub上の自動処理に組み込むGitHub Action、Everything Claude Codeの追加機能、GitHub上の連携サービス（GitHub App）の四つの形があると書かれています。このうち連携サービスは、作者の関係する別の名義が提供する有料の枠を含むサービスで、OSSの本体とは分けて考える必要があります。この点は後の章で詳しく書き分けます。

なぜAIエージェントの「設定」を点検する必要があるのか

Claude Codeのようなコード生成AIは、利用者の端末でファイルを読み書きし、命令を実行し、外部の道具とつながります。何を許すかは、設定の文書に書かれた許可の一覧、フック、MCPサーバーの登録、AIへの常設の指示で決まります。これらは便利さを求めて少しずつ書き足されることが多く、誰がいつ何を許したのかを、後から追いにくいという性格があります。

READMEは、開発者が他人の作った追加機能を入れ、MCPサーバーをつなぎ、フックを設定しているのに、その設定の安全を自動で確かめる手段がないことを問題に挙げています。設定の文書は、多くの場合ただの文字の文書です。鍵が書き込まれていても、すべての命令を許す書き方になっていても、AIエージェントは何も言わずに動きます。動くことと、安全に動くことは別だという点が、この種の点検が求められる理由です。

加えて、設定の文書はリポジトリに入れて共有されることがあります。一人の開発者の端末の中の問題だったものが、共有した瞬間にチーム全体、場合によっては公開のリポジトリへ広がります。設定を「個人の好み」ではなく、組織として点検すべき資産として扱う必要が出てきたと言えます。

見つけ方の基本：設定の文書を読み、決まりに当てはめる

AgentShieldの見つけ方は、静的な点検と呼ばれる方式です。AIエージェントを動かして様子を見るのではなく、設定の文書を読み、あらかじめ用意した危険の型に当てはまる書き方がないかを探します。READMEと変更の記録によると、決まりは15の分類に268個あり、秘密情報、権限、フック、MCPサーバー、AIへの指示などに分かれています。

点検の対象は、当初はClaude Codeの設定だけでしたが、1.6.0で大きく広がりました。変更の記録には、Codex、Gemini、Cursor、Copilot、OpenCode、Cline、Hermesなど、ほかのAIエージェントの設定の文書や、AIへの指示を書いた文書の読み取りに対応したと書かれています。指示の文書には、どのAIエージェントのものでも、Claude Code向けと同じ乗っ取りの点検を掛けるとされています。

もう一つの大事な事実は、開発者自身の比較の文書にAgentShieldはMCPサーバーに一度も接続しないと明記されていることです。MCPサーバーが実際にどんな道具を差し出しているかは見ず、設定に書かれた中身だけで判断します。これは外部への通信を起こさない安心材料であると同時に、動いている相手の中身は見えないという限界でもあります。

秘密情報の書き込みをどう見つけるのか

一つ目の柱は、設定の文書に直接書き込まれた鍵の発見です。READMEによると、AnthropicやOpenAI、Google、主要なクラウドの接続用の鍵、GitHubの個人用の通行証、チャットや決済のサービスの鍵、データベースへの接続の文字列、秘密鍵の中身などを、それぞれの鍵に特有の書き出しの形から見つけます。フックの中で秘密の値を画面に出してしまう書き方も対象です。

見つけた鍵は、報告の中では一部を伏せた形で示されます。また、基準として保存する点検結果には、鍵の値そのものではなく、元に戻せない形に変えた指紋だけを残すと説明されています。点検の記録そのものが新たな漏れの元にならないよう配慮されている点は、評価してよいところです。

自動の修正の機能もあり、READMEによると、書き込まれた鍵を環境変数（端末の外側に置く設定値）への参照に置き換えます。1.6.0では、修正のあとにもう一度点検し、点数が下がったり新たな重大な問題が出たりした場合は、すべての変更を元に戻す仕組みが加わりました。ただし、鍵を置き換えても、一度書き込まれた鍵が漏れていないことの証明にはならない点には注意が必要です。見つかった鍵は、置き換えと合わせて無効にし、作り直すのが基本です。

権限設定の誤りをどう見つけるのか

二つ目の柱は、AIエージェントに許した操作の点検です。権限の分類には17の決まりがあり、READMEでは、どんな命令でも実行できる許可、ファイルを無制限に書き換えられる許可、削除や管理者権限での実行を拒む一覧がないこと、確認を省く危険な指定、履歴を強制的に書き換える操作、外部への通信を広く許す書き方などが挙げられています。

1.6.0の変更の記録には、見逃しを減らした改善がいくつも並んでいます。たとえば、同じ意味の許可を別の書き方で書くと見逃していた点を、書き方をそろえてから照合するよう改めたとされます。また、広い許可がすでにある状態で狭い許可を消しても改善に見えてしまう問題に対し、より広い許可が狭い許可を覆い隠していることを知らせる決まりが加わりました。

点検の結果には、守りの設定も並びます。拒否や確認の一覧、隔離の設定、危険な操作を止めるフックなどは「認められた守り」として示され、減点されません。一方で、守りを足しても点数は上がらず、飾りの拒否の一覧で点数を稼ぐことはできないと明記されています。点数を下げるのは、実際に見つかった問題だけだという設計です。

フックへの注入と持ち出しをどう見つけるのか

三つ目の柱はフックです。フックは決まった場面で自動的に命令を動かすため、書き方を誤ると、AIエージェントが扱ったファイルの名前などがそのまま命令の一部として実行されるおそれがあります。READMEによると、フックの分類には40の決まりがあり、こうした注入の入口、外部への送信を伴う書き方、失敗を黙って通す書き方、作業の開始時に外から取ってきた処理を動かす書き方などを探します。

ほかにも、端末の鍵の保管庫やパスワードの記録を読む動き、外部から端末を操る通り道を作る動き、貼り付け用の一時的な記憶を使った持ち出し、記録の消去といった痕跡隠しも対象に挙げられています。READMEはさらに、最近のパッケージを使った攻撃の手口で使われた、居座りのための仕掛けの痕跡も探すと説明しています。悪いパッケージを消したあとでも残る仕掛けを、重大な問題として示すとされます。

フックの点検で難しいのは、危険な命令を「止めるための」フックにも、同じ危険な言葉が書かれていることです。1.6.0では、危険な命令を見つけて拒むための書き方を見分け、守りのフックを攻撃と取り違えないよう改めたとされています。ただし、言葉の並びで判断する方式である以上、取り違えが完全になくなるわけではありません。

MCPサーバーの危険をどう見つけるのか

四つ目の柱はMCPサーバーです。MCPは、AIエージェントが外部の道具やデータにつながるための共通の取り決めです。READMEによると、MCPサーバーの分類には49の決まりがあり、命令の実行やファイル全体へのアクセスのような危険の大きいサーバー、確認なしに自動で入手される登録、版の固定がない登録、設定の中に書き込まれた鍵などを探します。

遠隔のMCPサーバーについても、暗号化されていない通信、接続先の住所に付けた鍵、社内の機器やクラウドの管理用の住所への接続、すべての道具の利用を自動で認める設定などが対象です。また、道具の説明文に命令を紛れ込ませる手口や、別のサーバーの道具になりすます手口についても、設定の文書に書かれた範囲で点検すると変更の記録に書かれています。

ここで押さえるべきは、先に触れたとおりAgentShieldはMCPサーバーに接続しないことです。開発者の比較の文書も、動いているサーバーの道具の一覧を取り寄せて調べることは対象外で、今後の課題だと認めています。つまり、登録の書き方は点検できるが、サーバーが後から中身を差し替えても気づけないということです。MCPサーバーの中身の確認は、別の手段と組み合わせて考える必要があります。

指示の文書に紛れ込む命令をどう見つけるのか

五つ目の柱は、AIエージェントへの常設の指示や、役割ごとの指示の文書です。指示の分類には41の決まりがあり、READMEでは、確認なしに常に実行するよう促す文、外部の住所から取ってきたものを実行させる文、時間や条件で動き出す指示、パスワードなどを大量に集めさせる指示が挙げられています。

見えない形で紛れ込ませた命令も対象です。幅のない特殊な文字、画面に表示されない注釈、別の形に変換して読めなくした文などに隠された指示を探すとされます。また、「前の指示を無視せよ」のような乗っ取りの決まり文句や、点検の結果から警告を消せ、常に問題なしと報告せよといった、出力をゆがめる指示も対象に挙げられています。AIに点検を手伝わせる場面が増えるほど、こうした指示は見過ごせません。

ただし、READMEは限界も率直に書いています。追加機能として配られる手順書（スキル）の文については、他の指示の文書より点検の範囲が狭いと明記されています。開発者の比較の文書でも、スキルの点検は最も手薄な分野だと認めています。他人の作ったスキルを取り込むときは、この点検だけに頼らない方がよいでしょう。

点数の付け方と、誤検知への向き合い方

点検の結果は、AからFの評価と100点満点の点数で示されます。READMEによると、分類ごとに100点から始まり、見つかった問題の重さに応じて、重大なら25点、高なら15点、中なら5点、低なら2点を引きます。経営層への報告に使える形式の報告書や、監査の証跡としてまとめた一式を出す機能もあり、見つかった問題をSOC 2、PCI DSS、ISO 27001の管理項目に対応づける機能も1.6.0で加わりました。

誤検知への向き合い方も詳しく書かれています。READMEは、いま実際に効いている設定と、見本や説明書の中の設定、取り込んだ追加機能の保管場所の設定などを区別し、見本の中の危険な書き方は、点数への影響を4分の1に下げると説明しています。ただし、本物の鍵は見本の中でも重大なまま扱うとしています。

この区別は、運用の負担に直結します。点数が低く出ても、その多くが見本の中の指摘なら、急いで直すべきものは少ないかもしれません。逆に、点数がそこそこでも、いま効いている設定に重大な指摘が一つあれば、それが最優先です。点数だけを見ず、指摘がどの設定から来たかを読むことが、この道具を使いこなす前提になります。

外部のサービスにつながる部分を書き分ける

AgentShieldの基本の点検は、手元の端末やGitHub上の自動処理の中で完結し、設定の中身を外へ送りません。一方で、いくつかの機能は外部のサービスにつながります。社内で使う前に、どれがどちらかを整理しておくことが大切です。

機能	外部とのつながり	企業が確かめること
基本の点検と報告	手元またはGitHub上の自動処理の中で完結	点検の結果の保管場所と、見られる人の範囲
AIによる深い分析	設定の中身をAnthropicの窓口へ送る（利用者の鍵が必要）	送ってよい設定か、鍵を伏せてあるか
別の中継サービス経由の分析	設定の中身をOrcaRouterという中継サービスへ送る	社外の中継に設定を渡してよいか
パッケージ情報の照会	npmの登録情報を問い合わせる（既定では止まっている）	問い合わせで社内の利用状況が外に出てよいか
GitHub上の連携サービス	別の名義の事業者が運営するサービスにリポジトリを読ませる	利用規約、保存の扱い、料金、与える権限

AIによる深い分析は、攻める役・守る役・まとめる役の三つのAIに設定を読ませ、問題のつながりを洗い出す機能です。既定ではAnthropicのOpusとSonnetの系統のモデルが使われると書かれています。READMEは、中継サービスを使う場合について鍵を伏せていない設定には使わないようにと注意しています。同じ注意は、Anthropicへ送る場合にも当てはまると考えるのが自然です。

GitHub上の連携サービス（ECC Tools）は、そのページで第三者が提供するサービスとされ、別の利用規約と個人情報の扱いの方針に従うと書かれています。公開のリポジトリは無料、非公開のリポジトリは有料の枠です。READMEには有料版の料金も載っています。OSSの本体がMITだからといって、連携サービスまで同じ条件で使えるわけではありません。なお、報告の末尾に有料版の案内を出す機能もありますが、既定では止まっていると変更の記録にあります。

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

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

根拠は次のとおりです。作者のアカウントは2023年に作られ、フォロワーが多く、ほかにも公開の活動があります。ライセンスはMITで、商用も含めて使えます。GitHub上にこのリポジトリのセキュリティ勧告は登録されていません。配布されているパッケージの設定を確かめたところ、入手したときに自動で動く処理は見当たらなかったことも判断材料です。変更の記録は詳しく、何を直し、何がまだ足りないかを開発者自身が書き残しています。

一方で、気になる点もあります。リポジトリには、弱点を見つけたときの報告の窓口を定めた文書（セキュリティの方針）が確認した範囲では置かれていませんでした。READMEの中にも、決まりの数を102とする古い表が残っており、本文の268との食い違いがあります。問題が見つからなかったことは、安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。

悪用されうるリスク

AgentShieldは守りの道具であり、攻撃のための道具ではありません。それでも、使い方しだいで生まれうる危険はあります。最も現実的なのは、点検の結果そのものが、弱点の一覧になることです。どこに鍵があり、どの許可が広すぎるかをまとめた報告書は、攻撃する側にとっても価値のある資料です。報告書や監査の一式を、誰でも見られる場所に置かない決まりが要ります。

次に、AIによる深い分析の機能や中継サービスを使うと、設定の中身が社外に送られます。鍵を伏せないまま送れば、点検のための行為がそのまま漏えいになりえます。また、点検の道具自体が狙われる可能性も一般論としてあります。人気の道具は、似た名前の偽物のパッケージを置く手口の標的になりやすいからです。取り込むパッケージの名前と配布元を確かめることは、この道具にも当てはまります。

最後に、これは推測ですが、点数が高いことを理由に設定の見直しをやめてしまう、という使い方の危険もあります。決まりに当てはまらない新しい手口や、動いているMCPサーバーの中身の変化は、この点検では見えません。なお、AgentShieldが悪用された事例は、2026年10月27日時点で確認した一次情報からは見つけられませんでした。

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

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

この手順の要は、点検の道具を入れる前に、結果を受け取って動く仕組みを決めておくことです。指摘の一覧が届いても、誰が直すかが決まっていなければ、一覧は積み上がるだけになります。

企業が取るべき対策

一つ目は、AIエージェントの設定を管理の対象にすることです。どの部署が、どのAIエージェントを、どんな設定で使っているかを把握し、共有の設定の書き換えには確認を挟みます。二つ目は、鍵を設定の文書に書かない決まりです。鍵は専用の保管の仕組みか環境変数に置き、設定の文書に書かれた鍵は見つけしだい無効にして作り直す手順を決めておきます。

三つ目は、許可の一覧の考え方をそろえることです。すべての命令を許す書き方は原則として認めず、削除や管理者権限での実行などは拒否の一覧に入れる、という最低限の線を社内で決めます。四つ目は、MCPサーバーの登録の決まりです。登録してよいサーバーの一覧、版の固定、自動で道具の利用を認める設定の禁止を決めます。AgentShieldは登録の書き方しか見られないため、サーバー自体の審査は別に行う必要があります。

五つ目は、点検を一度きりにしないことです。GitHub上の自動処理に組み込めば、設定が変わるたびに点検できます。READMEによると、前回の結果との差分だけを問題にする使い方もできるとされています。新しく増えた問題を止め、既にある問題は計画的に減らすという分け方は、現場の負担を抑えるうえで現実的です。

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

AgentShieldには、AIに設定を読ませて問題のつながりを探す機能もあります。AIは、別々に見れば小さな問題が組み合わさって大きな穴になる筋道を示すのが得意です。それでも、AIに判断させない部分を先に決める必要があります。

具体的には、どの許可を認めるか、どの指摘を例外として残すか、設定を社外へ送ってよいか、どのMCPサーバーを使ってよいか。この四つはAIにも道具にも委ねず、人が決めて記録に残します。AIの分析を使う場合も、なぜそれを問題と見たのかの根拠を書かせ、結果を人が確認する範囲を先に決めておきます。READMEも、権限の変更は人の確認が必要だとしています。やってはいけない向き合い方を挙げます。

• 点数がAだったことを理由に、設定の見直しや審査をやめてしまう
• 鍵を伏せないまま、設定の中身をAIの分析や中継サービスに送る
• 自動の修正で鍵を置き換えただけで、漏れたかもしれない鍵を無効にしない
• 点検の報告書を、誰でも見られる共有の場所に置いたままにする
• 直さない指摘を、担当も期限も決めずに例外として残し続ける
• MCPサーバーの登録の書き方が合格したことを、サーバーの中身の安全と取り違える

裏を返せば、人が決める範囲ははっきりしています。何を許すか、何を例外にするか、何を社外へ出すか、どこにつなぐか。この四つが決まっていれば、点検の道具は判断の材料を速く集める役目を果たします。

よくある質問：点数が高ければ安全と言えるのか

答えは「言えない」です。AgentShieldの点数は、決まりに当てはまる問題が見つからなかったことを示すもので、設定が安全であることの証明ではありません。開発者自身も比較の文書で、動いているMCPサーバーの道具の確認、道具の定義の後からの差し替えの検知、スキルの深い点検などを、まだ足りない点として挙げています。何が見えていないかを知ったうえで点数を読むことが大切です。

もう一つ、「似た道具とどちらが優れているか」という問いもありそうです。開発者の比較の文書は13の道具と並べていますが、これは開発者自身による整理で、第三者の評価ではありません。その文書によれば、AgentShieldの強みは外部に送らずに点検できること、フックや権限の点検、監査の証跡づくりで、弱みは動いているサーバーの点検やスキルの点検とされます。選ぶときは、自社が一番心配している入口がどこかを先に決め、そこを見られる道具かどうかで判断するのが筋道です。

• AgentShieldの機能・版・決まりの数は、GitHubのリポジトリ、README、変更の記録、比較の文書、リリースの一覧、配布されているパッケージの情報を2026年10月27日に確かめた範囲に基づきます。内容は変わる可能性があります
• READMEには決まりの数を102とする古い表が残っており、本文と変更の記録の268と食い違っています。この記事では新しい方の268を採りました
• GitHub上の連携サービスが求める権限と、データの保存の扱いは、確認したページには書かれていませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

AgentShieldは、Claude CodeをはじめとするAIエージェントの設定を読み、書き込まれた鍵、広すぎる権限、危険なフック、MCPサーバーの登録の危険、指示の文書に紛れた命令を、268の決まりに当てはめて見つけるOSSです。MITで公開され、セキュリティ勧告の登録はなく、判定は「紹介可」としました。MCPサーバーには接続せず、書かれた中身だけで判断するため、外へ送らずに点検できる一方、動いている相手の中身は見えません。

AIによる深い分析、中継サービス、パッケージ情報の照会、GitHub上の連携サービスは外部につながるため、使うかどうかを分けて決める必要があります。点数は安全の証明ではなく、判断の材料です。何を許し、何を例外にし、何を社外へ出すかを人が決め、設定を組織の資産として点検し続けることが、AIエージェントと付き合うときの基本です。

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