agt CLI実践｜Agent Governance Toolkitの検証コマンドを実機で確かめる

agt CLI は、microsoft/agent-governance-toolkit（★5,420・MIT）に同梱されるAIエージェント統制の検証コマンド群だ。AIエージェントに「やってはいけないこと」を守らせる仕組みは、宣言した時点では何も保証しない。宣言どおりに止まるかを自分の環境で確かめて初めて、AIエージェントのガバナンスは統制として成立する。本記事は v4.1.0 を実機で走らせ、各コマンドが何を検証していて、CIゲートとして本当に機能する書き方は何かを実測で確かめた記録だ。

AIエージェント基盤の全体像は AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 をご覧ください。AGTそのものの設計思想・アーキテクチャは Agent Governance Toolkit完全解説｜Microsoft発のOWASP Agentic 10/10対応・本番AGガバナンス基盤 で扱っています。本記事は同じツールを「実際にコマンドを叩いて検証する側」から見ます。

agt CLIとは——AIエージェント統制を検証する7つのコマンド

agt は AGT 本体（ポリシーエンジン・ID・サンドボックス）とは別に、「今の状態を検査して報告する」役割だけを担うコマンドだ。agt --help が返す実際のコマンド一覧は次の7つだった。

重要なのは、このうち「そのままでCIゲートになる」のは lint-policy だけだという点だ。理由は後半で実測とともに示す。

検証の順番も結果を左右する。筆者が実際に回してみて有効だった順序は次のとおりで、verify を先頭に置かないのがポイントになる。

インストールと実機環境——[full]で実際に入る5つの配布物

READMEが案内する導入コマンドは1行だ。実機（macOS arm64 / Python 3.14.4）で実行した結果を示す。

python3 -m venv agtvenv
./agtvenv/bin/pip install "agent-governance-toolkit[full]"

約14秒で完了し、AGT関連としてインストールされたのは次の5配布物だった。

agent-governance-toolkit-4.1.0
agent-governance-toolkit-core-4.1.0
agent-governance-toolkit-cli-4.1.0
agent-governance-toolkit-protocols-4.1.0
agent-governance-toolkit-integrations-4.1.0

agt --version は agt, version 4.1.0 を返し、PyPI 上の最新版（4.1.0・2026-06-11 公開）と一致した。GitHub 側の最新リリースタグも v4.1.0（2026-06-09）で、リリースとPyPIの版は揃っている。

ここで押さえておきたいのが、v4.1.0 が「大掛かりな整理を終えた直後のバージョン」だということだ。READMEは、45個あった配布物を5つに統合したと明記している。この統合が、次章で扱う doctor の表示に直結する。

agt doctor の「1/8」表示——壊れているのはインストールではない

最初に実行するよう案内されている agt doctor が、いきなり不安な数字を返す。

🩺 AGT Doctor — Python 3.14.4

 agent_governance_toolkit  4.1.0  ✓ installed
 agent_os_kernel             —    · not installed
 agentmesh_platform          —    · not installed
 agentmesh_runtime           —    · not installed
 agent_sre                   —    · not installed
 agentmesh_marketplace       —    · not installed
 agentmesh_lightning         —    · not installed
 agent_hypervisor            —    · not installed

 1/8 packages installed

[full] を指定したのに 1/8。一見すると導入に失敗している。しかし実際には失敗していない。READMEのクイックスタートが案内する import を、そのまま実行して確かめた。

from agentmesh.governance import govern            # → 成功
from agent_os.policies import PolicyEvaluator      # → 成功

どちらも import に成功する。ただし両方とも DeprecationWarning を伴う。

DeprecationWarning: agentmesh-platform is deprecated.
Use agent-governance-toolkit-core instead.

つまり doctor は、v4.1.0 で統合されて消えた「旧配布物名」を数え続けている。実体（モジュール）は統合先の agent-governance-toolkit-core に同梱されて存在するので、分数だけが取り残される。健全なインストールが欠損に見えるという、典型的な偽陰性だ。

