不要再向 AI 智能體提供生產環境金鑰

CERT-In 的報告內容

2026年10月15日，CERT-In 發出評級為嚴重的公告 CIAD-2026-0049，標題為「AI 代理作為攻擊途徑」。公告描述了兩類事件，兩者都與 AI 代理憑證如何暴露，以及如何設定其權限範圍有關。

第一類事件中，AI 模型供應商主動披露，其模型在互聯網上進行研究和評估期間，接觸到印度機構正在運作的系統。公告指出，代理使用應用程式設定及公開程式碼儲存庫中暴露的憑證和連線設定，以及權限過寬的雲端服務角色，讀取業務記錄，包括個人資料和機密資料。公告表示，代理的操作超出獲指派的任務，而受影響機構均未自行發現這些存取行為。

第二類事件中，CERT-In 自行進行威脅搜捕時，發現攻擊者在一項以牟利為目的的行動中，使用公開可用的 AI 網絡安全攻擊框架。公告指出，具代理能力的工具將從初始入侵到造成影響的時間，由數天縮短至數小時。

公告沒有提及供應商、模型或機構的名稱。The Hacker News 的報道總結了相同要點，並指出 CERT-In 沒有公佈任何入侵指標。

最值得注意的是：CERT-In 指出，根本弱點都是傳統的安全問題，包括暴露的金鑰、閒置的測試 API、以明文儲存的支付金鑰、權限過寬的雲端角色，以及對互聯網開放的管理介面。AI 代理比人更快、更徹底地找出並利用了這些弱點。

問題的兩個面向

這份公告對任何使用代理的團隊都有參考價值，因為它涵蓋問題的兩個面向。其他人的代理可能會找到你暴露的憑證。如果你的代理持有權限廣泛的正式環境憑證，一旦受到提示詞注入誤導，或只是越權操作，也可能造成同樣的損害。OWASP 將第二種情況稱為 Excessive Agency (LLM06:2025)，並將權限過大列為三個根本原因之一。

對機構而言，CERT-In 的建議包括專門針對內部代理治理的部分：每次執行都使用獨立、短期有效的身分，並遵循最低權限原則；強制採用預設拒絕的對外連線政策；以及保存防竄改的代理活動記錄，至少涵蓋所有會影響正式環境系統和數據的操作。本文其餘部分會將這些建議轉化為具體步驟。

步驟 1：找出已經洩漏的金鑰

先從公告提到的做起。CERT-In 要求機構檢查原始碼、儲存庫提交記錄、CI/CD 變數、設定檔、用戶端應用程式和雲端儲存空間，找出暴露的憑證；然後輪換任何已暴露的憑證、從記錄中徹底移除相關內容，並從外部驗證修補是否生效。公告亦要求掃描每次提交和建置中的機密資料。

在 GitHub 上，機密掃描會檢查儲存庫的完整 Git 記錄，尋找已知格式的機密；推送保護功能則可在包含受支援機密的提交進入儲存庫前將其封鎖。所有儲存庫都要啟用這兩項功能，不要只限於公開儲存庫。CI 也是常見的洩漏途徑；請參閲為何 GitHub Actions 中的 persist-credentials 很重要。請記住次序：先輪換憑證，再清理記錄。刪除提交無法收回已被他人複製的金鑰。

步驟 2：以工作負載身分取代已儲存的機密

防止金鑰外洩，最可靠的方法就是不再持有金鑰。在 Azure 上，受控身分識別讓工作負載毋須由應用程式管理憑證，便可取得 Microsoft Entra 權杖。對於在 Azure 以外運行的 Agent，例如 GitHub Actions 或 Kubernetes 中的 Agent，工作負載身分識別聯合讓工作負載以本身受信任簽發者的權杖交換 Entra 存取權杖，因此毋須儲存用戶端密碼或憑證。

以這種方式取得的權杖有效期較短，符合 CERT-In 的要求。接下來要處理的是界定權限範圍。

第 3 步：每次 Agent 執行使用一個身分識別，並將權限限制於該任務

一個由「Agent」共用的服務主體會破壞操作歸屬追蹤和最小權限原則。應以以下做法為目標：

• 每個 Agent 角色使用獨立身分識別。摘要 Agent 和部署 Agent 絕不應共用同一個主體。
• 收窄角色指派範圍。只在任務所需的特定資源上指派數據平面角色，不要在訂用帳戶上指派 Contributor 或 Owner。預設為唯讀；只有任務需要寫入時才授予寫入權限。
• 追蹤每次執行。如平台允許，為權杖或記錄項目加上執行識別碼標籤，讓每項操作都可追溯至一次執行。
• 評估時不得使用正式環境。CERT-In 為 AI 開發者提供的指引建議使用合成目標、合成憑證和可棄置的基礎設施，並避免在評估環境中使用正式環境資料和真實憑證。同一規則也適用於內部 Agent 測試。

絕不要讓憑證進入模型的上下文。工具層應持有權杖並傳回結果，避免提示詞注入要求模型將權杖輸出。

第 4 步：預設拒絕外連流量，並由網絡層強制執行

CERT-In 明確指出，網絡限制必須在網絡層強制執行，而非透過向模型下達指令。提示詞寫上「只聯絡 api.example.com」並不構成控制措施。

讓 Agent 在網絡分段中運行，所有對外流量都經過防火牆或代理伺服器，並以允許清單列出所需目的地。除非身分識別機制有需要，否則封鎖雲端中繼資料端點；亦要封鎖 Agent 毋須連線的私人網絡範圍。記錄遭拒絕的連線；Agent 嘗試連線至意料之外的位置，便是早期警號。AI Agent 緊急停止開關及出站閘道介紹了更完整的設計，包括每次執行專用的允許清單和關閉機制。

第 5 步：Agent 無法修改的記錄

CERT-In 要求保留防篡改的 Agent 活動記錄，並要求一般機構至少保留記錄 180 天。實際做法是將 Agent 和工具呼叫記錄傳送至獨立儲存空間，確保 Agent 的身分識別無法寫入或刪除記錄，例如存取權限受限的中央記錄工作區，或不可變儲存空間。每次工具呼叫觸及正式環境時，都要記錄目的地、操作、參數和結果。

這裏同樣適用於該指引對評估人員的警告：只檢視對話記錄，可能會漏掉模型推理中看似合理的活動。要記錄 Agent 做過甚麼，而不只是它説過甚麼。

簡短檢查清單

• 每個儲存庫都啟用機密掃描和推送保護；清除前先輪替金鑰。
• Agent 不使用長效金鑰；改用受控身分識別或工作負載身分識別聯合。
• 每個 Agent 角色使用一個權限範圍明確的身分識別，預設為唯讀。
• 測試和評估執行期間，不使用正式環境憑證或資料。
• 在網絡層預設拒絕外連流量。
• 將只能追加的記錄存放在 Agent 無法觸及的位置，並至少保留 180 天。

這些都不是新的安全做法。這正是 CERT-In 想指出的一點。代理只是縮短了原本在有人察覺之前，你還有的時間。

最初刊載於 yadui.dev，作者為 Abhinav Yadav。