對於許多剛接觸雲原生開發的 junior 工程師來說，我們習慣將 Kubernetes (K8s) 上的工作負載視為「微服務」或「批次作業」。微服務的特點是依賴關係明確、資源消耗穩定且路徑可預測。然而，當我們引入「自主 AI Agent」（Autonomous AI Agents）——例如一個能自動診斷生產環境故障並嘗試修復的 AI 助手時，傳統的安全模型會徹底失效。
為什麼 AI Agent 會打破 K8s 的安全假設？
傳統微服務在設計時，我們會定義好它能呼叫哪些 API、需要哪些權限額（Resource Limits）以及網路策略（Network Policy）。但 AI Agent 的行為是非決定性的（Non-deterministic），它會根據推理過程動態決定下一步要做什麼。
首先是動態依賴。Agent 可能這次只需要讀取日誌，下次則需要跨越網路遙測、資料庫指標與安全事件日誌。你無法預先寫死一個靜態的網路策略來涵蓋所有可能性。
其次是權限過大。一個能跨域診斷的 Agent 需要同時持有 LLM API Key、日誌系統權限、資料庫讀取權限等。如果將這些 Secrets 全部塞在一個長駐的 Pod 中，一旦該 Pod 被攻破，攻擊者將直接獲得整個基礎設施的最高權限，這就是所謂的「爆炸半徑」（Blast Radius）過大。
最後是資源不可預測。簡單的診斷可能只需 200MB 記憶體，但面對複雜的連鎖故障，Agent 可能會處理數十萬行日誌，瞬間衝到 4GB 記憶體，導致同個 Pod 內的其他任務因記憶體不足（OOM）而崩潰。
解決方案一：使用 Kubernetes Job 實現絕對隔離
為了避免上述問題，不要將 AI Agent 部署為 Deployment（長駐服務），而應將每一次的診斷任務視為一個獨立的 Kubernetes Job。
將任務 Job 化能帶來四大好處：資源隔離（每個任務有獨立的 CPU/記憶體限制）、故障隔離（單一任務崩潰不影響其他任務）、狀態乾淨（每次啟動都是全新容器，無快取污染）以及天然的審計追蹤（每個 Job 有獨立的日誌流與時間戳）。
實作上，後端 API 接收請求後，直接透過 K8s API 建立一個 Job，注入該次任務所需的元數據與短暫權限，任務完成後 Job 自動終止。
解決方案二：利用 Vault 管理短暫且分域的 Secrets
面對巨大的爆炸半徑，我們不能使用靜態的環境變數。建議導入 HashiCorp Vault（一個專業的機密管理工具），實作動態且短暫的憑證（Short-lived Credentials）。
具體做法是讓每個 Job 在啟動時使用 K8s Service Account 向 Vault 申請權限，僅在任務執行期間有效。同時，將不同域（如日誌、網路、LLM）的憑證路徑分開，這樣即使某個權限外流，也能快速追蹤是被哪個域的權限所影響。
解決方案三：建立四階段漸進式信任模型（Graduated Trust Model）
不能在第一天就給 AI Agent 生產環境的寫入權限，這在企業環境中是極其危險的。我們需要一個讓維運團隊逐步建立信任的框架：
第一階段：影子模式（Shadow Mode）。Agent 讀取生產數據並給出診斷結果，但結果不對外發布，僅供人類事後比對正確率。
第二階段：唯讀輔助（Read-Only Assist）。Agent 將診斷結果與推理鏈條呈現給值班工程師，由人類決定是否採納。
第三階段：有限修復（Limited Remediation）。在人類明確核准下，Agent 可執行低風險操作（例如重啟某個 Pod），權限由 K8s RBAC（基於角色的存取控制）嚴格限制。
第四階段：自主 L1（Autonomous L1）。Agent 自主處理常規事件，僅在信心水準低於門檻或超出權限範圍時才觸發人工升級。
每個階段的晉升必須基於數據（如診斷準確率 > 95%）而非時間表。
重新定義 AI Agent 的可觀測性（Observability）
傳統的請求/響應追蹤（Tracing）無法監控 AI Agent，因為它的核心是「假設 $\rightarrow$ 驗證 $\rightarrow$ 修復」的循環。我們需要關注以下新指標：
推理深度（Reasoning Depth）。追蹤 Agent 進行了多少次循環。如果次數過多仍未收斂，可能陷入推理迴圈，此時應觸發斷路器（Circuit Breaker）強制停止並交由人工處理。
LLM 成本歸因。AI 的推理成本極高，且複雜任務的成本可能是簡單任務的十倍。必須將 LLM Token 消耗量與 K8s 運算成本直接掛鉤到單次 Job ID 上，才能算出自動化的真正 ROI（投資報酬率）。
GitOps 的角色轉變。在 AI Agent 體系中，風險不在於程式碼，而是在於配置（Configuration）。當信任階段改變時，對應的 RBAC、Vault 策略與網路策略都會變動。使用 GitOps（如 ArgoCD）能確保這些權限變更經過 PR 審核且可追溯，避免有人在排錯時隨手開了最高權限卻忘記關閉。
總結給工程師的建議
如果你正準備在 K8s 上部署 AI Agent，請先審視你的安全模型是否基於「靜態依賴」、「單一域憑證」、「可預測資源」或「決定性路徑」這四個假設。如果是，請立刻將其拆解。
從 Job 隔離開始，用 Vault 管理短暫權限，並從影子模式逐步推進。讓數據決定權限的開放程度，而不是讓開發進度決定。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。