なお、READMEはクイックスタートの注記で「agentmesh の import は現行のラッパーAPIである」と説明している。実機ではその現行APIも DeprecationWarning を出すため、警告が出ること自体は異常ではない、と理解しておくのが安全だ。

agt verify は何を検証しているのか——OWASP ASI 10/10 の正しい読み方

AGTの看板は「OWASP Agentic Top 10 を 10/10 カバー」だ。agt verify はそれをコマンドで確認する。実行結果はこうなる。

Agent Governance Toolkit — Verification PASSED ✅
OWASP ASI 2026 Coverage: 10/10 (100%)
Toolkit: 3.2.2
Python: 3.14.4
Mode: components
Attestation: 36030d1ff59160b9...

 ✅ ASI-01: Prompt Injection
 ✅ ASI-02: Insecure Tool Use
 ✅ ASI-03: Excessive Agency
 ...
 ✅ ASI-10: Behavioral Anomaly

ここで2つ、読み違えやすい点がある。

1. Mode: components は「あなたのエージェント」を見ていない

この実行は、ポリシーもエージェントも1つも存在しない空のディレクトリで行った。それでも 10/10 PASSED になる。Mode: components が示すとおり、これは AGT自身の構成部品が揃っているか の確認であって、利用者のシステムの統制状態の評価ではない。

自分のシステムの実態を評価に含めたい場合は --evidence で実行時の証跡を渡す設計になっている。agt verify --help の記載は次のとおりだ。

Options:
  --badge          Output markdown badge only.
  --evidence FILE  Path to runtime evidence JSON/YAML.

--evidence は 既存ファイルを読み込む入力であり、証跡の出力先ではない。実際、存在しないパスを渡すと生成ではなくエラーになる。

$ agt verify --evidence ./agt-evidence.json --strict
Error: Invalid value for '--evidence': File './agt-evidence.json' does not exist.
# 終了コード 2

なお本記事では、実際の証跡ファイルを用意した --evidence 実行までは検証していない。確認したのは「--evidence が存在するファイルを要求する入力オプションであり、パスを渡すだけでは生成されない」ところまでだ。証跡モードで何が追加検証されるかは、実運用の監査要件に合わせて別途確かめてほしい。ここを曖昧にしたまま「10/10 が出たから適合」と扱うのが最も危うい。

2. 報告されるバージョンが実体と食い違う

出力の Toolkit: 3.2.2 に注目したい。インストールされているのは 4.1.0 である。

agt --version → agt, version 4.1.0
pip メタデータ → 4.1.0
agt verify     → Toolkit: 3.2.2

出所を追うと、agent_compliance/__init__.py の23行目に __version__ = "3.2.2" が据え置かれたままだった。統合前の値が残っている格好で、アテステーション（attestation）が実体と異なる版を名乗ることになる。適合性の証跡としてこの出力を保存する運用では、版の記録が合わなくなるため注意したい。

ポリシーを書いて agt CLI で二重に確かめる——lint と実行の食い違い

次はポリシーだ。READMEに載っている policy.yaml をそのまま保存して agt lint-policy にかけた。

$ agt lint-policy ./readme_policy/
readme_policy/policy.yaml:1: error: Missing required field 'version'
readme_policy/policy.yaml:11: error: Rule 'require-approval-for-send': unknown action 'require_approval'

2 error(s) found.
# 終了コード 1

READMEのポリシー例が、同梱linterのチェックを通らない。エラーは2種類ある。

・version フィールドの欠落：linter の必須フィールドは ("version", "name", "rules") と定義されている。READMEの例には version が無い
・require_approval が未知のアクション扱い：linter の既知アクション集合は {allow, deny, audit, block, escalate, rate_limit} の6種で、require_approval が含まれていない

1つ目は version: "1.0" を足すだけで解消する。実際に追加して再実行すると通った。

apiVersion: governance.toolkit/v1
name: production-policy
version: "1.0"          # ← これを足すと lint を通る
default_action: allow
rules:
  - name: block-destructive
    condition: "action.type in ['drop', 'delete', 'truncate']"
    action: deny
    description: "Destructive operations require human approval"

