當 AI Agent 開始掌管基礎設施：為何我們需要超越 Prompt 的安全邊界

當我們開始賦予 AI Agent 權限，讓它直接觸碰生產環境的基礎設施時，一個根本性的安全挑戰隨之浮現。過去仰賴在 System Prompt 中設定的「行為準則」或「道德約束」，在面對複雜且高風險的維運任務時，顯得脆弱而不堪一擊。我的觀察是，真正的安全控制權必須下沉，從應用層的「指令」轉移到基礎設施層的「邊界」。這意味著，我們必須建立一個獨立於 LLM 之外、可驗證的控制層，透過網路隔離、最小權限原則與嚴格的 API 閘道來確保 Agent 的行為可控，否則無異於將系統的鑰匙交給一個行為無法完全預測的實體。

當自動化維運遇上大型語言模型

在軟體工程領域，特別是網站可靠性工程（SRE）與平台工程團隊，日常工作充滿了大量重複性的調查與操作。例如，開發者可能會在 Slack 頻道中詢問：「某個服務的 Pod 狀態正常嗎？」、「請幫我拉一下昨晚服務 X 的錯誤日誌。」這些請求雖然不複雜，但頻繁地中斷了 SRE 團隊的專注，累積起來成為可觀的時間成本。

為了解決這個痛點，導入 AI Agent 進行自動化處理，成為一個極具吸引力的選項。日本醫療科技公司 Ubie 的工程團隊便開發了一個名為「Infra Agent」的內部工具，它能透過 Slack 監聽特定請求，理解人類的自然語言意圖，並自主規劃、執行一系列的基礎設施查詢指令，例如使用 kubectl 檢查 Kubernetes 叢集狀態，或透過 gcloud 調用雲端平台 API。這個 Agent 的目標，是將 SRE 從日常瑣事中解放出來。

然而，當 Agent 手中握有 kubectl 的權力時，一個嚴肅的問題擺在眼前：我們該如何信任它？

為什麼單靠 System Prompt 無法保障基礎設施安全？

許多 Agent 框架的初始設計，傾向於在 System Prompt 中對 Agent 的行為進行約束。例如，我們可能會寫下這樣的指令：「你是一個 SRE 助理，你的任務是協助查詢，絕不可以執行任何刪除、修改或關閉等破壞性操作。」這種方式，本質上是一種「君子協定」，它依賴 LLM 對指令的理解與遵循。

然而，這種基於 Prompt 的安全模型存在幾個致命缺陷：

• 提示詞注入（Prompt Injection）：惡意或無意的使用者輸入，可能繞過或覆寫原始的系統指令，誘使 Agent 執行非預期的危險操作。關於這類攻擊的研究，例如《Ignore Previous Prompt: Attack Techniques For Language Models》，已經證明了其可行性與危險性。
• 模型行為的不可預測性：大型語言模型本質上是機率性的。即使在相同的 Prompt 下，其生成的回應也並非 100% 確定。在複雜的推理鏈中，模型可能會「誤解」指令，或在多個工具之間做出錯誤的組合，導致災難性後果。
• 權限過於寬鬆：如果 Agent 運行的環境本身就擁有過高的權限，那麼無論 Prompt 寫得多麼嚴謹，一旦防線被突破，其破壞潛力將是巨大的。

將攸關系統生死的基礎設施，建立在一個可被輕易操弄且行為不完全確定的模型之上，這在任何嚴謹的工程文化中都是無法接受的。

Ubie 如何將「意圖」與「執行」徹底分離？

Ubie 團隊的洞見在於，他們意識到安全邊界不應該設在 Agent 的「大腦」（LLM）中，而應該設在 Agent 的「手腳」（執行工具的環境）上。他們設計了一個將「意圖生成」與「指令執行」徹底分離的架構。

真正的安全控制，不在於教導 Agent 什麼不該做，而在於從根本上讓它「沒有能力」去做不該做的事。

這個架構的核心是一個獨立的「工具伺服器」（Tool Server）。整個工作流程如下：

1. 接收請求：Infra Agent 在 Slack 中接收到開發者的自然語言請求。
2. 規劃意圖：Agent 內部的 LLM 進行思考與規劃，判斷需要執行哪些查詢指令來回應這個請求。例如，它可能會決定需要執行 kubectl get pods -n my-namespace。
3. 發送意圖：Agent 並不直接執行這個指令。相反地，它將這個「意圖」（包含要執行的指令與參數）發送到一個獨立的工具伺服器。
4. 驗證與執行：工具伺服器是一個傳統的、非 LLM 的應用程式。它內部有一份非常嚴格的「允許清單」（Allowlist），只允許預先定義好的、唯讀的、安全的指令通過。所有不在清單上的指令（例如 kubectl delete）都會被直接拒絕。
5. 最小權限原則：這個工具伺服器本身運行在一個專屬的 Google Cloud 服務帳號下，該帳號被授予了完成允許清單中所有任務所需的最小權限。它甚至沒有權限去執行任何修改或刪除操作。
6. 回傳結果：指令執行後，結果會回傳給 Agent，由 Agent 整理成人類可讀的語言，最終在 Slack 中回應。

在這個設計中，網路邊界成為了真正的安全屏障。LLM Agent 所在的環境與能夠實際操作基礎設施的工具伺服器是網路隔離的。Agent 唯一能做的，就是向工具伺服器提出「請求」，而執行的最終裁決權與能力，則牢牢掌握在規則明確、行為確定的工具伺服器手中。這套方法論，與 Google 在 BeyondCorp 白皮書中所倡導的零信任網路架構精神不謀而合。

如何從「自律」轉向「他律」，確保 AI Agent 的基礎設施安全？

Ubie 的案例為我們揭示了一個重要趨勢：當 AI Agent 的應用從無狀態的內容生成，走向有狀態、高風險的系統操作時，我們的安全思維也必須跟著演進。我們需要從寄望 Agent 「自律」，轉向建立強健的「他律」機制。

這意味著我們需要設計一個可驗證的基礎設施控制層（Verifiable Control Plane）。這個控制層獨立於 AI 的認知核心，專門負責權限驗證、指令過濾與安全審計。無論上層的 Agent 如何思考、如何規劃，它最終的行動都必須通過這個狹窄、透明且嚴格控管的閘口。這種模式讓我們能夠在享受 AI 帶來的高效率的同時，將潛在風險控制在可接受的範圍內。隨著 LangChain、AutoGen 等 Agent 框架的成熟，這類安全架構的設計與實踐，將成為所有希望將 AI 導入核心業務流程的團隊，都必須嚴肅面對的課題。

延伸閱讀

• Ubie 團隊關於 Infra Agent 的原始技術分享（日文）
• 《Understanding the Security of Large Language Model-based Agents》：一篇關於 LLM Agent 安全性的學術研究
• AWS Identity and Access Management (IAM) 的最佳實踐

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。