一場完整記錄的真實入侵事件揭示：信任機制不能只建立在執行任務的 AI 模型之中。
一名實際攻擊者的工作目錄，以及超過 1,000 筆還原的 AI 代理（AI Agent）工作階段，提供了目前最完整的實證資料，呈現 AI 輔助入侵（AI-assisted Intrusion）實際如何運作。然而，研究發現與過往媒體標題所呈現的情況並不相同。
目前對於 AI 輔助攻擊（AI-assisted Attack）的多數理解，其實來自間接推論。通常只能看到攻擊產生的結果，再反向推測其形成過程。但這一次不需要如此。
研究人員將一台已遭入侵的伺服器轉為蜜罐（Honeypot），並完整取得攻擊者的工作目錄，其中包含超過 1,000 筆完整的 AI 代理工作階段，包括使用的提示詞（Prompt）、工具、模型本身的推理過程，以及過程中觸發的每一次拒絕回應。OALABS 的研究人員隨後公布了完整分析。
最直觀的結論，是 AI 正在降低發動攻擊所需的技術門檻。這起事件中的攻擊者本身並非高度專業的攻擊者，而是提出相對模糊的目標，再由 AI 代理完成其中的技術工作，包括偵察（Reconnaissance）、漏洞利用研究、憑證驗證、資料蒐集，甚至整理攻擊紀錄。這確實是值得關注的現象，但研究人員也特別提醒，不應只從這個角度解讀事件。
其中一項細節，比任何論述都更能說明問題：真正識別出攻擊者身分的，並不是 AI 的安全防護機制，而是攻擊者自身的疏忽。攻擊初期，攻擊者曾要求同一個 AI 代理協助潤飾履歷，並建立求職工具，而履歷中包含完整姓名、所在地及 LinkedIn 資訊。在執行超過 1,000 次惡意工作階段的過程中，模型始終未能辨識攻擊者身分；最後卻因為要求同一個 AI 代理協助求職，而自行暴露身分。
對系統而言，無論是入侵行為或求職需求，從對話內容本身來看，都可能只是一般的任務指令。既然系統無法區分入侵行為與經授權的資安作業，也同樣無法從這些請求中辨別犯罪行為與一般求職活動。 研究報告對這起事件採取審慎的分析態度，也刻意避免過度渲染風險。研究人員指出，這套攻擊流程與合法的紅隊作業（Red Teaming）幾乎難以區分。因此，報告並未主張擴大 AI 模型拒絕執行任務的範圍，因為攻擊者所使用的這些能力，同樣也能協助防禦方進行資安工作。
更值得注意的是，整起攻擊使用的 AI 模型甚至落後當前最先進模型一個世代。若將焦點放在「AI 降低攻擊技術門檻」所帶來的恐慌，不僅可能誇大這項風險，也與原始研究本身的觀點有所出入，而且隨著下一代模型推出，這樣的論點很快就可能失去時效性。
真正值得關注的發現並不那麼聳動，卻不會隨著技術演進而失去意義。
真正值得留意的是，在超過 1,000 次攻擊工作階段中，AI 代理僅觸發寥寥數次政策違規警示。不是每個工作階段觸發幾次，而是全部加總只有少數幾次。問題並非安全防護機制不存在，也不完全是防護能力不足，而是這些機制遭到繞過。而攻擊者使用的方法甚至非常簡單：每次開始工作階段時，都先宣稱正在執行「經授權的紅隊演練」。當特定要求遭到模型拒絕時，便重新改寫指令，並進一步強調相關作業已取得授權。
整個手法其實就這麼簡單。嚴格來說，這並不是技術層面的越獄攻擊（Jailbreak），而只是透過情境包裝（Framing）繞過限制。
這也是整起事件真正值得深入探討之處，因為問題並非單純透過未來的模型調校就能修補。從對話內容本身來看，AI 模型很難可靠地區分「經授權的安全驗證」與「具有惡意意圖的攻擊」，因為兩者呈現出的行為可能完全相同。偵察就是偵察，漏洞利用研究也仍然是漏洞利用研究。真正區分合法資安測試與惡意入侵的，是模型無法取得、也無法自行驗證的外部情境，例如由誰授權、授權測試的範圍為何，以及是否取得相關單位或資產擁有者的同意。攻擊者只需要宣稱這些條件成立，後續工作便得以繼續進行。
值得肯定的是，在部分情境下 AI 代理仍維持了明確的安全界線。當攻擊者將目標指向特定個人及其家人或要求建立利用竊取憑證牟利的明確操作指南時，AI 代理皆拒絕執行，而且攻擊者無法透過重新描述情境說服模型。這些案例的共同點在於，惡意意圖本身已經非常明確。然而，在兩端之間存在一大片灰色地帶，而真正入侵企業所需的大量工作正位於其中。這些操作從模型角度看起來與一般資安工作沒有明顯差異，因此仍能順利完成。
過去一系列文章反覆提出一項核心主張：對 AI 生成及 AI 驅動軟體的信任，不能來自執行工作的模型本身，而必須建立在一個獨立於模型之外的驗證層。這起真實入侵事件，正好在實際環境中驗證了這項觀點。
情境包裝之所以有效，與 AI 模型無法同時擔任自身稽核者的原因相同：負責檢查的角色與負責執行工作的角色共享相同的情境，因此也會共享相同的盲點。當模型被要求判斷自身行為是否合理時，實際上只能判斷所接收到的情境描述，而無法驗證真實環境中發生的事實。只要安全防護機制位於內容生成與任務執行的同一個循環中，就必須根據提示詞提供的資訊判斷使用情境；然而，提示詞本身的情境描述完全可能由提出指令的一方自行設定。
獨立驗證（Independent Verification）則不存在相同的限制，因為其判斷重點並不是意圖，而是實際產生的結果與系統狀態：程式碼實際執行什麼行為、系統暴露哪些服務，以及這些暴露是否形成真實風險。
一項面向網際網路、且存在已知可被利用漏洞的服務，無論發現該漏洞的工作階段被標示為紅隊演練、無害掃描，還是完全沒有任何標示，都同樣具有危險性。獨立驗證層判斷的是系統實際存在的風險，而不是圍繞系統的情境描述。這項特性並非單純提升模型能力就能補足，因為其中的落差來自架構本身，而不只是模型能力不足。
研究報告中的另一項細節，也直接指出了防禦方應關注的方向。AI 代理成功入侵服務時，並沒有自行發現全新的零時差漏洞（Zero-day），而是利用公開且已知的漏洞攻擊暴露在外的基礎架構，其中包括 CitrixBleed 2、Ghostscript 漏洞及 Livewire 漏洞等。AI 代理查找公開的 CVE 資訊、撰寫漏洞利用程式，接著實際執行攻擊。
這才是現階段 AI 攻擊威脅更真實的樣貌。真正需要關注的並非充滿未知技術的 AI 新型攻擊，而是企業原本就存在的大量已知漏洞，如今可以透過 AI 快速自動化利用。AI 並沒有改變哪些「門」原本就沒有鎖好，而是讓技術能力有限的攻擊者，也能快速且輕易地逐一檢查這些入口。 這也凸顯了持續性、獨立且涵蓋完整環境的安全防護為何如此重要。攻擊者成功利用的漏洞都是已知問題，原則上也都有機會事先修補。真正存在的落差並不是「不知道漏洞存在」，而是時間。防禦方尚未完成處理，攻擊方卻已經透過自動化快速完成利用。
這種不對稱性，正是所有資安團隊需要關注的問題。攻擊方如今有了能全天候運作、不會遺漏目標，並能逐一檢查所有對外暴露面的自動化工具，大幅放大了攻擊效率。相較之下，多數組織的防禦速度仍受到人力與注意力限制：本週有哪些發現完成初步研判、這個 Sprint 優先修補哪些漏洞，以及哪些既有服務多年來缺乏明確的維護責任。當攻擊方開始全面自動化，而防禦方仍高度依賴人工處理，可被利用的漏洞與已完成修補的漏洞之間，差距便會持續擴大，而這個差距本身就是攻擊面的一部分。
解決方法並不是責怪資安人員無法跟上攻擊速度，而是讓防禦方取得與攻擊方相同的槓桿。將自動化與 AI 應用於防禦端的事件初步研判、風險排序及弱點修補，可讓資安人員將專業判斷投入真正需要人工決策的工作，而不是被大量重複性任務淹沒。獨立驗證層的目的並不是移除人工角色，而是讓人員與機器能共同以接近現代攻擊者的速度運作，使攻防之間的差距不再持續擴大，而能逐步縮小。
而縮小差距不能只代表「更快發現漏洞」。在這起事件中，發現漏洞從來不是主要限制。這些都是具有公開 CVE 的已知漏洞。真正需要提升速度的是修補（Remediation）：在確認某個可被觸及且實際可利用的弱點後，以接近攻擊者將弱點轉化為漏洞利用程式的速度，完成修復並正式部署。這種能力還必須涵蓋整體環境，而不只是近期開發的程式碼，包括新系統與既有系統、自行開發的程式碼與第三方相依套件。當攻擊者已能完整掃描整個攻擊面，防禦方也必須具備涵蓋完整攻擊面的能力。
同時，這套機制仍必須獨立於產生程式碼的模型之外，原因與整起入侵事件所揭示的問題相同。若由模型負責修補自身產出的內容，本質上仍然是讓模型評估自身結果。要建立能與自動化攻擊抗衡的防禦機制，需要的是自動化、持續性、涵蓋整體環境的修補能力，並由獨立驗證層根據程式碼實際執行的行為進行判斷，而不是依賴提出要求的一方如何描述情境。
這也是後續文章將進一步探討的主題：如何讓「獨立驗證層」從一項安全原則，進一步成為實際可落地的產品能力。
以上觀點並不代表應完全排除 AI，而是應將 AI 運用在正確的位置。
人工判斷仍應作為重要的驗證層，因為最終責任仍由人承擔，而不是 AI 模型。人員能以獨立角度檢視並質疑 AI 的判斷，而這正是模型難以對自身工作做到的。 AI 的角色則是放大這些專業判斷的效益，包括持續揭露風險暴露、排列處理優先順序、加速修補，以及減少單靠人力難以負荷的大量重複性工作。
目標並不是以 AI 取代人工驗證，而是讓資安人員有能力驗證規模與變化速度都已超出純人工評估能力的複雜環境。在這樣的模式下，AI 提供規模化處理能力，而人員提供信任與最終判斷。透過這種分工，防禦方才能跟上以機器速度運作的攻擊者，同時保留資安最終所依賴的獨立判斷能力。
這起事件比較容易接受的解讀，是「AI 讓攻擊者變得更聰明」。但更值得關注的事實是：攻擊者本身並不高明，AI 的安全防護機制也沒有失效，但攻擊依然成功了。
模型端的安全防護機制與紅隊測試仍然不可或缺，也應持續改善。然而，這些機制都運作在對話情境之中，而在對話裡，意圖可以透過文字自行宣稱。這與驗證程式碼實際執行行為屬於不同層次的安全機制。兩者應彼此互補，而不能互相取代。這起攻擊最終仍然成功，因為區隔「經授權的安全驗證」與「真實惡意入侵」的關鍵，只剩下一句由攻擊者自行輸入的情境描述。
建立在模型內部的信任機制，可能受到情境描述影響；建立在模型之外、關注程式碼實際行為而非提示詞內容的信任機制，則不受相同限制。這並不是等待下一代模型改善就能解決的調校問題，而是為什麼安全架構需要具備獨立驗證機制的根本原因。而這起真實入侵事件，正提供了一個具體的證明。
若對 Mend.io 有興趣歡迎留下資訊，將會有專人與您聯繫 ➤ https://www.gss.com.tw/mend-io