AI Agent 上線後，真正危險的地方不是它會講錯話，而是它會做事。
它可能呼叫工具、查資料庫、寄信、改設定、跑程式、觸發付款流程，甚至跟其他 agent 協作。
這也是 Microsoft Agent Governance Toolkit 值得注意的原因：它處理的不是聊天回答，而是 agent 執行動作前後的治理。
Agent Governance Toolkit 是什麼？
Agent Governance Toolkit，簡稱 AGT，是 Microsoft 開源的 AI Agent runtime security 與 governance 工具。
Microsoft 在 2026 年 4 月先公開 AGT，5 月又進一步說明它如何與 Microsoft Agent Framework 搭配。
它的核心想法很直接：
Agent Action → Policy Check → Allow／Deny → Audit Log也就是在 agent 真正執行工具、存取資源或傳送訊息前，先經過政策檢查。
這和只寫 system prompt 很不同。Prompt 可以要求模型不要做某件事，但 runtime governance 是在執行層攔截。
為什麼 AI Agent 需要 runtime 治理？
傳統聊天機器人的風險多半是「回答錯」。
AI Agent 的風險是「做錯」。
常見情境包括：
- Agent 讀到不該讀的資料。
- Agent 呼叫不該呼叫的 tool。
- Agent 被 prompt injection 誘導。
- Agent 把內部資料送到外部系統。
- Agent 無限制產生雲端成本。
- 多個 agent 互相傳遞錯誤指令。
- Agent 執行過程沒有完整 audit trail。
Microsoft 在 AGT 介紹中提到，OWASP 在 2025 年底發布 Agentic Applications Top 10，列出 goal hijacking、tool misuse、identity abuse、memory poisoning、cascading failures、rogue agents 等風險。
這些問題很難靠「請模型小心一點」解決。
企業需要的是明確政策、身分、權限、隔離、記錄與中止機制。
AGT 和 Microsoft Agent Framework 怎麼分工？
Microsoft 的說法可以整理成兩層。
| 層級 | 負責內容 |
|---|---|
| Microsoft Agent Framework | 建立、編排、部署 agent，支援 multi-agent workflow、A2A、MCP、middleware、memory、hosting |
| Agent Governance Toolkit | runtime policy enforcement、zero-trust identity、sandbox、audit、cost governance |
簡單說：
- Agent Framework 負責把 agent 做出來。
- AGT 負責讓 agent 在可控邊界內運作。
這個分工很重要，因為企業最終不會只問「agent 能不能做事」，還會問：
- 這個 action 是誰授權的？
- 為什麼被允許？
- 如果被拒絕，原因是什麼？
- 有沒有留下可稽核紀錄？
- 成本超過門檻時能不能停止？
- agent 和 agent 之間的訊息能不能驗證？
AGT 提供哪些能力？
Microsoft 公開的資料中，AGT 涵蓋幾個重點能力。
1. Deterministic policy enforcement
治理規則不能只靠模型自己判斷。
AGT 的方向是用明確政策檢查 agent action。Microsoft 提到它支援 YAML rules、OPA Rego、Cedar 等政策語言，讓團隊可以把規則寫成可執行政策。
例子：
- 客服 agent 只能查自己的客戶範圍。
- 財務 agent 超過一定金額必須升級人工審核。
- coding agent 不能改 production secret。
- sales agent 不能把合約資料送到未核准外部 tool。
2. Zero-trust identity
Agent 不能只共用一組 API key。
每個 agent 都應該有自己的身分、權限與審計軌跡。
Microsoft 在 AGT 中強調 agent identity、trust scoring、secure agent-to-agent communication。這對多 agent 系統尤其重要，因為你需要知道是哪個 agent 發出請求，而不是只看到「某個 AI 系統做了事」。
3. Execution sandboxing
Agent 如果能執行程式、瀏覽器、Shell 或自動化任務，就需要 sandbox。
Sandbox 的目的不是讓 agent 變聰明，而是把可能的破壞半徑縮小。
例如：
- 限制檔案系統範圍。
- 限制網路存取。
- 限制可呼叫工具。
- 隔離測試環境與正式環境。
- 執行危險 action 前要求人工批准。
4. Audit trail
Agent 的每個重要 decision 都應該留下紀錄。
最基本要記：
- agent 身分。
- 使用者身分。
- tool call。
- 輸入摘要。
- policy decision。
- allow 或 deny 原因。
- action 結果。
- 成本與 token 使用量。
沒有 audit trail 的 agent，很難進入金融、醫療、法務、人資、IT 管理等高風險流程。
5. Cost governance
AI Agent 的成本風險比 chatbot 更高。
因為 agent 可能自己拆任務、重試、呼叫多個模型、跑工具、讀大量文件。
AGT 這類工具需要能設定 budget、threshold、kill switch 與異常行為偵測。
不然一個看似小的任務，可能在背景開出一串昂貴流程。
企業導入前的檢查表
如果公司準備讓 agent 進入正式流程，可以用這份檢查表。
| 問題 | 上線前應有答案 |
|---|---|
| Agent 可以做哪些 action？ | 明確 tool 與權限清單 |
| 誰授權 agent 做這些事？ | 使用者、角色、流程與政策 |
| 哪些資料可以讀？ | 資料分類與最小權限 |
| 哪些 action 必須人工確認？ | 金額、刪除、外部傳送、production change |
| 出錯後怎麼追查？ | audit log 與 decision record |
| 成本暴增怎麼停？ | budget、rate limit、kill switch |
| 被 prompt injection 怎麼辦？ | action 層政策檢查，不只靠 prompt |
AGT 不等於合規保證
Microsoft 在文件中也有法律提醒：政策檔與範例是治理模式示範，不保證符合特定法規。
這點很重要。
AGT 這類工具可以幫企業實作控制措施，但不能取代法務、資安、稽核與實際營運流程。
企業應該把它視為 agent 上線架構的一部分，而不是完整合規答案。
為什麼現在值得關注？
2026 年的 AI Agent 正在從 demo 走向 production。
一旦 agent 開始接工具、接資料、接系統，治理就不能停留在「請模型遵守公司政策」。
更合理的架構是：
Prompt safety
+ Tool permission
+ Runtime policy
+ Agent identity
+ Sandbox
+ Audit log
+ Cost controlMicrosoft Agent Governance Toolkit 的訊號是：AI Agent 的競爭不只會比模型能力，也會比誰能把 agent 放進企業真實控制面。