AIエージェントの操作を事前に止めるOSS「Agent Governance Toolkit」を解説

「AIエージェントに社内のデータベースや業務の道具を触らせたいが、何をされるか分からないのが怖い」「複数のエージェントが同じ鍵を使っていて、問題が起きたときにどれがやったのか分からない」——AIエージェントの業務利用を任された情報システム部門や、監査に備えるセキュリティ担当者から上がってくる声です。こうした不安には、指示文で「規則を守って」と念を押す対策がよく取られます。しかし求められているのは、より丁寧なお願いではありません。エージェントの操作を、実行される前に仕組みの側で判定し、その判定を後から証明できる形で残すことです。この記事では、MicrosoftがGitHubで公開しているOSS「Agent Governance Toolkit」を取り上げ、一次情報で確かめられる仕組みと限界、そして企業が導入前に決めておくべき点を整理します。導入や設定の手順は扱いません。

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

Agent Governance Toolkitは、Microsoftの組織アカウントでGitHubに公開されているOSSです。リポジトリの説明では、自律的に動くAIエージェントのための「方針の強制、身元の確認、実行の切り離し、信頼性の管理」をまとめた道具一式とされています。READMEの冒頭には、製品に近い品質の公開プレビューであり、正式版までに互換性のない変更が入る可能性があると明記されています。

配布の形を確かめます。リポジトリは2026年3月2日に作られ、ライセンスはMITです。2026年10月18日時点でスターは6,435、派生は1,138、最後の更新は10月17日でした。一日あたりのスターの伸びは約28件です。運営するMicrosoftの組織アカウントは2013年12月に作られ、公開しているリポジトリは8,378件にのぼります。作ったばかりのアカウントが急に注目を集めている形ではありません。Microsoftのオープンソース公式ブログは、2026年4月2日にこの道具の公開を告知しています。

中身は一つの塊ではなく、役割ごとの部品の集まりです。READMEには、方針の判定を担う部品、エージェント同士の身元と信頼を扱う部品、実行の権限を段階に分ける部品、信頼性を管理する部品、規制や基準との対応を確かめる部品などが並んでいます。開発者向けの部品はPythonを含む五つの言語で用意され、主要なエージェント開発の枠組みや、Copilot、Claude Code、Codexといった開発支援の道具に組み込めるとされています。READMEには日本語版も用意されています。

なぜ「指示文でのお願い」では足りないのか

READMEは、この道具が応えようとする問題を三つの問いで示しています。一つ目は「この操作は許されているか」です。メールの送信とデータベースの照会を許したエージェントが、表そのものを消す操作までできてはいけません。READMEは、従来の権限の仕組みはどのサービスに接続できるかを決めるもので、接続したあとに何をするかまでは決めないと指摘しています。

二つ目は「どのエージェントがやったのか」です。複数のエージェントが一つの鍵を共有していると、問題が起きたときに「エージェントがやった」としか言えず、事故の対応になりません。三つ目は「何が起きたかを証明できるか」です。監査や規制の担当者は、どの方針が有効で、エージェントが何を求め、なぜ許可または拒否されたのかを、改ざんされていないと示せる記録として求める、とREADMEは述べています。

そのうえでREADMEは、指示文の中で規則を守らせる方法について「制御の手段ではなく、確率で動く仕組みへの丁寧なお願いだ」と書いています。指示文への攻撃を完全に防ぐ方法は不明だとするOWASPの見解も引いています。だからこの道具は、指示文の中で勝負せず、操作が外へ出る手前で、決まった手順の処理として判定するという立場を取っています。

実行前に操作を判定する方針の仕組み

中核にあるのは、エージェントの操作を実行の前に捕まえて判定する仕組みです。READMEによると、道具の呼び出し、メッセージの送信、ほかのエージェントへの依頼が判定の対象になります。判定の結果は「許可」「拒否」に加えて、人の承認を待つという扱いも選べます。READMEの例では、表を消すような破壊的な操作は拒否し、メールの送信は担当チームの承認を求める、という方針が示されています。

