在目前的 AI 發展趨勢中，我們正從單純的聊天機器人轉向 Agentic AI（代理式 AI）。所謂的 AI Agent，是指能夠自主使用工具、呼叫 API、甚至讀寫程式碼來達成特定目標的系統。然而，這種「自主性」對工程師來說是一把雙面刃。
傳統應用程式的行為是確定性的，輸入 A 通常會得到 B。但 AI Agent 的行為是非確定性的，它可能會因為 Prompt Injection（提示詞注入，即惡意誘導 AI 執行非預期地執行指令）而產生邏輯劫持，或者在追求目標時產生幻覺，執行危險的指令。如果讓 AI Agent 直接在公司內部的正式環境中運行，一旦它被攻破或失控，可能會導致敏感 API Key 外洩，甚至對整個運算叢集造成毀滅性影響。
為了解決這個問題，東南亞超級 App Grab 開發了一套名為 Palana 的 Kubernetes 原生安全執行平台。這本質上是一個為 AI Agent 量身打造的隔離沙箱。
建立信任的基礎：強隔離與零信任架構
Grab 認為，面對不可預測的 AI 行為，不能依賴 AI 自身的自我約束，而必須在基礎設施層級建立硬性限制。Palana 採用了零信任模型（Zero Trust Model），將隔離作為信任的基本單位。
具體實作上，Palana 為每個 AI Agent 分配一個獨立的 Kubernetes Namespace（命名空間）。透過設定嚴格的 RBAC（基於角色的存取控制）和自定義的 Network Policies（網路策略），確保即便某個 Agent 被攻破，攻擊者也無法橫向移動到其他 Agent 或底層的運算叢集。此外，為了支援長時間運行的非同步工作流，平台還提供了持久化的本地儲存，讓 Agent 在容器重啟後仍能保有記憶狀態。
解決機密外洩：解耦金鑰管理
在開發傳統 App 時，我們習慣將 API Key 放在環境變數或掛載文件中。但對於 AI Agent 來說，這太危險了。因為 Agent 具有執行任意腳本的能力，一旦執行環境被入侵，所有高價值金鑰會立刻暴露。
Palana 採取了機密解耦的策略。真正的敏感金鑰（如 Git Token 或模型 API Key）儲存在 HashiCorp Vault 中，而 Agent 容器內拿到的僅僅是「虛擬佔位符（Placeholder Tokens）」。
當 Agent 發起 API 請求時，流量會經過一個中間代理（Proxy）。這個代理會攔截請求，驗證目的地是否合法，並在發出前動態地將虛擬佔位符替換為真實金鑰。這樣設計的結果是，真實的金鑰永遠不會出現在 Agent 的環境變數、記憶體或日誌文件中。
流量管控與外部終止機制
由於 AI Agent 必須與外部工具溝通才能發揮作用，出向流量（Egress）成了關鍵的安全控制點。Palana 將所有 HTTP/HTTPS 流量強制路由至 Envoy Proxy，並搭配 Open Policy Agent (OPA) 執行權限檢查。
透過中間人證書終端（MITM CA Termination）技術，代理伺服器可以即時解密並檢查流量標頭，確保請求符合規範，同時產生詳細的審計日誌。
更重要的一點是，如果一個 AI Agent 陷入死迴圈或被劫持，我們不能指望它會「自己停止」。因此，Palana 將控制權完全移至執行環境之外。平台提供了網路層級的 Kill Switch（緊急停止開關），可以直接從控制平面切斷網路連接，並由外部的 Reaper（回收機制）強制關閉閒置或異常的容器。
以基礎設施即程式碼（IaC）規模化
為了讓開發者能快速部署而不需要每次手動設定環境，Grab 將 AI Agent 定義為 Kubernetes 的 Custom Resource（自定義資源），並開發了專屬的 Kubernetes Operator。
這個 Operator 會自動處理命名空間、儲存空間、網路策略和入口路徑的配置。對開發者而言，他們只需要透過簡單的 UI 或 CLI 工具定義 Agent 需求；而對系統工程師而言，則可以使用標準的 Kubernetes 工具對數百個併發的 Agent 工作負載進行審計與生命週期管理。
總結
從 Palana 的設計可以看出，運行自主 AI Agent 的核心邏輯在於：不要信任 AI 的行為，而要信任由基礎設施強加的限制。透過 Kubernetes 的隔離能力、動態金鑰替換以及外部流量管控，企業才能在享受 AI 自動化生產力的同時，將安全風險控制在可接受的範圍內。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。