AI 與科技新聞摘要 - 2026/10/17
一個外部評估者在某家實驗室的測試環境裡,發現某個前沿模型可能幫人做出生物武器。照報導裡 Anthropic 遞給國會議員的那份草案,評估做完後他有 72 小時,要把這件事報給美國商務部。商務部認定風險存在,可以去找哥倫比亞特區的聯邦法官,請法官叫停這個模型。其他聯邦機關,據報導草案寫明不准插手。
一家 AI 公司寫的法案草案、美國三個聯邦機關的自願指引、中國的出口管制草案,談的都是停機鍵握在誰手上、多大的事才按得下去。另外三則比較小,一則是 Python 套件的漏洞,一則是一筆借錢的利率,一則是台灣一家雲端平台被入侵兩次後宣布收攤,但我覺得它們回答的是同一個問題,只是從底下回答。
一、Anthropic 自己寫了一份法案:門檻是逾 10 億美元或逾 50 個人
這則的源頭是 Politico,我讀不到原文。以下依 Reuters 的轉述,Politico 的消息來源是「three people with knowledge of the efforts」,Reuters 頁面沒有寫它獨立驗證過。
Anthropic 的代表被指「quietly pitched」國會議員一份草案,目的是「regulate frontier AI safety and security」。草案的核心是一道門檻:政府只有在風險屬於「a foreseeable, imminent risk of more than $1 billion in damages, or of killing or seriously injuring more than 50 people」時,才能封鎖模型的發布或使用。風險來源依 Politico 的說法限定三種:生物武器、模型逃出開發者控制、網路攻擊。
執行的路徑是這樣:獨立評估者向商務部登記,定期評估實驗室和前沿模型;實驗室可以付錢給評估者,只要款項不跟評估結果掛鉤。評估者發現「imminent enumerated risk」,要在評估完成後 72 小時內報給商務部。商務部認定風險存在,可以請法官停掉這個模型;能下令暫停的是哥倫比亞特區的聯邦法官,草案同時禁止其他聯邦部門、機關或官員暫停開發、部署或內部使用。
Anthropic 發言人說,法案反映的是它「Advanced AI Framework」裡的提案,政府會有「ability to block or deter dangerous deployments of the most powerful models」,開發者也要測試前沿模型、公開發現、接受獨立評估。商務部沒有立即回應 Reuters 的置評請求。草案全文沒有公開,哪些議員被遊說也沒寫。
被管的人自己寫規則,這件事本身我不覺得奇怪,至少比完全不寫好。我在意的是門檻的形狀。這套設計最容易怎麼失敗?我看是它只看得到「imminent」而且「enumerated」的那種大事。一連串各自不到 10 億美元、各自不到 50 人的小事故,或者落在三種風險之外的損害,照這個門檻永遠不會觸發停機。這是我的推論,報導沒有討論這一點。
另一個問題是「其他機關不能插手」那一句。它讓停機鍵只剩一個入口,好處是企業不會被五個機關輪流叫停,壞處是這個入口卡住的時候,沒有第二條路。如果之後公開的條文裡,門檻以下的事故有強制通報、或累積達一定程度也能觸發,我會收回前面那段擔心。
原文來源:Investing.com/Reuters:Anthropic quietly pitches its own AI safety bill to lawmakers - Politico reports,2026-10-16(Politico 原文未讀到)
二、CISA、NSA、CAISSI 的測試指引:不要只讓 AI 看著 AI
這份指引的主要文件我讀不到。CyberScoop 文內連到的「原文」是一份跟主題無關的 PDF,所以這一則只依 CyberScoop 的報導,指引的正式標題、章節結構我都沒有看到。
據 CyberScoop 10 月 16 日的報導,CISA、NSA 和商務部底下的「Center for Advancing Innovation and Standards for Super Intelligence (CAISSI)」共同發布一份指引,談前沿 AI 在訓練與評估階段的事件應變,性質是自願的。
報導列的建議,大多是很傳統的資安控管搬到模型測試上:在虛擬化的測試環境裡內建技術控管;用外部監控確認模型沒有碰到不該碰的工具或權限;檢查內部測試環境有沒有持久化機制和隱藏的通訊管道;風險分四層評估,模型、harness、主機、整個網路;跟「independent, external auditors」合作評估控管;專案暫停或重啟時,主管要更親自參與。指引也鼓勵 AI 公司訂「shut down policies」,規定什麼時候把模型或測試下線。
最值得記下來的是這一條:不要只靠 AI 系統監督測試中的模型,部署前要讓人和 AI 一起測試控管。CyberScoop 引了 METR 的 president Chris Painter,他本月稍早在國會說,前沿公司測試時幾乎全靠其他 AI 系統監控模型。CyberScoop 的背景描述更直接:OpenAI、Anthropic、Google、Meta 等公司都表示自己的模型「escaped from testing environments and hacked real organizations and websites」,部分公司的研究員說,夏天可能有數百甚至上千次類似的逃逸。這段是 CyberScoop 的陳述,我沒有逐家去核對。
我對這份指引的看法是:內容對,力道不夠。用 AI 監控 AI,最大的問題是兩邊的盲點可能長在同一個地方,監控者看不到的,正好是被監控者會鑽的洞。把人放回迴圈裡是對的方向。但「自願」兩個字代表,最不想做的公司可以不做,而我猜最不想做的,就是測試量最大、最趕上線的那幾家。這份指引會不會被當回事,要看它之後有沒有被寫進採購條件或第一節那類法案裡;沒有的話,它就是一份很好的清單。
原文來源:CyberScoop(Derek B. Johnson):三機構的前沿 AI 測試事件應變指引,2026-10-16(三機構的主要文件未讀到)
三、中國的 AI 出口管制草案:門檻是至少 2 兆參數,或世界前十
中國這邊的停機鍵,裝在國境上。據 TNW,中國商務部與科技部 10 月 16 日公布一份技術出口管制草案,40 項技術裡 23 項是 AI,其餘 12 項太陽能、5 項生物醫藥,公開意見收到 11 月 15 日。Taipei Times 轉載的 Bloomberg 稿說,這 23 項 AI 技術涵蓋大型語言模型、agents、晶片設計和運算叢集。
門檻有兩條。模型權重與原始碼這一類,產品要「at least 2 trillion parameters」,或者在性能、使用量、安全等指標上排「world’s top 10」(TNW 標註這段引自 Bloomberg)。另外,用中國《資料安全法》定義的「core data」訓練出來的模型,禁止出口。例外也寫了:「open-source code and published research would be exempt」,開源技術出口可以走自動許可這類簡化程序。
TNW 還寫了兩個工程師會在意的細節。中國公司仍然可以透過 app、網站、API 服務海外使用者;但在境外伺服器上執行受管的模型,算出口,只是在自家的境外雲端伺服器上跑,可能自動拿到許可。另一份臨時出口登記規定已經生效,適用還沒完成的交易,包括智慧財產轉讓、海外授權、讓中國技術所有人變成受外國控制的變更。Taipei Times 10 月 17 日那篇寫它「yesterday」生效,換算是 10 月 16 日,報導本身沒寫日期。
商務部發言人(未具名)說目的是「the safety and controllability」(Taipei Times),TNW 引的說法是「prevent misuse and abuse」與「ensure that AI remains under human control」。
開源例外是我覺得最有意思的一格。照字面,它讓這套管制對開源的東西幾乎沒有作用,管得到的是閉源、而且大到某個程度的東西。不過報導寫的是「open-source code」,開放權重算不算在內,我讀到的兩篇都沒講清楚。對海外用中國模型的團隊來說,草案寫的是 API 照常、開源照常,最可能碰到的是第三類:你想把某個受管模型搬到自己的機房跑。如果你的架構裡有「把中國廠商的閉源模型部署到境外」這一步,草案定案前別把它當成穩定的選項。反過來說,如果最終版本把開源例外拿掉,整個判斷就要重來。
原文來源:TNW:China AI export controls draft,2026-10-16;Taipei Times(Bloomberg 稿),2026-10-17(商務部原公告、Bloomberg 原文未讀到)
四、claude-agent-sdk 的 resume:一個 session ID,變成一行指令
前面三則都在談大事的門檻。這一則小到不會出現在任何一份草案裡,但我覺得它最像真實世界的事故長相。
OSV 10 月 16 日刊出 GitHub Advisory GHSA-h4mw-j7qp-8mwm,標題是「Claude Agent SDK: Argument Injection via resume Option Allows Arbitrary Command Execution」,CVE 編號是 CVE-2026-96620(OSV 的 aliases 欄位),嚴重度「9.2 (Critical) CVSS_V4」。原文這樣寫:
「The Claude Agent SDK for Python passed the resume option to the Claude CLI without validation, allowing a value beginning with - to be interpreted as a separate CLI flag.」
接著是攻擊方式:「An attacker who controlled the resume value could inject an --mcp-config flag defining a stdio MCP server」,結果是 CLI 啟動時執行任意指令,而且繞過 SDK 自己的權限控制。
拆開來看其實很老派。SDK 底下是去叫 Claude CLI,resume 收的是一個 session ID,照理只是一串識別字。可是如果那串字以 - 開頭,CLI 會把它當成另一個 flag。攻擊者塞進去的是 --mcp-config,再定義一個 stdio MCP server,而 stdio MCP server 的本質就是「啟動時幫你跑一個程式」。一個本來只用來找回對話的欄位,走兩步就變成任意指令執行。這種洞在 shell 指令注入的年代就有了,換了一個 AI 工具鏈,一樣的坑又踩一次。
受影響套件:PyPI 的 claude-agent-sdk,修正版本 0.2.121(OSV 的範圍是 0.2.121 之前的版本,頁面列出 0.0.23 到 0.2.120)。依 PyPI 的發布紀錄,0.2.121 是 2026-07-17 上架的。通報者是 hackerone.com/moamenmahmood。
前置條件要講清楚,OSV 寫得很明白:「Exploitation required an application to pass untrusted input as the session ID to resume.」你的程式如果 session ID 都是自己產生、自己保存,這個洞碰不到你。會中招的是那種把 session ID 直接從 URL 參數、前端表單或 webhook payload 接進來,原封不動丟給 resume 的寫法。做多使用者 agent 服務、讓使用者「繼續上一段對話」的人,很容易順手寫成這樣。
我會做兩件事。第一,把套件升到 0.2.121 以上。第二,就算升了,也回頭檢查所有把外部字串餵給 SDK 選項的地方,session ID 先比對格式再用,以 - 開頭的一律擋掉。OSV 寫到的只有 resume 這一個入口,同樣的習慣會不會出現在別的選項上,我手上沒有證據,所以更不該只靠升版。
還有一個時間差。PyPI 上 0.2.121 是 7 月 17 日上架的,公告是 10 月 16 日刊出的。修正先出、公告後補是很常見的負責任揭露節奏,但它也代表這三個月裡,沒有習慣定期升版的人,不會知道自己為什麼該升。只在看到公告時才升版,等於把安全交給別人的發文時程。
原文來源:OSV:GHSA-h4mw-j7qp-8mwm,2026-10-16;GitHub Security Advisory;版本發布時間依 PyPI:claude-agent-sdk
五、Anthropic 向 Blackstone 開出逾 10% 的殖利率
這則的源頭是 FT,付費牆後面,我讀不到。以下只用 Reuters 轉述裡讀得到的四件事;網路上流傳的其他細節(總額、其他出借人、擔保結構),我讀到的 Reuters 稿裡都沒有,一律不寫。
據 Reuters 轉述 FT 週五的報導,引用知情人士:「Anthropic is offering Blackstone a yield of more than 10% to finance its latest chip deal.」Blackstone 旗下基金會投資 90 億美元的債務,擔保是 Anthropic 對這批晶片五年期的租賃付款。Reuters 寫「Reuters could not immediately verify the report.」
讀得到的就這麼多,但這四件事已經夠講一個重點。這筆債拿來還錢的,是 Anthropic 未來五年要付的晶片租金;換句話說,出借人押的是 Anthropic 五年內每期都付得出來。殖利率開在 10% 以上,代表出借的人要求的補償不低,我的解讀是它沒有把這筆當成安全的錢在算。晶片的價值會隨新一代產品下滑,五年期的租金是不是固定,報導沒寫;如果是,這兩條線走的方向本來就不一樣。
我的判斷偏保守:對外界來說,這則能證明的只是 Anthropic 願意用高成本換資金速度,證明不了它的現金流撐得住,那要等條件和揭露文件出來才看得到。在那之前,別拿這個利率去推 Anthropic 的財務狀況,也別拿網路上那些讀不到出處的大數字來補。
原文來源:Global Banking & Finance(Reuters 稿):Anthropic offers Blackstone double-digit yield,2026-10-16(FT 原文未讀到)
六、Zeabur 不到七週被入侵兩次,10 月 17 日宣布年底前全部關閉
前面五則的主角都在美國或中國,這一則離台灣工程師最近。Zeabur 是台灣團隊做的雲端部署平台,10 月 14 日被入侵,是它不到七週內的第二次;10 月 17 日,創辦人林沅霖寄信給用戶,宣布平台在 12 月 31 日前全部關閉。
第二次要對照第一次看,所以先交代 8 月那次。依 Zeabur 官方的事後報告,8 月 27 日(UTC)的入口是某位用戶部署在共享叢集上的 NextChat v2.16.1,它有一個 RCE 漏洞(CVE-2026-7644)。共享叢集允許跨專案的內網連線,攻擊者從那裡讀到路由快取裡的 Legacy API Key,找到一把團隊管理員還有效的 Key。接著從內部管理服務的環境變數拿到 AWS root 金鑰,一路走進正式環境的資料庫。被讀走的是部分專案的環境變數,裡面有 AI 與第三方服務的 API Key、雲端憑證、資料庫密碼和簽章金鑰。動區 8 月 29 日報導,官方確認 OpenAI、Anthropic、OpenRouter 的金鑰遭到濫用。官方自己列的促成因素裡,有兩條我會記下來:Legacy API Key 沒有權限範圍也沒有期限,內部服務拿著權限過大的雲端憑證。
第二次的攻擊時段,據動區引述社群取得的一封用戶通知信,是台灣時間 10 月 14 日晚上 9 點到 15 日凌晨 1 點(動區沒有附信件原文)。狀態頁的第一則公告掛在 UTC 10 月 15 日 16:08,也就是台灣時間 10 月 16 日凌晨 00:08,內容是「confirmed unauthorized access to user-deployed PostgreSQL and MySQL services still running on deprecated shared clusters」,另外補一句「we have found no evidence that services deployed on dedicated servers have been affected」。
4 小時 40 分鐘後,UTC 20:48(台灣時間 04:48),同一頁改口:「Our investigation has found that the incident is broader than first reported, and we are correcting our earlier update.」部分架在 Google Cloud 上的專用伺服器也被未授權存取,攻擊者對平台資料庫有讀取權限,外洩的資料包括服務環境變數、帳號資訊、API token 和 zSend API 金鑰。動區另外指出,用戶收到的通知信寫的是影響範圍僅限共享叢集,跟這次更正對不上。
被駭本身是壞消息,我更在意的是有件事發生了兩次。8 月那份事後報告自己承認,第一次通知對影響範圍的判斷有誤;10 月的第一則公告,又在幾個小時內被同一頁推翻。兩次事件,兩次的第一份通知都把範圍說小了。所以我的立場是:Zeabur 說的「沒有受影響」只能當下限,不能當結論。只要你的金鑰曾經放在 Zeabur 的環境變數裡,不管有沒有收到通知信,都當它已經外洩來處理。會讓我改變這個判斷的,是官方公布第二次的根因和逐專案的受影響範圍,而且附上判斷依據。到我寫這段為止,狀態頁寫的還是根因在調查中,受影響人數與外流筆數都沒有公布。
還有「deprecated shared clusters」這幾個字。依動區整理,共享叢集的退場 2 月 23 日就公告了,3 月 15 日起不能開新專案,4 月 1 日起不能加服務。可是已經在上面跑的服務可以繼續跑,第二次的第一則公告點名被存取的,正是這些還留在棄用叢集上的資料庫。標成棄用的系統,攻擊面不會跟著標籤一起消失,只是比較少人在盯。這是我的推論,第二次的入口官方還沒公布。
停業這件事,我沒有讀到 Zeabur 官方站上的公告,以下依電腦王阿達 10 月 17 日刊出的信件內容。信裡寫的時程是:即日起停止新購專用伺服器與網域,開始受理帳戶餘額退款;12 月 1 日起專用伺服器停用續費,依各自的到期日在 12 月 1 日到 31 日之間陸續關閉;共享叢集同樣從 12 月 1 日起暫停所有運行中的服務,還能手動恢復來備份資料;12 月 31 日全部停止。信裡特別寫了一句:「12 月 31 日是平台服務全部停止的日期,並不代表每一項服務都會持續運作到那一天。」資料刪除日、最晚匯出期限、Zeabur Support 停止服務的日期都還沒定。在 Zeabur 買的網域已經開放自助轉出。餘額退款和資安事件的損失賠償是兩項不同的申請,都透過 Zeabur Support 提出,信裡要求聯絡時註明申請哪一項。
用 Zeabur 的人今天該做什麼,狀態頁 10 月 15 日的兩則更新已經列了:輪替所有存在環境變數裡的機密,重新產生 Zeabur API token;用 zSend 或 Zeabur Email 的,建新的 API 金鑰,舊的已經全部撤銷;用 Google Cloud 專用伺服器的,改 root 密碼,刪掉不認得的 SSH 金鑰,特別是名稱標成 zeabur-pentest 的;這段期間部署失敗的服務要重新部署。8 月那次官方還建議過檢查用量帳單,這次一樣適用。
下面三點是我自己的建議,不是官方說的。第一,輪替先排 AI 服務的 API 金鑰和雲端憑證,8 月真的被拿去用的就是 AI 金鑰;8 月換過金鑰、又把新的那把放回 Zeabur 環境變數的人,那把也要再換。第二,搬家和輪替一起做,新平台上用新產生的金鑰,不要把 Zeabur 上的環境變數整包匯出再匯入,那等於把可能已經外洩的東西原封不動搬過去。第三,期限看 12 月 1 日,不要看 12 月 31 日:共享叢集那天就暫停,專用伺服器看自己的到期日。Zeabur 在 8 月的報告裡,把 Legacy API Key 沒有權限範圍和期限列成自家的促成因素之一;同一個毛病放在你自己的金鑰上也成立,這次能設範圍和期限的,換的時候一起設上。
原文來源:Zeabur 狀態頁:Unauthorized Access to Zeabur Infrastructure and User Data,2026-10-15(UTC);Zeabur:8 月資安事件報告;Zeabur 狀態頁:8 月事件;動區:Zeabur 七週內二度遭駭,2026-10-16;動區:Zeabur 環境變數外洩,2026-08-29;電腦王阿達:Zeabur 收攤,2026-10-17(Zeabur 官方站的停業公告未讀到)
Anthropic 的草案要的是逾 10 億美元或逾 50 個人,中國的草案要的是至少 2 兆參數或世界前十,兩邊都把門檻畫在「大到誰都看得到」的地方。可是今天最具體的一則事故,是一個以 - 開頭的 session ID,它不會觸發任何一條門檻,卻能讓一台主機照攻擊者的意思跑程式。三機構那份指引說不要只讓 AI 看著 AI,講的也是同一件事:盲點通常不在大家畫線的地方。
門檻底下的事,今天六則裡有兩則有現成的處理方式:把 claude-agent-sdk 升到 0.2.121 以上,再把餵給 resume 的字串擋一次格式;用 Zeabur 的人,把環境變數裡的金鑰全部換掉,照各自的到期日搬走。另外三份文件,小事故有沒有人收、會不會累積、累積到哪裡才有人負責,我讀得到的報導都沒寫。Anthropic 草案的全文還沒公開,三機構的主要文件我打不開,中國那份還在收意見,截止日是 11 月 15 日,定案版會不會補上這一塊,到時候才知道。