方針は文書として書き、判定の処理はその文書を読んで決めます。公式ブログによると、方針の書き方は複数の形式に対応しています。判定にかかる時間について、提供元は方針の判定そのものが0.1ミリ秒未満で済むと説明しています。ただし、限界をまとめた文書では、複数のエージェントが通信し合う構成では一回のやり取りごとに5〜50ミリ秒ほどかかると見込むべきとも書かれています。速さの数字は、どの範囲を測ったものかを確かめて読む必要があります。

判定の処理は、READMEでは状態を持たず、同じ入力には同じ結果を返し、判定の途中で誤りが起きたら止める側に倒す作りだと説明されています。近年の更新では、判定の中核が別の公開仕様として切り出され、この道具は呼び出し側の部品と各枠組み向けの接続部品を受け持つ形に整理されました。判定の場所を一か所にまとめ、修正を取り込みやすくするためと説明されています。

エージェントごとの身元と、エージェント同士の信頼

二つ目の柱は、エージェントの身元です。公式ブログによると、エージェントごとに分散型の識別子と暗号の鍵を持たせ、エージェント同士が相手を確かめてからやり取りする仕組みが用意されています。相手のエージェントに0から1000までの信頼の点数を付け、点数に応じて許す操作を変える考え方も示されています。

これは、先に挙げた「どのエージェントがやったのか」という問いへの答えです。一つの鍵を共有するのではなく、エージェントごとに身元を分け、誰が何をしたかを記録で区別できるようにすることが狙いです。エージェント同士の通信を暗号化する仕組みや、組織をまたいでエージェントを連携させる仕組みも、リリースノートに追加の記録があります。

一方で、限界の文書には注意書きもあります。言語ごとの部品によって識別子の書き方が二通りに分かれており、識別子の先頭の文字列で方針を書くと、言語をまたいで一致しない場合があるとされています。複数の言語の部品を混ぜて使う構成では、身元の照合が想定どおりに働くかを確かめる必要があります。

権限の段階、緊急停止、信頼性の管理

三つ目の柱は、実行の権限を段階に分ける仕組みです。READMEでは、計算機の特権の段階になぞらえた四つの段階が説明されています。危険の大きい操作ほど上の段階に置き、必要なときに人の承認を挟むという考え方です。あわせて、エージェントを止めるための緊急停止の仕組みも用意されています。

四つ目の柱は、システムの安定運用の手法をエージェントに当てはめる部品です。公式ブログによると、サービスの目標水準と許容できる失敗の量の管理、連鎖的な失敗を止める遮断の仕組み、わざと障害を起こして耐性を確かめる試験、段階的な展開が含まれます。エージェントの失敗が次々に別のエージェントへ広がる事態を、仕組みで食い止めるための道具立てです。

ここで限界の文書が述べる点を押さえておきます。緊急停止の意味は、言語ごとの部品で異なるとされています。ある言語では登録した処理が成功したかどうかを示すだけで、別の言語では処理が終わったことを示すだけで、「停止した」という表示が、実際にプロセスが止まったことを意味しない場合があると明記されています。緊急停止を頼りにするなら、使う言語でそれが何を意味するのかを確かめておく必要があります。

改ざんを検知できる記録と、記録に残らないもの

判定の記録も、この道具の大きな特徴です。READMEによると、判定のたびに、有効だった方針、エージェントの要求、許可または拒否の理由が記録されます。記録は前後をつなぐ形で保存され、後から書き換えられたら分かる作りとされています。監査の担当者に「何が起きたか」を示す材料になります。

ただし、限界の文書は、記録が何を示すかについてはっきり線を引いています。記録に残るのは、操作が許可されたか拒否されたかという「試み」であって、その操作が外の世界で実際に成功したかという「結果」ではないとされています。許可された操作が途中で失敗した場合や、想定と違う結果を生んだ場合は、別の仕組みで確かめる必要があります。

