OpenAI 安全衝刺計劃引入 Cathedral Systems 測試其防禦能力

OpenAI 正把 Cathedral Systems 納入下一輪內部安全衝刺計劃，邀請外部研究人員運用該公司的 AI 模型挑戰其防禦措施。這項於 11 月 2 日公布的 OpenAI 安全衝刺計劃，延續此前已有 25% 產品工程師參與的工作。當中的矛盾相當實際：發現弱點會帶來額外工作，而防護則取決於能否將可靠的修補措施部署至正在運行的系統。

公告描述的是籌備工作，而非已完成的成果。Cathedral 的研究人員將與 OpenAI 團隊並肩工作，為內部測試加入另一個視角。OpenAI 尚未披露衝刺計劃的時間表、詳細測試範圍，或這項擬議合作的發現。

Anthropic 的 Project Glasswing 提供了一個相關比較，尤其是其對驗證及修補限制的說明。這些工作共同面對的核心競爭，在於加快發現漏洞與處理研究人員所發現問題所需工程能力之間的取捨。外部專業意見的價值，在於能否在整個過程中挑戰既有假設。

OpenAI 安全衝刺計劃實際改變了甚麼

具體改變，是在 OpenAI 的內部防禦測試中加入一個外部研究合作夥伴。

根據該公司的安全衝刺計劃，Cathedral 將與其團隊一同使用 OpenAI 模型調查弱點。Cathedral 聯合創辦人兼行政總裁 Gavin Kliger 表示，合作涵蓋發現問題、測試修補措施，以及強化持續防禦。這些是合作夥伴所述的目標，而非經獨立驗證的成果。

這個區別相當重要，因為公布安全演練代表一項意圖，並不代表已覆蓋所有範圍、揭示調查人員遺漏了甚麼，或證明擬議修補能通過後續測試。讀者在評估其後更新時，應留意這個界線。

外部研究人員可以在不承襲系統建設者所有假設的情況下，檢視一個熟悉的系統。內部團隊了解某項架構存在的原因，以及塑造它的各種限制。這些知識有助調查，但熟悉程度亦可能收窄人們提出的問題。

試想一個共享文件服務中假設性的權限問題。其開發人員可能會測試一般使用者能否透過預期介面開啟受限制文件。另一名調查人員則可能檢視匯出、背景處理或較舊的整合路徑，是否實施相同限制。

這個例子僅作說明，並非 OpenAI 已披露的發現。它的相關性在於，比較檢查預期工作流程與挑戰其周邊假設之間的差異。當研究人員有空間追查這些不同路徑時，合作才會發揮作用。

協作亦會帶來協調成本。外部調查人員需要足夠背景資訊，才能區分真正的安全邊界與預期行為。內部工程師則需要可重現的證據，而不是一份令關鍵條件仍然模糊的描述。

這個交接的質素，將影響 Cathedral 參與的價值。當另一個團隊能理解其條件、評估其後果並識別負責系統時，一項發現才會變得可採取行動。缺乏這種轉譯，外部審視可能只會增加另一條待辦隊列。

協作與獨立保證之間亦有重要分別。參與演練的合作夥伴可貢獻專業知識，但單憑參與並不構成公開審計。範圍、匯報安排，以及挑戰結論的自由度，決定外界可合理推斷多少保證。

現時，這項合作只支持一個狹義結論：OpenAI 希望有更多研究人員挑戰其防禦措施。關於風險暴露降低的說法，必須等待工作本身提供證據。

更快的發現速度為工程能力帶來壓力

面對即時壓力的，是負責把可信發現轉化為安全改動的工程師。

漏洞是在特定條件下可能危及系統安全的弱點。發現漏洞後，隨即要就嚴重性、責任歸屬、修補及部署作出一連串決定。加快發現速度，並不會自動加快之後每一項決策。

審視擬議安全修補的產品工程師，必須考慮的不只是原有測試是否已失效。改動可能影響合法使用者、整合功能、效能或營運復原。即使 AI 系統提供了初步修補，這些責任仍然存在。

這造成一項組織層面的取捨。安排更多工程師投入防禦工作，可加強對安全的關注，但亦會減少其他承諾可用的時間。管理層必須決定哪些工作要調整、由誰負責決策，以及未解決風險如何升級處理。

