OpenAI把安全團隊「第一眼」的部分工作交給了自家模型:新警報先由AI分類,人力只處理影響重大的判斷。8月17日,Greg Brockman在一篇安全文章中公開了這套做法,同時提出更具體的主張——安全團隊不該只用AI多抓漏洞,還要讓它縮短修復真正重大漏洞的路徑。
這並非單獨發布的軟體功能,比較像是OpenAI對自動化攻防節奏的一次公開說明。模型已經能把漏洞、設定錯誤與權限過大的身分關係串成完整攻擊路徑,防守方如果還照傳統工單的步調處理,待辦事項的堆積速度恐怕會先於能力升級變成風險。
警報分類率先自動化
OpenAI表示,如今「幾乎所有」最初的安全警報都會先經過AI系統分類,再交由人力處理。公司同時也把偵測結果串接到範圍受限的自動回應機制上,但把影響重大的決策留給人。
文章原文寫道:"The goal is to ensure we can detect and respond to security issues at machine speed."(目標是確保我們能以機器的速度偵測並回應資安問題)。白話一點說,就是把機器擅長的重複篩查工作提速,而權限擴大、正式環境變更與事故判斷仍留給資安人員。
文章提到的個人案例也說明了OpenAI想推廣的工作方式:Brockman讓公開可用的GPT-5.6 Sol檢查自己的靜態網站,約15分鐘就找出13個問題;隨後又在約一小時內協助完成DNS、TLS、依賴套件與部署遷移的修復。這個案例來自公司負責人本人,不該被當成通用的效能基準,但它展現出把「發現、驗證、修復」壓縮進同一套工作流程的方向。
先掃最窄的一段範圍
OpenAI並沒有建議企業直接建置無人值守的資安維運中心。它給出的路徑相當保守:先對單一程式碼儲存庫做唯讀掃描,再讓模型讀取已結案的警報;確認流程可靠後,才進入到拉取請求(pull request)審查、即時警報分類,以及範圍明確的誤判自動結案。
這種先後順序值得注意。資安自動化最容易出包的地方,通常不在於模型能不能找出異常,而在於這個異常被接上了什麼權限。文章反覆提到最小權限、網路隔離、監控與階段性上線等傳統控管機制;AI被放進流程之後,這些控管並沒有因此失效,反而更需要明確界定。
對開發團隊來說,眼下值得驗證的指標不該只是「模型抓出幾個問題」。更實用的是:高優先級問題從發現到確認耗時多久、修復是否搭配回歸測試、自動化動作是否始終被限制在權限邊界之內。OpenAI這次的表態,把這些工程指標推到了AI資安產品敘事的最前面。
參考來源:OpenAI安全文章、CocoLoop、AI警報分類與人工決策邊界及個人網站案例之查證。