在現代的軟體開發流程中，我們已經習慣了 CI/CD（持續整合與持續部署）這種決定論的自動化。簡單來說，決定論（Deterministic）是指只要輸入相同，輸出的結果永遠一致，例如定義好如果測試失敗就停止部署。然而，隨著 AI Agent（人工智慧代理）的引入，自動化進入了 Agentic Workflow（代理工作流）時代。
AI Agent 與傳統腳本的不同之處在於它具有推理能力，能根據意圖做出決策並執行任務。但這也帶來了一個核心問題：AI 是非決定性的（Non-deterministic）。它會處理不可信的輸入，並在執行時自主行動，這對安全性而言是一個巨大的挑戰。如果一個 AI Agent 擁有直接修改程式碼或存取伺服器的權限，一旦遭遇 Prompt Injection（提示詞注入攻擊，即透過惡意輸入誘導 AI 執行非預期指令），可能會導致權限提升或機密外洩。
為了將 AI Agent 安全地導入 GitHub Actions 等生產環境，GitHub 採取了一套深度防禦（Defense-in-Depth）的架構，其核心邏輯可以拆解為以下三個維度。
第一是環境隔離與權限最小化。AI Agent 不應該在具有高權限的環境中運行，因此 GitHub 將其放置在沙箱化（Sandboxed）且臨時的（Ephemeral）環境中。這意味著 Agent 每次執行完畢後環境就會被銷毀，防止攻擊者在系統中建立持久化的後門。同時，Agent 預設處於唯讀模式，無法直接修改儲存庫。
第二是受控的輸出與執行路徑。這是最關鍵的實務設計：AI Agent 被禁止直接提交程式碼（Commit）。任何 AI 建議的變更必須透過受控的輸出管道，例如建立一個 Pull Request（合併請求）或在 Issue 中留下評論。這樣做將 AI 的角色從執行者轉變為提案者，將最終的審核權交還給人類工程師，確保所有變更都經過透明的審查且符合公司政策。
第三是機密資訊的保護與網路限制。在共享的執行環境中，環境變數或設定檔常包含敏感的 API Token。為了防止 AI 被誘導將這些機密外洩，GitHub 採取了兩項措施：一是限制網路出口（Network Egress），防止 Agent 將資料傳送到未經授權的外部伺服器；二是將敏感憑證移出 Agent 的邊界，透過受信任的代理伺服器或閘道器（Gateways）來處理，讓 AI 永遠接觸不到真正的金鑰。
最後，為了確保出錯時可以追溯，可觀測性（Observability）被視為安全基石。系統會詳細記錄所有跨越信任邊界的活動，包括網路流量、與模型的對話紀錄以及呼叫了哪些工具。這不僅是為了除錯，更是為了在發生安全事件時能進行數位鑑識（Forensic Analysis），分析 AI 是在哪個環節被誤導或失效的。
總結來說，將 AI 引入 CI/CD 的關鍵不在於追求完全的自動化，而是在於建立一套強大的護欄（Guardrails）。透過隔離環境、限制寫入權限、隔離機密資訊以及完整的日誌追蹤，我們才能在享受 AI 提升生產力的同時，不會讓自動化流程變成系統的安全漏洞。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。