壓力亦會落在安全團隊身上。分流，即按可信度及緊急程度整理發現的程序，當報告湧入速度快過調查人員的評估能力時，會變得更困難。對同一弱點的重複描述，可能掩蓋真正需要即時行動的問題。

OpenAI 在公布 Cathedral 合作前已表達這種緊迫性。在其 8 月的防禦者窗口文章中，Greg Brockman 指出，不斷提升的 AI 能力為防禦者提供了有限機會去強化系統。他亦寫道，Hugging Face 事件後，OpenAI 低估了其模型在現實世界中的網絡能力。

這個說法為公司立場提供背景，而非其預測的獨立證明。OpenAI 認為，防禦者應把 AI 輔助與基礎安全控制結合。該公司的論點是，隨著攻擊能力擴散，等待一般審核週期會愈來愈不可接受。

其分析含意不止於購買另一款安全產品。組織需要一套方法吸收可信發現，避免緊急工作在團隊之間消失。若無人可授權修補，即使調查人員速度更快，價值亦有限。

企業買家面對相關的評估問題。供應商的公告可以展示關注與投入，但買家仍需要與自身風險暴露相關的證據。他們應區分營運活動與足以改變自身風險評估的結果。

知識工作者亦與此息息相關，因為 AI 服務正愈來愈多地嵌入日常資訊工作流程。文件、對話及連接系統，令存取錯誤的後果變得具體。讀者毋須具備技術專業知識，也能理解權限邊界為何值得反覆審視。

對工程組織而言，維護一個可搜尋的知識庫可協助調查人員尋找系統文件及過往決策。這有助提供調查背景；並不能取代安全測試，亦不能證明系統安全。

核心壓力仍然是能力。當組織能就所發現問題作出穩健決策時，發現更多問題才有價值。否則，發現速度將超越負責採取行動的機構。

持續防禦取決於經驗證的修補措施

AI 輔助防禦最有力的版本，是衡量弱點在修補部署至目標環境後是否仍可被利用。

OpenAI 公布的持續防禦架構描述了一個涵蓋資產盤點、發現、驗證、責任歸屬及已驗證修復的循環。修復意指糾正弱點並確認更正有效。該公司表示，其早期工作揭示了已合併修補與已部署修復之間的落差。

這是重要的營運區別。已合併的修補已進入程式碼庫，但正在運行的服務仍可能使用舊版本。即使部署成功，相關實例、設定或相依系統亦可能仍未納入修復範圍。

OpenAI 亦描述了用於重現發現及測試擬議改動的隔離環境。隔離可把可能造成干擾的調查工作與其他系統分開。可重現性則讓另一名調查人員能重複相關條件，並評估是否出現相同行為。

這些是公司對其方法的描述，而非全面的外部評估。不過，它們仍指出評估下一輪演練時可用的問題。這項合作的成效，部分應按證據從最初懷疑傳遞至經驗證的營運結果的流暢程度衡量。

設想一個假設性的服務，它在接受請求時未有檢查呼叫者是否擁有所請求的資源。調查人員在受控環境中重現該行為，工程師其後加入權限檢查，並驗證原有請求失敗。

這個結果固然必要，但調查仍有更多問題。另一種請求格式會否存取同一資源？非同步工作會否重複同一錯誤？已部署環境是否確實運行經修正的版本？

這些問題說明，發現與修復需要不同類型的判斷。最初的調查人員尋找可行的路徑。工程師則必須在保留合法行為的同時，於相關系統中堵塞弱點。

AI 代理人，即使用模型選擇及執行步驟的軟件，可協助這個過程的部分工作。挑戰在於決定它可採取哪些行動，以及哪些證據足以獲得人類批准。更高自主性同時擴大潛在處理量，以及錯誤假設所帶來的後果。

因此，經濟問題關乎整個調查流程。一份由模型產生、節省發現時間的報告，若說明不完整，仍可能耗用審閱者的時間。清晰的重現步驟及聚焦的擬議修補，則可改變這個平衡。

證據質素亦影響機構記憶。若調查人員保留條件、推理及驗證步驟，日後的審核便可建立於這些工作之上。若只保留一張已關閉的工單，未來團隊便須重新建構為何該決定曾被視為穩妥。

這正是 Cathedral 合作存在具體機會的地方。外部研究人員可同時挑戰弱點，以及對其修復的擬議詮釋。當內部團隊已對一個熟悉解釋建立信心時，這種貢獻尤其有用。

