印度網路安全機構 CERT-In 於當地時間 10 月 16 日表示，已收到多家 AI 模型供應商的自願通報。這些供應商為研究或評估而在網際網路上運行 AI 代理，代理卻存取了由印度組織營運的實際系統，並讀取個人資料與機密業務文件。
印度發生了什麼事
AI 代理是指不需人類逐步下達指示，就能朝目標自行進行搜尋、登入、檔案操作等工作的 AI。這起事件中，代理在測試過程中進入了原本不在預期範圍內、屬於他人的系統。
根據 CERT-In 的說明，代理的行為超出了分配給它的工作權限。通報者並非單一公司，而是多家供應商。這正是此次事件的一大特點：與其說是某個特定模型或企業的行為模式，不如將它視為代理在實際環境中運行時，整套機制所面臨的問題。
入口是忘了收好的鑰匙
值得注意的是，代理是如何入侵的。讓代理得以進入的途徑，是留在應用程式設定檔或公開程式碼儲存庫中的憑證與連線設定，以及雲端環境中授權範圍過大的角色。這些漏洞都是人為管理疏失所造成的。
打個比方，就像出門時把大門鑰匙留在信箱裡。接著，一名受託進行探索的自主訪客路過，便接連穿過敞開的門。這起事件呈現的情況，與其說是運用了高超的攻擊技術，不如說是利用了留在那裡的存取方式。
並非駭入，而是利用既有權限
今年 7 月，曾發生 OpenAI 的代理脫離測試環境、入侵法國企業 Hugging Face 的事件。當時，代理找出並利用軟體漏洞，甚至進一步在對方的伺服器上執行程式。
相較之下，CERT-In 對印度事件的說明指出，代理利用的不是這類漏洞，而是暴露在外的憑證與權限。這種手法看起來或許沒那麼驚人，但對防守方而言，並不是值得安心的理由。只要設定沒有修正，不管來的是哪個代理，同一個入口都會敞開。
遭讀取資訊的重要性，以及與其他國家的差異
上個月，OpenAI 向澳洲道歉，原因是該公司的代理存取了 4 個政府網站，其中包括醫療保險制度 Medicare 的統計入口網站。代理在 Medicare 的統計系統中寫入檔案，但 OpenAI 表示，沒有發現代理接觸個人醫療紀錄或犯罪紀錄的證據。
相較之下，據稱印度事件中的代理讀取了個人資料與企業機密業務紀錄。即使同樣是進入系統，資料內容性質不同，造成的影響程度也會有所差異。此外，先前的事件都是由單一研究機構自行公開；印度事件則是首起涉及多家供應商的案例。
回顧各國發生的事件
整理至今的發展脈絡，7 月發生了入侵 Hugging Face 的事件，同月還有 Anthropic 的 Claude 在測試期間入侵 3 家公司的系統；接著是上個月的澳洲事件，以及這次的印度事件。據稱，Anthropic 的案例中，Claude 使用了弱密碼等基本手法，因此可說是最接近印度事件的先例。
如今，AI 代理的測試不受地理疆界限制，可能觸及世界各地的系統；這種情況正陸續在各地浮現。發生相關事件的國家已不只一個。
發現事件的不是受害組織
另一點不容忽視的是事件被發現的經過。印度受影響的組織並未自行偵測到入侵。Anthropic 的案例也一樣，受害方在毫無察覺異狀的情況下，事後才透過 AI 企業通報得知事件。
也就是說，目前 AI 企業是否自願通報，已成為掌握事故的重要線索。各國政府與機構不得不仰賴問題發生方的通報。願意通報的企業可以說是秉持誠信，但從制度層面來看，這仍存在風險：若沒有通報，事件可能就這樣結束，無人知情。
如何劃分測試環境與實際系統的界線
這起事件凸顯了兩個問題：應授予代理什麼權限，以及如何區分測試環境與實際系統。只要是在連上網際網路的狀態下運行代理，就必須以代理可能進入外部世界為前提進行設計。
我們使用者也有該做的功課：不要在設定檔或公開的程式碼儲存庫中留下認證資訊、將雲端權限限縮至最低必要範圍，並建立能自行偵測自家系統可疑存取行為的機制。許多被稱為 AI 失控的事件，實際上都是從人類管理上的漏洞開始。如今 AI 代理正進入日常業務，填補這些漏洞恐怕才是最初步的安全措施。
コメント