406 位科學家連署要 AI 氣隙隔離：斷網與否，是最粗糙的問法

連署鎖定的是具網路攻擊能力的模型，主張開發、部署與測試階段採高保障隔離，初期以氣隙為預設；把這份倡議翻成產品端可執行的權限分層，比爭論 AI 該不該上網更有用。

「406 位科學家要求 AI 斷網」，十月裡這個說法在社羣平臺流傳時，最常被讀成所有 AI 服務都應該離線。先把範圍說清楚：這封公開信針對的是具網路攻擊能力的模型，主張在開發、部署與測試階段採高保障隔離，並在初期以氣隙（air gap）為預設。它沒有要求所有 AI 永久斷網，目前也不是任何司法管轄區的法律。

對一般使用者來說，這封信短期內不會改變任何產品的行為。對開發與部署 AI 的團隊來說，它丟出的題目具體得多：模型連上網路之後，能動用哪些工具與憑證、碰得到哪些主機與資料、出錯時由誰收手。這些問題的答案，才決定一項任務需要哪一層連線。

連署說了什麼，沒有說什麼

公開信提出三項建議。第一，具網路攻擊能力的 AI 模型在開發、部署與測試時採高保障隔離，初期以氣隙為預設。第二，由政府、AI 與資安專家共同組成國際機構，制定較高外部存取的隔離實務，並追蹤隔離失敗事件。第三，隔離失效事件應先通報，之後逐步公開資訊，以利學習與問責。

「具網路攻擊能力」是整份倡議的範圍邊界。它指向可能尋找漏洞、執行攻擊或操作網路系統的能力；一般問答或搜尋服務，不會自動落在同一個風險級別。不過公開信沒有列出完整的測量門檻，團隊仍須依模型能力與部署方式自行判讀。

406 這個數字說明的是參與規模，無法證明哪一種隔離設計比較有效。信裡也沒有氣隙、白名單與沙箱的實測比較；機構怎麼組成、通報怎麼定義、執行權限放在誰手上，都還是待討論的空白。把它當預防性倡議來讀，比當定論來讀，更貼近它的性質。

風險來自組合，能力只是其中一項

模型能力本身決定不了風險。真正的變數是組合：模型能做到什麼、可呼叫哪些工具、網路出口開到哪裡、持有什麼憑證、資料讀寫權給了多少。只記錄「能不能上網」，會漏掉它連線之後能做的事，以及這些操作影響得到哪些系統。

風險是沿著工具一路墊高的。沒有外部工具的問答模型，影響多停留在輸出內容；接上搜尋或資料庫，系統就能讀取外部資訊；再接上程式執行、雲端管理或寫入 API，它就可能修改檔案、建立資源或觸發流程。

AI 代理（AI agent）把這條路走得更遠。它能按任務規劃步驟、呼叫工具並接收結果；一旦受到提示注入或錯誤輸出的影響，又握有超出任務所需的權限，錯誤就可能轉成外部操作。OWASP 對此有專門命名：「過度代理權限」，成因包括功能過多、權限過大或自主程度過高。

沙箱是常見的隔離機制，但名稱本身不保證防護完整。要檢查的是它能不能擋住未授權連線、檔案存取與主機操作，以及憑證怎麼管理。若代理能透過其他工具或服務帳號存取內部資源，只封住瀏覽器出口，這道防線幾乎等於沒有。

這裡不需要假設模型有自主意圖。錯誤指令、外部內容或不穩定輸出，任何一項都足以在高權限環境釀成越權。模型輸出時好時壞並非假設情境，先前解釋過DeepSeek 回應時好時壞的技術成因，那類不穩定一旦碰上高權限工具，後果就從答錯問題變成動錯系統。

事故之後的檢討，常停在「沙箱設定錯了」或「這個模型版本不穩定」。單一設定與單一版本都只是症狀。更該追問的是：為什麼當初讓一個工具同時握有讀取、執行與寫入三種權限，而沒有人在設計階段把它拆開？原因多半不在模型，而在權限分配的流程：誰決定給哪個工具多大的存取範圍、這個決定有沒有留下紀錄、需求變動時是否重新審視。公開信對近期隔離失敗事件的判讀，也是把兩端並列：

模型行為與系統防護要一起處理，這句話對產品團隊的實際意義在於：對齊研究是模型廠的課題，沙箱與權限設計卻是每個部署現場自己的責任。

三層連線，各自接得住的任務

把連線設計分成三層，判斷會具體許多。

完全隔離適合高風險能力評估、未公開模型的測試，以及含敏感資料的封閉作業。它的代價是即時搜尋與外部服務整合大幅受限，而資料匯入匯出、人員操作與內部網路，仍然需要另外管理。氣隙封得住對外路徑，封不住內部作業的疏忽。

限制出口、採目的地白名單，適合只需要查核指定資料源、呼叫少數核準 API 的任務。它能保留特定功能又縮小外連範圍，但要留意一點：白名單若只比對網域，未必限制了 API 操作、帳號身分或可讀資料。同一個網域底下的服務能做的事，差異可以很大。

一般網際網路存取留給需要廣泛搜尋、整合多種外部服務，且後果輕微、經風險核準的任務。彈性最高，監控與事件處理的負擔也最重，外部內容與連線對象的增加，都會擴大提示注入的暴露面。

挑選原則可以用兩句話收攏：任務越依賴即時外部資料與實際操作，連線需求越高；可觸及的資源越多、失誤的後果越大，就越要縮小工具、身分與目的地的範圍。

使用者與產品團隊各拿到什麼

一般使用者拿到的是一組提問的語彙。下次讀到「AI 助理可代你操作某項服務」這類功能宣傳，可以接著問：它用哪個身分登入、能讀哪些資料、高影響動作有沒有人核準。答不出這些問題的功能，風險等級就該自己往上加一級。

產品團隊拿到的是盤點順序，而且應該做在連線之前：模型可使用的工具清單、每個工具持有的憑證、可連線的目的地、可讀寫的資料範圍、高影響動作的核準者是誰。這套思路與供應鏈安全的驗收相通，概念上接近收到軟體物料清單時的欄位核對：文件寫的與實際交付的對不上，後面的防護都建立在假設上。

至於氣隙什麼時候該用，公開信給的答案針對模型廠與高風險測試場景。多數產品團隊的日常，會落在白名單與分項權限這一層，而現實是，不少團隊連這一層的文件都還沒有。

可依序核對的訊號

這封信的後續，可以按順序盯幾個點。先看國際機構的籌備訊息：誰實際參與、外部存取標準何時出草案。再看通報定義：什麼樣的情況算隔離失效、誰有義務通報、多久之後公開。最後看廠商端的文件變化：部署指南是否出現權限矩陣、氣隙選項是否從附加方案變成預設。

產品端也有跡可循。AI 功能的權限設定頁，若從單一的「允許上網」開關，細化成按目的地與按工具的分項控制，代表這套分層思路開始進入產品設計，而不停留在倡議文件裡。

斷網與否是二選一，分層才是日常。這封信把最嚴格的隔離留給最危險的模型，把其餘的判斷還給每個部署現場。可檢驗的進度會出現在通報機制與文件細節裡；連署人數只是起點，後續那兩件事做得好不好，才是判斷這份倡議有沒有用的地方。

資料來源：本站編輯參考 APPI News〈AI 網路權限完整指南：模型連網的風險與判準〉（作者：張饒輝 Lightman Chang）改寫而成，原文出處；原文文字內容採 CC BY 4.0 授權。