もう一つ、記録が改ざんを検知できる作りであることと、誰かがその記録を見ていることは別の話です。判定の記録は、見る人と見る頻度が決まっていて初めて守りの役に立ちます。記録の保存先、保存期間、点検の担当を、導入の前に決めておくことが前提になります。

OWASPの上位10項目への対応は自己申告として読む

この道具は、OWASPがまとめた「エージェント向けの上位10のリスク」への対応を前面に出しています。リポジトリの説明には10項目すべてに対応するとあり、公式ブログも、10項目すべてに取り組む最初の道具だと述べています。一方で、READMEに掲げられた表示は「7項目が全面、3項目が一部」となっています。同じリポジトリの中でも、対応の度合いの書き方がそろっていない点は押さえておくべきです。

詳しい対応表を見ると、一部対応とされているのは三つです。外部の部品やプラグインを通じた供給網のリスクについては、使ってよい道具を固定する仕組みはあるものの、部品表の作成や依存関係の弱点の検査は組み込まれていないとされています。エージェントの記憶や文脈を汚染されるリスクは、対策の部品が任意で組み込む形のため、組み込んでいない外部の記憶の仕組みまでは保証できないとされています。人がエージェントを信頼しすぎることを突かれるリスクについては、承認の手順と受け皿は用意するが、承認の画面は利用者が作る必要があるとされています。

そして対応表の文書自身が、これは提供元による自己評価であり、第三者の監査や認証ではないと書いています。報道も、提供元の説明に基づくもので独自の検証は含まれていないと注記しています。対応表は「どのリスクにどの部品が向けられているか」を知る地図として使い、「10項目が片づく」という証明としては扱わないのが妥当です。

既存の手段と何が違うのか

AIエージェントの操作を制限する方法は、この道具以外にもあります。一次情報で確認できた範囲をもとに、よく使われる手段と比べます。どれか一つを選ぶというより、どの層で何を止めるかを分担させる話です。

見る点	指示文での制約	従来の権限管理	Agent Governance Toolkit	コンテナなどの隔離
止める対象	モデルの出力の傾向	接続できるサービス	個々の操作の内容	プロセスが触れる範囲
確実さ	確率に左右される	接続の可否は確実	決まった処理で判定	基盤の設定しだい
誰がやったか	区別しにくい	鍵の単位	エージェントの単位	実行の単位
判定の記録	残りにくい	接続の記録	方針・要求・理由を記録	基盤の記録
苦手なこと	攻撃に弱い	接続後の操作	推論の誤り・操作の組み合わせ	操作の意味の判断

表のとおり、この道具の位置は「接続した後に、個々の操作を内容で判定する層」です。限界の文書は、モデルの安全対策、この道具による操作の統制、業務処理の検証、基盤での隔離という四つの層を重ねる考え方を示し、この道具は多層防御の一つの層であって、戦略のすべてではないと述べています。

特に押さえたいのは、隔離との関係です。READMEは、この道具の判定は業務の処理の中間で行われ、基本ソフトの中核の水準では行われないと明記しています。判定の処理とエージェントは同じプロセスの中で動くため、エージェントごとに別のコンテナで動かし、基盤の水準でも切り離すことを推奨しています。

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

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

根拠にした事実は次のとおりです。運営はMicrosoftの公式の組織アカウントで、2013年に作られ、公開リポジトリは8,000件を超えます。ライセンスはMITで、商用を含めて使えます。スターの伸びは1日あたり約28件で、大手の公開としては自然な水準でした。GitHubのセキュリティ勧告の一覧には、2026年10月18日時点で公開済みの勧告は表示されていません。リポジトリの直下にはコンテナの定義ファイルがありますが、取り込みのときに自動で動く処理を含む設定は見当たりませんでした。

補足として、脆弱性の報告方針をまとめた文書には、過去に修正された問題が記されています。中でも、エージェント間の通信で使う認証の部品が要求全体と結び付いておらず、捕まえた要求の再送や改変を許しうる問題は、5.0.1で修正済みとされています。修正済みであるため判定は変えていませんが、古い版を使い続けると、修正済みの問題を抱えたままになる点は押さえてください。なお、勧告がないことや自動実行がないことは安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。