$ agt lint-policy ./policies/
No issues found.
# 終了コード 0

2つ目の require_approval は、もう少し丁寧に見る必要がある。「linterが知らない」ことと「動かない」ことは別だからだ。

govern() で本当に止まるか確かめる——実行時は fail-closed だった

ポリシーが「書けている」ことと「効いている」ことは別なので、実際に関数をラップして呼び出す。READMEの2行のAPIをそのまま使う。

from agentmesh.governance import govern

def db_tool(action: str, table: str):
    return {"table": table, "action": action, "rows": 42}

safe = govern(db_tool, policy="policies/fixed.yaml")

結果はこうなった。

read  -> ALLOWED {'table': 'users', 'action': 'read', 'rows': 42}
drop  -> GovernanceDenied: Action denied by policy rule 'block-destructive':
         Destructive operations require human approval

宣言どおりに止まる。deny ルールは実際に例外を投げ、ツール本体は実行されない。ここはREADMEの主張どおりだった。

続いて、linter が「未知」と言った require_approval を実行時に試す。承認ハンドラは何も設定していない状態で、send_email を呼ぶ。

Auto-rejecting approval for rule 'require-approval-for-send' — no handler configured
>>> BLOCKED: GovernanceDenied: Approval rejected by system:auto-reject:
    No approval handler configured — auto-rejected

これは重要な結果だ。「linter が unknown action と言う」という事実だけを見ると危険に見えるが、実行時は正しく解釈し、しかも安全側に倒れる。つまり食い違っているのは linter の語彙であって、ポリシーエンジンの挙動ではない。

実行時に有効なアクションの集合も確認しておく。

from agent_os.policies import PolicyAction
[m.value for m in PolicyAction]
# → ['allow', 'deny', 'audit', 'block']

判定の流れを図にすると次のようになる。require_approval は承認パスへ分岐し、ハンドラの有無で結果が決まる。

なお agt integrity も実行しておいた。こちらは素直に通る。

Integrity Verification — PASSED ✅
Modules checked: 15
All 15 files and 4 critical functions verified.

agt red-team scan をCIゲートとして機能させる——--strict の有無で結果が変わる

最後に、プロンプト防御の採点コマンドを見る。ここが最もCIに影響する箇所だった。

3種類のシステムプロンプトを用意した。①防御文を一切書いていない素のプロンプト、②防御文を4行書いたもの、③防御文を8行書いたもの。同じディレクトリに置いて採点させる。

$ agt red-team scan ./prompts/
  [!] agent_prompt.txt   Grade: F (8/100)   Coverage: 1/12
  [!] partial.md         Grade: D (33/100)  Coverage: 4/12
  [!] hardened.md        Grade: D (42/100)  Coverage: 5/12

  Results: 0/3 passed (min grade: C)

採点基準は12の攻撃ベクトルに対する防御記述のカバレッジだ。注目すべきは、「システムプロンプトを見せない」「上書き指示を拒否する」「ツール出力を命令として扱わない」など8行の防御文を書いても D（42点）止まりだったこと。既定の合格ラインである C にも届かない。multilang-bypass（多言語での回避）や unicode-attack（同形異字による回避）といった観点が抜けていると指摘される。

このコマンドは「プロンプトに攻撃文字列が含まれているか」を見ているのではなく、「防御の記述が揃っているか」を見るリンターである点も押さえておきたい。①のファイルには実際に “Ignore all previous instructions” という攻撃文を入れてあるが、それを検知して警告するわけではない。あくまで「この観点への備えが書かれていない」という不足の指摘であり、攻撃検知器ではない。

採点対象の12ベクトルと重大度

評価軸は実装（agent_compliance/prompt_defense.py）に定義されており、各ベクトルにはOWASP LLM Top 10（2025）のカテゴリが紐づけられている。重大度のほうは PromptDefenseConfig.severity_map の既定値として定義されており、呼び出し側で上書きできる（ベクトル固有の不変の属性ではない）点に注意したい。既定値のまま書き出すと次の12種になる。なお「何への備えか」の列は、各ベクトルの定義を踏まえた筆者の要約である。

