５月２０日，Microsoft 開源兩個 AI agent 安全工具：RAMPART 與 Clarity。
這件事比一般工具發布更重要。因為它代表 agent 安全開始從「安全團隊做一次 red team」走向「工程團隊每天在 CI 裡跑測試」。
過去很多 AI 安全流程像是上線前健檢：找紅隊測一輪、修掉幾個問題、寫一份報告，然後產品繼續迭代。問題是 agent 會一直變：新工具、新資料源、新 prompt、新 memory、新 workflow、新權限，任何一個改動都可能讓舊漏洞復活。
Microsoft 這次的訊號很清楚：
AI agent 安全不能是週期性審查，要變成持續工程 discipline。
RAMPART 和 Clarity 是什麼？
Microsoft 的兩個工具分工很明確。
| 工具 | 作用 | 放在流程哪裡 |
|---|---|---|
| RAMPART | 把 adversarial scenario、red-team findings、prompt injection 與事故重現轉成可執行測試 | 開發中、CI/CD、回歸測試 |
| Clarity | 在寫程式前釐清需求、架構假設、失敗模式與決策紀錄 | 設計階段、PR 討論、架構審查 |
RAMPART 偏「測」。
Clarity 偏「想清楚」。
兩者合在一起，就是把 AI 安全從一份報告變成 repo 裡的工程資產。
RAMPART：把 red-team 發現變成測試
RAMPART 建在 Microsoft 既有的 PyRIT 上，但定位不同。
PyRIT 比較像紅隊與安全研究者用來探索模型與系統弱點的工具；RAMPART 則更貼近工程師，讓團隊把攻擊情境寫成類似 integration test 的測試，放進 CI 裡持續跑。
Microsoft 的設計重點有幾個：
１．針對 cross-prompt injection
Agent 會讀 email、文件、ticket、網頁、CRM 記錄。這些外部內容可能藏有指令，間接操控 agent 行為。RAMPART 目前成熟覆蓋的重點就是這類跨 prompt 注入。
例如：
- 客服 agent 讀到惡意客服信件後，把內部資料外送。
- Coding agent 讀到惡意 issue 後，新增後門依賴。
- 研究 agent 讀到被污染網頁後，覆寫原本任務。
這些都不是單純輸入框測試能抓到的。
２．支援機率式測試
LLM 行為不是 deterministic。一次測試安全，不代表十次都安全。
RAMPART 支援 statistical trials，讓團隊可以設定「同一場景跑多次，安全行為至少要達到某個比例」。這比單次 pass／fail 更接近 production agent 的現實。
３．把事故變成 regression test
如果某次 red team 發現 agent 會把 CRM 資料貼到外部 ticket，修完後不該只關 issue。更好的做法是把這個情境變成 RAMPART test，之後每次改 prompt、改工具、改資料源都跑一次，避免回歸。
這是 AI 安全工程化的關鍵。
Clarity：先檢查「為什麼要這樣設計」
RAMPART 處理已經有系統可測的問題，Clarity 則往更早一步走：在寫程式前，先檢查團隊是不是正在做錯東西。
Microsoft 對 Clarity 的描述很像「架構師＋產品經理＋安全工程師」的結構化對話工具。它會帶團隊釐清：
- 問題到底是什麼？
- 這個功能真的需要 agent 嗎？
- Agent 應該有哪些工具？
- 權限邊界在哪？
- 什麼情境會失敗？
- 人類審批在哪裡？
- 哪些設計假設可能之後變舊？
Clarity 會把結果寫進 repo 裡的 .clarity-protocol/ 目錄，用 markdown 保存。這點很務實：它不是把安全討論鎖在某個 SaaS 儀表板，而是變成可以 commit、review、diff 的專案檔案。
這會讓 agent 安全討論更接近工程文化。
為什麼這剛好接上「agent 安全是系統問題」？
５月２５日 CSO 另一篇整理提到，研究者主張 AI agent 安全要從模型問題轉成系統問題。
RAMPART／Clarity 正好是這個觀念的實作版本。
如果模型本身不能被完全信任，那安全就要放到外層：
- 工具呼叫要被觀察。
- 資料流要被限制。
- 權限要被拆小。
- 失敗案例要能重現。
- 設計假設要被記錄。
- 修補後要能回歸測試。
RAMPART 處理「能不能重現與測」。
Clarity 處理「當初為什麼這樣設計」。
這比單純喊「加強 guardrails」有用，因為它把安全拉進工程流程。
對企業導入 agent 的影響
未來企業導入 AI agent，安全審查可能會多三個新要求。
１．Agent PR 要包含安全測試
如果一個 PR 新增 agent 工具或資料源，它不只要有功能測試，也要有 agent safety tests。例如：agent 讀到惡意文件時，不能外送內部資料；agent 遇到要求改權限的 ticket 時，不能直接執行。
２．Red-team findings 要轉成可跑測試
紅隊報告不能只是一份 PDF。每個可重現問題都應該被轉成測試，進入 CI，成為未來變更的防回歸網。
３．設計假設要能被 review
Agent 為什麼能讀 CRM？為什麼能寄信？為什麼能改 repo？為什麼能讀客戶個資？這些問題不能只存在會議記錄裡，要和程式碼一起被 review。
Clarity 的 .clarity-protocol/ 方向就是把這些假設版本化。
台灣團隊可以怎麼用這個概念？
不一定要馬上導入 RAMPART 或 Clarity 本身，但可以先採用它們背後的工作流。
最低限度可以做四件事：
１．每個 agent 功能都附一份 threat model。
２．每個外部資料源都設計 prompt injection 測試。
３．每次新增工具權限，都要新增一個失敗情境測試。
４．每次 red team 或事故，都轉成 regression test。
如果公司已經有 CI/CD，這套流程其實不陌生。只是測的不是傳統函式輸入輸出，而是 agent 在真實資料、工具與外部內容下的行為邊界。
這會是 ２０２６ 年企業 AI 導入的分水嶺：只會 demo 的 agent，和能進 production 的 agent，差別就在這裡。
這件事的真正訊號
Microsoft 開源 RAMPART 與 Clarity，說明大廠已經承認一件事：
AI safety 不能只靠安全團隊，也不能只靠模型團隊。它要變成軟體工程流程。
這也是 agent 時代的安全成熟度標準。未來問一家企業 agent 安不安全，不該只問「有沒有 red team」，而要問：
- Red-team 發現有沒有進 CI？
- Prompt injection 測試是否能重複跑？
- 設計假設是否版本化？
- 高風險工具新增時是否同步新增 safety test？
- 修補後是否能證明問題沒有回歸？
能回答這些問題的 agent，才有資格進正式環境。