公開プレビュー段階であることと、更新の速さ

導入を考えるうえで最も大きな注意点は、正式版ではないことです。READMEは公開プレビューであり、正式版までに互換性のない変更が入りうると明記しています。変更履歴を見ると、2026年6月1日の4.0.0では、45あった配布物を五つにまとめる大きな変更が入りました。6月25日の5.0.0でも、全体の版をそろえる互換性のない変更が記録されています。

更新には安全面の修正も多く含まれます。変更履歴によると、4.0.0では複数の認可のすり抜けを塞ぎ、身元の確認の抜け道を閉じたとされています。それ以前の版でも、身元の確認の偽装や依存関係の検証のすり抜けといった問題の修正が記録されています。安全のための道具そのものにも弱点は見つかるということであり、版を固定して検証し、修正の取り込みを定期的に行う運用が欠かせません。

もう一つは、部品と接続先の多さです。言語ごとの部品、枠組みごとの接続部品があり、公式ブログや報道でも、すでに配布されているものと、動作する接続部品の段階のものが混在しているとされています。限界の文書も、すべてをそろえると単純な用途には過剰になりうると書いています。使う部品を絞り、一覧にして管理するのが現実的です。

悪用されうるリスクと、過信が生む落とし穴

この道具は守りのための仕組みで、攻撃に使う道具ではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、「統制の道具を入れたから安全」という安心が、確認されないまま独り歩きすることです。限界の文書は、方針を何も読み込んでいない状態では既定の動作が「許可」になり、寛容な動作の設定でもすべてを許可すると明記しています。

次に、判定の対象外の領域です。限界の文書によると、この道具はAIの推論の誤りや、外部の文書に紛れ込ませた間接的な指示の注入を検知しません。一つひとつは許可された操作でも、組み合わさると害になる流れも対象外とされています。ここからは推測ですが、許可された読み取りと許可された送信を順に使い、情報を外へ出す筋書きは考えられます。

さらに、エージェントが作業をまたいで持ち続ける鍵や通行証を、この道具は追跡も失効もしないとされています。検索で取り込んだ文書の出どころや鮮度の確認も対象外です。安全のための道具を狙う攻撃も考えられ、実際に過去の版では認証やすり抜けの問題が修正されています。なお、この道具が悪用された事例は、2026年10月18日時点で確認した一次情報からは見つけられませんでした。

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

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

この手順の要は、動かす前に「何を止めるか」と「何はこの道具では止まらないか」を両方決めておくことです。関所を設けると、通った操作はすべて正しいように見えてしまいます。対象外の領域を誰が受け持つかを決めずに入れると、その安心が守りの穴を隠します。

企業が取るべき対策

一つ目は、エージェントごとの身元を分けることです。複数のエージェントで一つの鍵を共有している状態をやめ、どのエージェントが何をしたかを、記録の上で区別できるようにします。この道具を使うかどうかにかかわらず、事故の対応と監査の土台になる考え方です。

二つ目は、取り返しのつかない操作に人の承認を挟むことです。削除、外部への送信、支払いなど、影響の大きい操作を一覧にし、承認の担当者を決めます。この道具は承認の手順を用意していますが、承認の画面は自社で作る必要があるとされています。三つ目は、基盤の水準での隔離です。READMEの推奨どおり、エージェントを別々のコンテナで動かし、外へ出る通信の範囲を絞ります。

四つ目は、鍵を短く切ることです。この道具は作業をまたいで持ち続ける鍵を追跡しないため、作業ごとに期限の短い鍵を渡す運用を別に用意します。五つ目は、調達のときの確認です。正式版になるまでの互換性の扱い、脆弱性の報告窓口と対応の期限、修正の公開の仕方を確かめます。報告方針の文書では、受け付けから24時間以内の応答と、確認から90日以内の修正を目標にしているとされています。

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

