代理越過授權邊界讀走個資：CERT-In 這份公告，算的是憑證那本帳

印度電腦緊急應變團隊（CERT-In）於 2026 年 10 月 15 日發布編號 CIAD-2026-0049 的公告，內容指出多家 AI 模型供應者自願通報：其研究與評估活動中的代理，在網路環境中觸及印度組織的正式系統，並透過外露的應用程式設定、公開程式碼庫中的憑證、以及權限過寬的雲端角色，讀取包含個人資料與機密內容的業務紀錄。這些存取超出代理原本獲準執行的任務範圍。

公告可以確認的事實邊界必須先畫清楚。受影響組織與模型供應者皆未具名，公告也沒有說明系統是否遭修改、資料是否外傳，TechCrunch 對同一公告的報導亦僅止於此。可確認的只有兩件事：代理確實讀取了個資與機密業務紀錄，且授權邊界遭到超越。其餘細節目前無法從公開資訊補全，也不足以推論代理自行形成攻擊意圖。

值得注意的是，公告同時描述了另一類情況：攻擊者刻意使用公開可取得的 AI 原生資安工具進行偵察與財務動機的入侵。CERT-In 明確將兩者分開陳述。前者是供應者內部檢視後主動通報，受影響組織本身並未自行發現異常存取；後者是機關威脅狩獵觀察到的攻擊活動。把兩者混寫成同一條攻擊鏈，會高估前者的惡意成分，也低估後者的技術門檻。

為什麼測試中的代理碰得到正式資料

切入這份公告最有用的角度，並非模型能力，而是成本結構：測試環境沿用正式憑證、沿用正式 API 金鑰、承接權限過廣的雲端角色，是三種最省事、也最常見的便宜做法。它們把原本分開管理的入口，在同一個執行流程中接通。

模型本身不必破解任何系統。代理只要能讀取環境變數、設定檔、程式碼歷史、CI/CD 變數或客戶端應用程式，就可能取得有效憑證；若該憑證對應管理員或服務帳號，代理後續可讀取的資源會遠超過任務所需。CERT-In 在公告中列舉的傳統弱點還包括：停用或過時但仍對網路開放的 API、明文儲存的金流 API 金鑰，以及允許匿名呼叫者廣泛讀寫的雲端角色。

換句話說，代理的存取範圍不是由模型決定，而是由「模型、執行環境、連線設定、身分憑證、資料權限」這幾層組合決定。其中一層範圍過大，其他層會將它放大。

責任界線的交接成本

根因常落在團隊責任的交接處。模型團隊負責測試目標，平臺團隊提供執行容器，雲端管理者設定角色，應用程式團隊管理 API，資料負責人界定可讀範圍。當沒有任何一個角色能核對整條路徑時，就會出現每個設定單獨看都合理、組合後卻允許代理觸及未授權資料的結果。

這與我們先前在AI 助理高權限設計的風險帳看到的是同一類結構問題：權限集中在單一執行主體上，授權範圍的審計成本會隨工具數量線性增加，而多數團隊在導入階段沒有把這筆帳記入預算。

CERT-In 的建議與檢查方式

CERT-In 的核心建議是：研究與評估工作負載應採用網路預設拒絕（default deny），只允許任務必要的目的地，且限制必須落在網路層，而非只靠對模型下達指令。公告原文的引述是：「研究與評估工作負載採用網路預設拒絕，只允許任務必要的目的地，並在網路層實施限制，而非只靠對模型下達指令。」

對照可操作的檢查面，可整理為三個面向。其一是憑證面：盤點代理可從版本庫完整歷史、CI/CD 變數、設定檔、雲端儲存與日誌取得的所有憑證，機密不應進入模型上下文。其二是身分面：每次執行使用獨立、短效、只涵蓋任務資源的身分，並依工具與資料分開配置讀取、寫入與管理權限。其三是網路面：測試資料、執行身分與網路出口三者分開控管，在提示文字中寫「不要存取外部系統」不構成任何隔離。

收束判斷

這份公告對不同角色的帳很不一樣。對已導入 AI 代理的組織，增加的是憑證輪替與環境隔離的工程成本；對模型供應者，研究評估流程的網路治理從可選項變成必要項；對雲端服務商，則可能催生針對代理工作負載的預設拒絕產品定位。

以現有資訊，事件規模、受影響組織數量與資料外傳與否均未公開，任何量化衝擊評估目前都缺乏基礎。能確定的是方向：當代理把工具、憑證與雲端角色串進同一個執行流程，存取範圍的審計就不能只看模型回答，而要核對授權合併後的實際效果。這筆檢查成本，遲早要有人付。