就 OpenAI 安全衝刺計劃而言，可信的結果應把發現與營運上的閉環連結起來。大量產生的修補措施只反映輸出量。經驗證的修復則能更有力地證明，這項演練是否改變了風險暴露。

Anthropic 的經驗突顯同一瓶頸

競爭比較的重點，在於組織如何處理發現，而非哪個模型產生最長的清單。

Anthropic 在 5 月發布的漏洞修復更新中，介紹了 Project Glasswing 早期使用 Claude Mythos Preview 進行防禦研究的經驗。該公司表示，隨着發現速度加快，驗證、披露及修補已成為限制因素。它亦指出，部分維護者要求放慢披露節奏，因為他們需要更多時間準備修正措施。

這個說法提供了相關的比較角度，儘管兩個計劃的範圍不同。Cathedral 已公布的工作關乎 OpenAI 自身的防禦。Glasswing 則涉及更廣泛的軟件生態系統，當中所有權及部署可能跨越不同機構的界線。

Anthropic 的說法亦屬於模型供應商提供的有利益關係證詞。其觀察值得註明來源，正如 OpenAI 的描述一樣。兩家公司發布的內容均未能建立其模型或防禦營運的受控比較。

不過，內部與外部軟件維護之間的營運差異仍然重要。修復自家服務的機構，通常可在其管理架構內協調調查、程式碼審查及部署。生態系統項目則可能依賴日程、資源及發布政策各異的維護者。

因此，這項比較不能支持簡單地判定誰勝誰負。處理由外部維護軟件的計劃，面對的協調問題，並非內部衝刺工作以相同形式需要面對。讀者在根據所報告的結案率差異作出結論前，需要先理解相關背景。

對 OpenAI 而言，相關的競爭壓力在於清晰說明其流程，讓其他人能夠評估及調整採用。對 Anthropic 而言，相應的壓力是展示增加發現如何轉化為可持續的維護工作。當兩者都處理發現之後的工作時，其敘述便會更有說服力。

外部研究人員在這些安排中亦扮演不同角色。他們可以發現弱點、驗證報告、評估嚴重性，或評估建議的修復措施。把所有外部參與一概而論，會掩蓋流程中哪些部分實際獲得了另一種視角。

同樣的審慎態度亦適用於「AI 輔助防禦」一詞。它可以指模型提出問題建議、生成重現步驟、準備修補程式，或協助協調調查。這些活動有不同的失效模式，亦需要不同的監督。

因此，評估 OpenAI AI 防禦影響的讀者，應問清楚協助在某個具體工作流程中改變了甚麼。調查人員是否更快得出可信結論？工程師是否獲得更好的證據？已部署的修復措施能否承受新的挑戰嘗試？

這些問題可避免把合作公告變成缺乏支持的模型競賽，也令競爭比較對需要決定向供應商索取甚麼證據的買家更有用。

業界共同面對的問題是，軟件維護有人力及組織上的限制。更好的發現能力可以更清楚地暴露這些限制。它能否紓緩限制，取決於後續每個環節的質素。

外部審查仍留下驗證缺口

針對已知漏洞利用方式的成功測試，並不能證明根本弱點已獲徹底解決。

獨立研究在此提供了有用的提醒。Tobias Heldt 與同事於 10 月發表一篇關於攻擊與修復的預印本，評估模型在五個非公開軟件環境中的表現。在某些環境中，修復表現優於攻擊表現；在另一些環境中則較差。

研究人員亦在初始漏洞利用被阻止後測試後續攻擊。在 524 個測試區間中，另一次漏洞利用在其中 92 次成功，而作者明確指出這些結果並非獨立。這項保留條件意味，不能把結果當作真實部署環境的一般失敗率。

該研究並未評估 Cathedral 合作關係，亦未確定 OpenAI 的系統將如何表現。其相關性在於方法論：阻止初始測試與抵抗進一步嘗試，是不同的結果。作者據此提出需要更具體的比較及更多抗性測試。

就以實際結果說明的 OpenAI 安全衝刺工作而言，這項區別應處於核心位置。團隊可以正確修復觀察到的症狀，卻忽略相關的另一條路徑。重新調查有助評估修復措施是否處理了最初失效的安全屬性。