この道具は、AIエージェントの操作を仕組みで止めるためのものです。言い換えれば、止めるかどうかの判断を、AIに委ねないための道具です。判定は決まった処理で行われ、AIの判断は入りません。だからこそ、その処理が読む方針の中身は人が決める必要があります。

具体的には、どの操作を拒否するか、どの操作に誰の承認を求めるか、対象外の領域を誰が受け持つか、記録を誰がいつ見るか。この四つはAIにも道具にも委ねず、人が決めて文書に残します。方針の文書をAIに下書きさせる場合も、それぞれの規則の根拠を書かせ、人が一つずつ確かめてから使います。やってはいけない向き合い方を挙げます。

• 方針を読み込まないまま、または寛容な設定のまま本番で動かし、守られていると思い込む
• READMEの「10項目すべてに対応」という表示を、第三者の認証のように社内へ説明する
• 判定の記録に「許可」と残っていることを、操作が正しく終わった証拠として扱う
• この道具の判定があるからと、エージェントを同じプロセスや同じ端末でまとめて動かす
• 方針の文書をAIに書かせ、規則ごとの根拠を確かめずにそのまま使う
• 公開プレビューの版を固定せず、修正の取り込みと検証の担当を決めない

裏を返せば、人が決める範囲ははっきりしています。何を止めるか、誰が承認するか、何はこの道具で止まらないか、誰が記録を見るか。この四つが決まっていないまま関所を設けても、守りの厚みは増えません。

よくある質問：入れればエージェントの統制は完了するのか

答えは「それだけでは足りない」です。この道具は、個々の操作を実行の前に方針で判定する層を担います。限界の文書は、モデルの安全対策でも、内容の監視でも、基盤の隔離でも、そのまま使える規制対応の完成品でもないと、自ら範囲を区切っています。どの層を任せ、どの層を別に用意するかを決めて初めて、統制の一部として機能します。

では入れる意味が薄いのかというと、そうではありません。指示文の中のお願いに頼らず、操作の手前で決まった処理として止められること、エージェントごとの身元を分けられること、判定を改ざんの分かる記録として残せることは、監査や事故の対応で大きな助けになります。限界の文書によると、中核の部品はクラウドの特定のサービスに依存せず、通信のない環境でも動くとされています。

「Microsoftのクラウドを使っていないと意味がないのか」という問いもありそうです。上のとおり、中核の部品は特定のクラウドに依存しない作りと説明されています。ただし、組み込みの深さは枠組みごとに差があり、配布済みのものと接続部品の段階のものが混在しているため、自社が使う枠組みでどこまで使えるかは、一次情報で個別に確かめる必要があります。

• Agent Governance Toolkitの機能・版・限界・対応表は、GitHubのリポジトリとその中の文書、リリースノート、変更履歴、Microsoftの公式ブログを2026年10月18日に確かめた範囲に基づきます。公開プレビューのため、内容は変わる可能性があります
• OWASPの上位10項目への対応、判定の速さ、試験の件数などの数字は、提供元の説明・自己評価です。第三者による検証は、確認した範囲では見つけられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Agent Governance Toolkitは、AIエージェントの道具の呼び出し、メッセージの送信、ほかのエージェントへの依頼を実行の前に捕まえ、方針に照らして許可・拒否・承認待ちに振り分けるMicrosoftのOSSです。エージェントごとの身元、権限の段階と緊急停止、改ざんを検知できる判定の記録までをまとめて扱います。MITライセンスで公開され、運営はMicrosoftの組織アカウントで、GitHub上に公開済みのセキュリティ勧告は表示されていません。ただし、正式版ではなく公開プレビューの段階です。

一方で、判定の対象は操作であって、推論の誤りや操作の組み合わせによる被害は対象外です。方針がなければ既定で許可になり、記録が示すのは結果ではなく試みです。OWASPの10項目への対応も自己評価として読む必要があります。何を止めるか、何はこの道具で止まらないか、誰が承認し、誰が記録を見るかを人が先に決めたうえで、多層防御の一つの層として使うことが、この道具との付き合い方です。

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