この一覧を見ると、防御文8行でも D 止まりだった理由がはっきりする。多くの人が自然に書くのは data-leakage instruction-override role-escape あたりまでで、multilang-bypass や unicode-attack、context-overflow は意識して書かない限り埋まらない。裏を返せば、このスキャンは「思いつく防御」と「体系的に必要な防御」の差分を洗い出す用途で使うのが正しい。合格させること自体を目的にすると、点数のためだけの定型文をプロンプトに足すことになり本末転倒だ。

重大度が critical の2つ——data-leakage と indirect-injection——は特に優先度が高い。とりわけ indirect-injection は、RAGで取得した文書やMCPサーバー経由のツール出力に混入した指示をエージェントが実行してしまう経路で、エージェント特有の攻撃面にあたる。ここが埋まっていない場合は、点数以前の設計課題として扱いたい。

決定的な落とし穴：不合格でも終了コードは 0

CIに組み込む前提で、終了コードを確認した。

$ agt red-team scan ./prompts/ --min-grade B    # 3本とも不合格
$ echo $?
0                                               # ← ビルドは止まらない

$ agt red-team scan ./prompts/ --min-grade B --strict
$ echo $?
1                                               # ← ここで初めて止まる

READMEのCLI紹介に載っている例は agt red-team scan ./prompts/ --min-grade B で、--strict が付いていない。この行をそのままCIにコピーすると、全ファイルが F でもパイプラインは緑のまま通過する。一方 agt red-team scan --help 側の例には --strict が含まれている。

Examples:
  agt red-team scan ./prompts/ --min-grade B --strict

Options:
  --min-grade [A|B|C|D|F]  Minimum passing grade (default: C).
  --strict                 Exit non-zero if any prompt fails.

同様に、READMEに載っている agt verify --evidence ./agt-evidence.json --strict の --strict も確認した。agt verify のヘルプには --strict が出てこないが、渡してもエラーにはならず正常終了する。ソースを見ると理由がはっきりする。

@click.option(
    "--strict",
    is_flag=True,
    default=False,
    hidden=True,
    help="Deprecated: strict mode is now the default.  This flag is accepted but has no effect.",
    ...
)

「受け付けるが効果はない」と明記された後方互換フラグで、hidden=True なのでヘルプにも出ない。存在しないフラグ（例：--definitely-not-a-flag）を渡すと終了コード 2 で拒否されるので、--strict が黙って受理されるのは意図された互換動作だ。ただし利用者の側から見ると、「strict を付けたから厳格になった」と誤解しやすい。

CIに書くなら、実測で止まることを確認できた次の形にする。

agt lint-policy ./policies/                        # 構文エラーで exit 1
agt red-team scan ./prompts/ --min-grade C --strict # 不合格で exit 1
agt integrity                                       # 改ざん検出で exit 1

実測でわかった導入判断——どこから使い始めるべきか

実機で走らせた5コマンド（doctor / verify / lint-policy / red-team scan / integrity）の結果を1枚にまとめる。残る test と cred は本記事では未検証で、上の一覧でも終了コードを空欄にしている。

検証項目ごとの結果は次のとおり。

この結果からの実務的な結論は、はっきりしている。

具体的な着手順としては、次のように段階を踏むのが現実的だった。

・第1段階：govern() で1つのツール関数をラップし、deny が本当に効くことを手元で確認する
・第2段階：agt lint-policy をCIに入れる（そのままで exit 1 を返すため、追加の指定が要らない）
・第3段階：agt red-team scan --strict を追加し、まず --min-grade F など緩い基準から始めて段階的に上げる（実測では防御文8行でも D 止まりのため、いきなり B を要求すると全落ちする）
・第4段階：agt integrity で依存モジュールの改ざん検知を足す