在整個調查過程中依賴相似推理，亦存在另一項風險。若相同假設指導發現、修復及驗證，一個錯誤可能在整個流程中存留。不同的調查人員及測試策略有助挑戰這個共同盲點。

這並不代表外部參與可保證每個階段都具獨立性。研究人員可能共用工具、文件及預期。關鍵問題是，是否有人同時具備質疑令人安心結論所需的授權與證據。

公開披露帶來另一項限制。詳細證據可讓外界評估結果，但在用戶獲得保護前公開可被利用的弱點，可能造成風險。負責任的更新通常需要說明方法，但未必會立即披露每項技術細節。

因此，讀者應區分缺少公開細節與沒有進行任何工作的證明；亦應區分保密安排與工作成功的證據。兩種錯誤都會把現有紀錄無法支持的不確定性，變成既定結論。

只要分類清晰，彙總結果可以提供幫助。候選發現、已重現的弱點、獲接納的修復措施及已部署的修正，代表不同階段。把它們合併成單一標題數字，會令進展更難解讀。

負面結果亦很重要。調查人員未能重現的報告可能是錯誤的，也可能是測試環境缺少必要條件。不確定性的原因會改變團隊下一步應採取的行動。

最有力的報道會保留這些區別，同時不誇大確定性。它會描述檢視範圍、支持結案的證據，以及仍然存在的限制。Cathedral 的參與創造了接受此類審查的機會，但單憑公告尚未展示其運作方式。

合作公告後值得留意的事項

下一批有用訊號，是經驗證的結果、持續的工程能力，以及外部報告轉化為可執行工作的證據。

第一個訊號是計劃中合作發出的實質更新。未來數月，讀者應留意明確界定的範圍，以及發現如何推進的清晰說明。一份把調查連結至獨立核實修復措施的報告，將加強合作關係的論據。

若該更新能把尚未解決的發現與已完成工作分開說明，將更具資訊價值。安全演練甚少能消除所有不確定性。解釋哪些事項仍未解決，可令報告更可信，因為這顯示證據的邊界所在。

主要聚焦研究活動的發布，則只能支持較狹窄的結論。它能顯示測試確實發生，但對已部署系統的影響仍不明確。讀者不應把這些不同結果視為可互換。

第二個訊號是，工作能否在集中演練以外變得可持續。一次衝刺可凝聚注意力，並暫時移除組織障礙。持續防禦要求這些能力能夠在日常產品期限、人手變動及相互競爭的營運需求下延續。

持續承擔責任的證據將加強 OpenAI 的論據。若證據顯示發現一再等待分配或部署，則會削弱「更快發現能產生持久保護」的說法。問題在於，機構能否在最初的集中投入結束後維持這個循環。

這個訊號亦會塑造 OpenAI AI 防禦對其自身系統以外的影響。其他機構需要知道，方法的哪些部分依賴非常規的人手配置。需要永久緊急關注的流程，將難以在其他地方複製。

第三個訊號關乎外部報告。在 11 月 2 日另行發布的漏洞賞金更新中，OpenAI 為獨立研究人員引入更強誘因，包括表揚報告質素。漏洞賞金計劃會獎勵以負責任方式報告安全弱點的合資格研究人員。

該公司表示，可靠的重現結果及清晰的影響描述，能讓工程師在修復工作上取得先機。這個重點與合作關係的營運挑戰一致。更好的證據可令外部發現更容易評估及採取行動。

有用的後續資訊應展示這些報告如何經過驗證及修復。僅有更多提交並不足以證明進展。能夠送達負責團隊並獲得驗證解決方案的可信發現，才會提供更有力的訊號。

這些觀察並不要求把每項未公開細節都視為可疑。安全報告有合理限制，尤其在修復仍未完成期間。目標是建立一份可支持審慎結論的紀錄，同時避免令用戶承受不必要風險。

對追蹤這個故事的讀者而言，應先留意下一批實質結果，而非下一則合作標題。比較哪些內容已被調查、哪些已被重現，以及哪些已達成經驗證的修復。把公司聲稱與獨立證據分開，並問清楚外部研究人員是否改變了結論，或揭露了被忽略的假設。當這些細節浮現時，OpenAI 安全衝刺工作將更具資訊價值。在此之前，公告只確立了擴大審查的計劃。值得帶進未來更新的具體問題是：有甚麼證據顯示，這項合作減少了運行中系統的真實弱點？