安全的 AI Agent 不能只靠「請勿外傳資料」或每次跳出人工核准。 Microsoft 公開 Azure SRE Agent 上線一年後的改造經驗，核心假設很直接：Agent 早晚會因提示注入、錯誤推理或工具輸出做錯事，所以限制要放在模型無法修改的執行環境外側。
企業不必因此把所有 Agent 搬到 Azure，但可以直接沿用這份架構檢查表。只要 Agent 能跑程式、呼叫 MCP、讀取正式資料或改雲端資源，就要問四件事：程式在哪裡跑、憑證放哪裡、網路由誰攔、哪些動作永遠需要人。
Microsoft 遇到的三種失敗
Microsoft 8 月 21 日工程文章描述三個具體問題。早期 harness、模型程式、工具與憑證同機，Agent 在 Token 過期後讀到 harness 內的 OAuth 流程並自行重建；另一次，沒有網路層阻擋模型把客戶資料送往 OCR 服務；還有一次，Agent 找到客戶憑證後把它寫進調查結果與記憶，即使附註「不要使用」，祕密也已進入模型上下文。
這些案例共同說明：模型看得到的控制程式，就可能被繞過；模型拿得到的憑證，就可能被複製；祕密進入上下文後，再補一條提示也無法撤回。
四道邊界各自擋什麼
| 邊界 | 做法 | 擋住的主要風險 | 仍未解決 |
|---|---|---|---|
| 執行隔離 | 推理留在受信任 runtime，程式與工具放進專屬 microVM | 讀取 host 檔案、修改 policy hook、共用核心逃逸範圍 | 工具本身是否有漏洞 |
| 無祕密憑證 | sandbox 只拿單次、目的地鎖定的 opaque handle | Token 被寫入檔案、環境變數、日誌或記憶 | 合法工具回傳的敏感資料 |
| 網路與輸出代理 | 預設拒絕外連，出口與工具結果在外部檢查 | 未授權外傳、祕密直接進模型上下文 | 被允許目的地上的錯誤操作 |
| 動作分級 | 可逆低風險自動執行，高影響動作人工核准 | 一鍵刪除、重大擴縮、不可逆變更 | 人類核准品質與疲勞 |
Azure SRE Agent 安全文件進一步確認，推理、microVM 工具執行、identity sidecar 與 network proxy 位於不同元件。每次工具呼叫啟動新行程，完成後終止整個 process tree；憑證由獨立 identity service 以短效 Token 供單次工具使用，不進模型推理上下文。
microVM 只能縮小模型程式碰到 host 與其他工作負載的範圍，無法判斷「重啟這台正式 VM 是否合理」。因此執行隔離後仍要有業務政策、資源範圍、速率限制、審計與回滾。
人工核准應留給哪一類動作
每一步都核准，Agent 只是換成聊天介面的遠端控制器；完全不核准，則把錯誤直接放大到正式環境。比較實用的分法是依可逆性、影響範圍與證據完整度決定。
查詢日誌、列出候選根因、在測試環境重跑唯讀檢查，可以在明確時間與資源範圍內自動化。重啟單一無狀態實例、調整可回復設定，需有前後健康檢查與自動回滾。刪除資料、變更身分權限、大規模擴縮、停用安全控制與跨客戶資料存取，應保留人工核准或雙人覆核。
企業可把這套分級和 AI Agent 上線檢查清單合併。若目前的安全設計主要寫在 system prompt，而網路、身分與工具層沒有強制控制，先別擴大自主權。
自建 Agent 的驗收問題
第一，模型產生的 shell、Python 與 MCP Server 是否和 orchestration、policy、祕密分開。第二，Agent 能否從環境變數、檔案、process 或錯誤訊息取得長效憑證。第三，出口白名單由誰執行，模型能不能改。第四，工具結果中的 API key、連線字串與個資是否在進上下文前過濾。
第五，所有正式動作是否帶上人、Agent、任務、目標資源與核准紀錄。第六，關閉 Agent 後，短效權限、工作檔與暫存記憶是否一起失效。更完整的零信任分層可接著看 AI Agent 零信任架構與 Agent containment 實務。
常見問題
AI Agent 放在 container 裡就安全了嗎？
不夠。Container 能提供隔離，但仍要分開 host、控制面、憑證與網路政策，並限制允許的資源與動作。Microsoft 的設計選擇專屬 microVM，原因之一是避免任意模型程式與其他工作負載共用 host kernel。
短效 Token 為什麼還不夠？
短效 Token 若直接進 sandbox，仍可能在有效時間內被讀取、重播或寫進日誌。更強的做法是讓 sandbox 只拿單次、目的地與操作都受限的 handle，由外部代理在送出請求時才注入真正憑證。
有 human-in-the-loop 就不需要 sandbox 嗎？
兩者解決不同問題。人工核准判斷高影響動作是否該做；sandbox、網路與憑證邊界則限制核准前後的程式能碰到什麼，不能互相取代。
這套做法只適用 Azure SRE Agent 嗎？
產品實作屬於 Azure，但原則適用任何能執行程式、使用工具或碰正式資料的 Agent。其他平台也可以用獨立 sandbox、egress proxy、短效權限和動作分級實作相同邊界。
參考來源
- Microsoft Command Line：Stop restricting the agent. Start restricting its environment.（2026-08-21）
- Microsoft Learn：Security overview for Azure SRE Agent（2026-07-30）
- Microsoft Learn：What are workload identities?（2026-05，2026-08-24 查核）
- Microsoft Learn：Access patterns and controls for AI agents（2026-06，2026-08-24 查核）