AI Agent 的風險，通常不在模型會不會想出一個錯誤答案，而在系統是否真的讓它把錯誤答案執行出去。當 Agent 開始讀寫資料庫、呼叫 SaaS、操作瀏覽器、執行程式碼，甚至委派工作給其他 Agent，安全問題就不再只是 Prompt Engineering，而是 Runtime Engineering。
本文結論：把 LLM 視為不受信任的規劃者，把 Runtime 視為可能被攻陷的工作負載；真正的安全邊界，應放在模型之外的政策、工具、憑證、網路與稽核平面。
一、先分清楚：推理能力不等於執行權限
模型可以提出「刪除檔案」、「付款」、「部署到正式環境」或「寄出郵件」，但它不該自行決定自己是否有權執行。這是 Agent Runtime 最重要的架構分界：模型負責提出動作，非模型的執行路徑負責授權與落地。
成熟的 Runtime 至少要處理排程、狀態、重試、工具派送、人工核准、憑證與生命週期控制。Runtime Enforcement 則回答另一組問題：這個動作能不能做、能對哪個資源做、能拿到什麼範圍的憑證、必須在哪種隔離環境執行，以及可以消耗多少時間、運算與網路資源。
這個分離和 Open Policy Agent（OPA）的設計精神一致：政策決策與實際執行點可以分開。NIST Zero Trust 也強調，不應因為工作負載位於內網、同一個叢集或同一家公司，就自動獲得信任。[1] [2]
二、企業級 Runtime，不是一個無限迴圈
最常見的 Agent 範例是「呼叫模型 → 執行工具 → 把結果交回模型」，但生產架構必須多出幾個可獨立信任與控制的元件：
- Orchestrator：負責模型回合、步驟、重試與委派，但不能自行擴張權限。
- Durable State：保存執行位置、待辦工作、核准與版本，支援中斷後恢復。
- Tool Gateway／PEP：統一驗證工具參數、套用政策、限流、去重與稽核。
- Policy Decision Point：根據身分、資源、風險、時間與核准狀態做出允許或拒絕。
- Credential Broker：授權完成後才簽發短效、限範圍的憑證。
- Sandbox 與 Egress Control：限制程式碼、檔案、程序、網路目的地與資源使用。
- Audit Plane：保存模型無法刪改的權威紀錄。
- Emergency Controller：獨立於 Agent 的緊急凍結、撤銷與終止路徑。
企業預設可採「中央治理、分散執行」的混合模型：政策管理、身分與稽核集中；工具閘道、網路邊界與 Sandbox 旁的 Enforcement Point 就近執行。這樣能保留一致治理，又不必讓每次低風險操作都依賴跨區的中央服務。
三、狀態可以恢復，不代表副作用可以重播
Agent 的狀態至少要拆成四類：模型對話、流程位置、授權與核准等安全狀態，以及外部系統真正發生了什麼的副作用狀態。若系統只在對話裡記著「款項已匯出」，那不是可靠的交易紀錄。
LangGraph 的 Checkpoint 適合保存 Graph 狀態與 Human-in-the-loop 流程；Temporal 的 Event History 則透過確定性重播重建 Workflow，並把 API、檔案、資料庫等外部工作放進 Activity。兩者都能提升可恢復性，但都不會自動把任意外部副作用變成 Exactly Once。[3] [4]
每個不可逆操作都應有一份獨立的動作帳本，至少記錄：run_id、step_id、標準化參數雜湊、政策決策、核准、憑證租約、Idempotency Key、外部 Operation ID，以及 PREPARED、DISPATCHED、COMMITTED、UNKNOWN、COMPENSATED 等狀態。Runtime 才能區分「模型想做」、「系統允許」、「請求已送出」與「外部系統已提交」。
四、Pause、Cancel 與 Terminate 是三件不同的事
Pause 不是 Kill。邏輯暫停通常只停止新的模型回合與工具派送；已送出的 API、正在執行的子 Agent、瀏覽器工作或 Sandbox 仍可能繼續。計時器、憑證租約與外部 Lock 也不會因為流程暫停而靜止。
因此 Runtime 應提供三個清楚的生命週期語意：
- Pause：停止新工作，保存可恢復狀態；對進行中工作明確選擇完成、取消或隔離。
- Cooperative Cancel：讓工作有機會清理資源、執行補償並寫入結果。
- Force Terminate：立即結束，不等待 Agent 合作，也不假設應用程式會完成清理。
Temporal 對 Pause、Cancellation 與 Termination 的區分，正好說明為什麼企業不能只做一顆「停止」按鈕。長時間暫停後恢復時，也必須重新核對政策、角色、核准、資源版本與未確認副作用，而不是直接從舊記憶繼續跑。[5] [6]
五、政策必須由可信資料驅動
Agent 說「主管已核准」只是一段不受信任的文字，不是授權事實。Policy Enforcement Point 應自行從身分系統、核准資料庫、資產分類、配額、威脅情報與事件狀態取得資料，並建立標準化的政策輸入。
一個高影響動作通常需要同時滿足：呼叫者身分保證等級足夠、核准內容綁定同一份標準化 Action Hash、金額或資料範圍未超限、憑證 Scope 精確吻合、目標在允許清單內，而且目前沒有 Incident Freeze。任何一項都不能讓模型自行聲明。
政策判斷也應回傳可執行的限制，例如最大金額、允許目的地、輸出上限、必須使用的 Sandbox 等級或需要的人工核准；Tool Gateway 在真正呼叫外部系統前再次強制執行。
六、隔離要依風險分級，網路預設拒絕
「跑在 Container 裡」不是完整的安全結論。不同技術提供的邊界不同：
- Process／Container：啟動快、相容性高，適合可信內部程式與低風險工作。
- gVisor：用 Userspace Kernel 攔截系統呼叫，降低工作負載直接接觸 Host Kernel 的範圍。[7]
- WebAssembly／WASI：以明確匯入能力與線性記憶體建立較窄的介面，適合可被限制在 Wasm 能力模型內的程式。[8]
- MicroVM：例如 Firecracker，以獨立 Guest Kernel 提供更強的租戶與執行隔離，適合不受信任程式碼與高影響自主操作。[9]
無論選哪一層，都要加上 CPU、Memory、PID、Disk、Output、Network 與 Wall-clock Budget。尤其是網路：Sandbox 若能任意連線，仍可外洩資料或繞過 Tool Gateway。企業預設應採 Deny-by-default Egress，只開放經政策核准的網域、Protocol 與資料流。
七、Agent 不該持有長效 Root Secret
最理想的流程是：先完成政策判斷與必要核准，再由 Credential Broker 簽發只對特定 Audience、Scope、Resource 與短 TTL 有效的臨時權限。SPIFFE/SPIRE 的 Workload Identity 與 Vault Dynamic Secrets，提供了可參考的短效身分與 Lease 模型。[10] [11]
模型 Context、工具輸出與 Sandbox 記憶體都不應出現第三方 Root Secret。若工具需要真實 Token，可由代理服務代持，Agent 只看見不具外部效力的 Placeholder 或 Opaque Capability。撤銷也必須發生在真正的 Issuer：刪除本地 Vault 記錄，不等於撤銷 Provider Token，更不代表已開始的 Session 自動停止。[12]
八、Kill Switch 要能在 Agent 不合作時生效
可防禦的緊急停止機制必須是多層、獨立且 Out-of-band。單純停止 Orchestrator 不夠，因為工作可能已經離開排程器。完整的 Emergency Stop 至少要能：
- 停止新 Run 與新 Session 進入。
- 發布 Emergency Deny Policy，讓各地 Enforcement Point 立即拒絕高風險操作。
- 停止排程與子 Agent 委派。
- 停止簽發新憑證，並向 Provider 撤銷既有權限。
- 封鎖 Egress 與外部 Tool Gateway 路徑。
- 先 Cooperative Cancel，再強制終止殘留 Sandbox。
- 保留 Checkpoint、政策、憑證與網路證據供鑑識。
這條緊急路徑應與一般執行路徑分離，並定期用 Failure Injection 演練。若 Kill Switch 只能在 Agent 正常回應時運作，它就不是安全控制，只是一個 UI 功能。
九、稽核要能重建「誰授予了什麼權限」
對每個重要動作，企業至少要能串起：Run → Tool Action → Policy Decision → Human Approval → Credential Lease → Sandbox → External Operation。紀錄應包含 Agent Revision、Policy Bundle、標準化參數雜湊、Sandbox Image Digest、Egress Destination、Idempotency Key、外部 Operation ID 與結果。
但不要把 Prompt、工具 Payload 與完整輸出無限制寫進永久 Log。它們可能含個資、商業機密、憑證與攻擊者注入內容。比較穩健的做法是保存結構化 Metadata 與 Hash，只在除錯或法規確有需要時，將原始 Payload 加密、限權且設定 Retention。
十、可落地的優先順序
如果團隊正把 Agent 從 PoC 推向 Production，可以依序完成：
- P0：所有重要工具都經過模型外的 PEP。先把不可逆、副作用大與資料敏感的動作收進 Tool Gateway。
- P0：動作標準化，核准綁定 Action Hash。避免核准的是 A，實際執行卻擴張成 A＋B。
- P0：外部副作用前後都落盤。加入 Idempotency、去重、Unknown Outcome 對帳與補償。
- P0：短效憑證與 Egress Allowlist。移除 Agent 身上的長效通用權限。
- P0：分開實作 Pause、Cancel、Terminate 與 Out-of-band Kill。
- P1：依風險提升 Sandbox。從 Hardened Container、gVisor／Wasm 到 MicroVM，不用一種隔離套全部工作。
- P1：建立 Append-only Audit 與演練。實測 Crash／Replay、Revocation、Resume、Network Partition 與 In-flight Side Effect。
成功指標不是「Agent 能完成更多步驟」，而是每一步的權限更小、結果可對帳、異常能停止、事故可重建，而且系統能在政策或基礎設施失效時進入安全降級。
結論
Agent 的核心產品價值來自推理與行動；核心風險也來自行動。當模型開始接觸真實權限，Runtime 就應從「把工具串起來的程式」升級成企業的執行與治理層。
最值得記住的設計原則是：LLM 提案，PEP 標準化，PDP 用可信資料授權，Credential Broker 發出最小臨時權限，Sandbox 在受限網路中執行，Runtime 把結果與證據持久化；另一條獨立的緊急路徑，隨時可以撤銷權限並終止執行。
狀態持久化讓 Agent 可以恢復，外部 Enforcement 讓它可以治理，Sandbox 讓執行可以圍堵，短效憑證讓權限可以撤銷，而獨立 Kill Switch 則確保它在不合作時仍然停得下來。這五件事，才是 Agent 從 Demo 走進 Production 的真正門檻。