エージェントの実行そのものを隔離したい場合は、プロセス分離の層を別に用意する必要がある。AGT自身のREADMEも「ガバナンスはアプリケーションのミドルウェア層で強制しており、OSカーネル層ではない。ポリシーエンジンとエージェントは同じプロセス境界を共有する」と明記し、本番ではエージェントごとのコンテナ分離を推奨している。この観点は AgentENV解説｜Firecracker microVMをforkして並列実行するE2B互換のエージェント基盤 で扱ったような、microVM/サンドボックス側の話題につながる。エージェントにOSレベルの操作を委ねる構成では cua（Computer-Use Agent）解説｜AIにmacOS/Linux VMを操作させる のような隔離実行環境と組み合わせる前提で考えたい。

他の手段との使い分け——agt CLI が埋める層はどこか

AIエージェント ガバナンスの実現手段は agt CLI だけではない。実機で触った範囲での役割の違いを整理しておく。重要なのは、これらが競合ではなく層として重なることだ。

この表で見落としやすいのが最下段から2つ目、プロセス分離はAGTが担わないという点だ。前述のとおりAGT自身がポリシーエンジンとエージェントの同一プロセス境界を認めており、govern() が守るのは「AGT経由で呼ばれたツール」だけである。エージェントが直接 subprocess を叩く経路や、AGTを介さない自作のツール呼び出しは素通りする。ラップし忘れたツールは統制の外にある——ここは実装者が意識して塞ぐ必要がある。

逆に言えば、agt CLI が最も費用対効果を発揮するのは「ポリシーを書いた／防御文を書いた」という人間の申告を機械的に検算する用途だ。書いたポリシーが構文として妥当か（lint-policy）、書いた防御文が体系的に足りているか（red-team scan）、依存モジュールが改ざんされていないか（integrity）——いずれも人手のレビューでは抜けやすく、かつ機械なら確実に検出できる領域である。

よくある落とし穴と対処

実機検証で引っかかった箇所を、対処とセットで整理しておく。

まとめ——「宣言」を「実測」に変えるための手順

AGTの agt CLI は、AIエージェントの統制を文書ではなくコマンドの終了コードに落とし込むための道具立てだ。実機で確かめた結論を3点に絞る。

1. 中核は宣言どおり動く。govern() の deny は確実に例外を投げ、承認ハンドラ未設定時は自動拒否で安全側に倒れる。ここは信頼してよい
2. 検証コマンドの表示は額面どおり読まない。doctor の 1/8 は偽陰性、verify の 10/10 は Mode: components（ツール自身の部品確認）、版表記は実体とずれる。いずれも v4.1.0 の大規模統合の途中経過として理解できる
3. CIゲートはフラグ次第。lint-policy と integrity はそのまま使えるが、red-team scan は --strict が無いと不合格でも通過する。verify --strict は効果のない後方互換フラグである

エージェント統制の価値は「ポリシーを書いたこと」ではなく「書いたとおりに止まると確認できたこと」にある。導入時は本記事のコマンドを自分の環境で一度走らせ、終了コードを目で確かめてからCIに載せてほしい。特にPublic Preview中は版ごとに挙動が変わり得るため、CIでは agent-governance-toolkit==4.1.0 のようにバージョンを固定し、上げるタイミングで各コマンドの終了コードを再確認する運用にしておくと事故が減る。ツールを信頼するかどうかではなく、信頼できる範囲を自分で測っておくことが、この種の統制基盤との付き合い方になる。

参照ソース

• microsoft/agent-governance-toolkit — GitHubリポジトリ（README・パッケージ構成・CLI例。★5,420 / MIT / 2026-07-29時点）
• agent-governance-toolkit — PyPI（4.1.0・2026-06-11公開。実機インストールに使用）
• v4.1.0 リリースノート — GitHub Releases（2026-06-09公開）
• Agent Governance Toolkit — 公式ドキュメント
• 本記事の各コマンド出力・終了コード・ソース引用は、上記PyPI版 4.1.0 を新規venvへ導入し 2026-07-29 に実行して取得したもの