Cloudflare以eBPF整合DDoS防護、流量分流與系統觀測

來源：https://www.ithome.com.tw/news/177391

提供網路安全、效能與可靠性服務的Cloudflare，將Linux核心可程式化技術eBPF導入全球邊緣網路，用於DDoS防護、流量分流、服務不中斷的重新啟動，以及系統運作狀態觀測，根據Linux基金會旗下eBPF基金會本週公布的Cloudflare eBPF部署案例，這套架構可因應Anycast網路及數百萬個IP位址的管理需求，並減少Cloudflare對客製化Linux核心修補及特定硬體的依賴。

在DDoS防護方面，Cloudflare結合eBPF與Linux高速封包處理框架eXpress Data Path（XDP），打造第四層DDoS防護機制L4Drop，可在惡意封包進入Linux核心網路堆疊前加以過濾，單一CPU核心每秒可處理逾1,000萬個封包。設於邊緣節點的dosd偵測系統，可在數秒內套用DDoS緩解規則。eBPF基金會指出，Cloudflare曾於2025年11月透過這套防護機制，自動緩解流量規模達31.4 Tbps的DDoS攻擊。

在連線分流方面，Cloudflare自行開發流量分派系統Tubular，在socket層級分配流量，讓多項服務共用相同IP位址與通訊埠。Cloudflare另以eBPF開發udpgrm，讓使用者資料包協定（User Datagram Protocol，UDP）服務在重新啟動期間持續處理流量。

Cloudflare也結合ebpf_exporter與追蹤工具，掌握Linux核心延遲分布情形及封包處理流程，協助工程人員找出傳統工具不易察覺的Linux核心競爭條件與延遲尖峰。

'

高階後門Daxin、Stupig鎖定臺灣製造業發動攻擊

來源：https://www.ithome.com.tw/news/177390

4年前資安公司賽門鐵克揭露中國高階後門程式Daxin，並指出相關活動可追溯至2013年，攻擊目標多半為各國政府或是與中國利益有關的企業組織，當時賽門鐵克指出是他們看過最先進中國的惡意程式，因而引起高度關注，如今傳出駭客將其用於臺灣企業。

博通旗下的Symantec and Carbon Black威脅獵補團隊指出，他們今年5月，在一家跨國高科技製造公司旗下的臺灣子公司當中，發現了Daxin的活動，該團隊針對受害電腦進一步調查，找到另一個後門程式Stupig，值得留意的是，這兩支惡意程式的編譯時戳都在2013年初，代表它們可能已潛伏在該公司長達13年。研究團隊表示，兩款惡意程式在同一主機上\部署、功能上相輔相成，且開發手法具有相似性，顯示背後的攻擊者很可能是同一批人馬。

Daxin為Windows核心層級的rootkit，最大的特徵在於C2連線機制，該程式不會主動對外建立連線，而是監控傳入的TCP流量，然後挾持既有的合法連線，來傳出經加密處理的C2指令，使其極難透過傳統網路監控方式被識別。此外，該惡意程式還能透過被感染的主機進行多次跳躍的通訊（Multi-hop Communication），從而接觸隔離網路環境的系統。而在這起攻擊行動裡，駭客疑似利用舊版鼎捷數智（Digiwin）單一簽入（SSO）入口網站作為初期的入侵管道，此入口網站約於2009至2011年之間建置，並採用老舊的Java Development Kit（JDK）1.5與1.6版元件。

對於這次新發現的Stupig，駭客設置與Windows鍵盤配置程式庫相似的名稱kbdus1.dll掩人耳目，並使用機碼將其向系統註冊為鍵盤配置的提供者，使得每次電腦開機的過程裡，win32k.sys會將其載入winlogon.exe。此後門進入winlogon.exe之後，就會監控Windows登入畫面，是否出現以Stupig開頭的使用者名稱，一旦有人輸入相關名稱，電腦就會在安全模式以SYSTEM執行特定的字串內容。

'

美國戰爭部暫停CMMC第二階段，檢討國防承包商資安認證制度

來源：https://www.ithome.com.tw/news/177389

7月13日美國戰爭部宣布，立即暫停網路安全成熟度模型認證（Cybersecurity Maturity Model Certification，CMMC）第二階段要求。第二階段原定今年11月10日實施，部分處理受控非機密資訊（Controlled Unclassified Information，CUI）的國防承包商，屆時必須通過CMMC第2級第三方評估，才能參與適用這項要求的國防採購案。如今戰爭部將重新檢討第三方評估方式及制度實施安排，以減輕中小型與非傳統承包商的法規遵循負擔，進階指引將於為期60天的審查結束後頒布。

戰爭部強調，此次暫停並不代表取消CMMC制度，第一階段的自我評估要求仍維持實施。處理聯邦合約資訊（Federal Contract Information，FCI）的承包商，仍須遵守《聯邦採購條例》FAR 52.204-21；處理CUI的承包商，仍須符合NIST SP 800-171第2版，以及DFARS 252.204-7012有關保護國防資訊與資安事件通報的要求。暫停期間，國防採購案只能列入CMMC第1級或第2級自我評估要求，不得要求承包商接受第2級第三方評估或第3級政府評估。

根據近期資料與業界回饋，包括美國小型企業署的報告，現行制度的法規遵循成本偏高，加上合格第三方評估機構的量能不足、等待時間過長，已導致部分新進業者與小型企業退出國防合約市場。路透社訪問多家中小型航太與國防供應商，部分業者表示，為符合CMMC要求，可能須負擔數十萬美元的法規遵循成本，也有供應商因等待CMMC第2級第三方評估的時間過長，重新考慮是否繼續承接國防合約。

'

Linus Torvalds談Linux核心對AI的立場，不排斥並以技術價值為主要考量

來源：https://www.ithome.com.tw/news/177381

Linux核心創始人Linus Torvalds在linux-media郵件清單表明，Linux核心不會成為全面排斥AI工具的專案。他表示，AI和其他開發工具一樣，開發者可自行決定是否採用，但核心社群不會因為有人反對，就禁止其他人使用大型語言模型協助開發。現行規範同時要求，人類提交者仍須審查程式碼、確認授權並承擔全部責任。

該討論起因於Linux核心開發者討論Sashiko的使用方式。Sashiko是Linux基金會的開放原始碼AI代理式程式碼審查系統，會監看Linux核心郵件清單上的新修補程式，透過多階段審查流程檢查架構、安全、資源管理與並行處理等問題。Linux核心開發者Laurent Pinchart認為，維護者若打算依據Sashiko的審查結果要求作者處理，應先自行分類並驗證，避免將未經確認的AI回報直接轉交貢獻者。

Laurent Pinchart引用Software Freedom Conservancy發布的生成式AI使用建議。該組織主張，自由及開放原始碼軟體社群應支持選擇拒絕使用AI系統的貢獻者，也不應強迫開發者採用相關工具。提交AI協助產生的內容前，貢獻者應充分審查並理解內容，也應揭露使用的系統、版本與協助方式。Sashiko開發者Roman Gushchin則表示，若要求維護者先分類並驗證Sashiko的審查結果，將使這套工具協助維護者的目標難以達成。

Linus Torvalds回應，全面排斥AI並非Linux核心的立場。他認為AI和其他開發工具一樣，已證明具有實際用途，但也不完美，並可能增加維護者的工作量。Linux核心應設法讓大型語言模型工具真正協助維護者，而不是製造額外負擔。核心專案仍會以技術價值作為主要判斷依據，不會因為對新工具的疑慮而排除AI，也不會強迫任何開發者使用。

Linux核心現行AI輔助開發文件規定，AI代理不得加入Signed-off-by標籤，因為只有人類能依開發者來源證明（Developer Certificate of Origin，DCO）對貢獻作出法律認證。人類提交者必須審查AI產生的程式碼、確認程式碼與GPL-2.0-only授權相容，並以自己的Signed-off-by標籤承擔全部責任。文件也指出，使用AI工具協助開發時，應加入Assisted-by標籤，註明工具或代理名稱及模型版本。

'

歐盟要求Google開放Android AI功能並共享搜尋資料

來源：https://www.ithome.com.tw/news/177388

歐盟執委會（European Commission）周四（7/16）依據《數位市場法》（Digital Markets Act，DMA）發布兩項具法律約束力的實施規範，要求Google開放Android作業系統的AI互通功能，並向符合資格的第三方搜尋服務分享匿名化搜尋資料，以促進AI助理及搜尋市場的公平競爭。Google則批評，相關措施恐削弱歐洲使用者的隱私與裝置安全。

歐盟表示，Google同時經營Android、Google Search等多項核心平臺服務，DMA要求被認定為「守門人」（Gatekeeper）的業者，不得利用平臺優勢偏袒自家服務或阻礙競爭對手發展。此次發布的實施規範，主要是進一步釐清Google應如何履行DMA義務，而非認定Google已違反DMA，因此不涉及罰款。

第一項規範聚焦Android的AI互通性。歐盟指出，目前第三方AI助理只能有限度存取Android的重要功能，相較之下，Google自家的Gemini可完整存取相關功能，不利市場競爭。為此，Google必須讓第三方AI助理平等存取Android功能，使用者未來可透過類似「Hey Google」的語音指令啟用偏好的AI助理，也能要求其跨App執行任務，例如預約計程車、建議聊天訊息的回覆內容，或回答與近期造訪地點有關的問題。歐盟使用者預計自2027年7月起受惠於相關變更。

另一項規範要求Google向符合資格的第三方搜尋服務提供匿名化搜尋資料，讓競爭對手可利用這些資料改善搜尋結果與服務品質。具備搜尋功能的AI聊天機器人也可申請取得資料，而Google原則上必須提供其用來優化Google Search的同類資料。Google須自2027年1月起向符合資格的搜尋服務供應商分享資料。

Google全球事務總裁Kent Walker表示，要求第三方AI助理取得更多Android權限，可能削弱既有的裝置安全機制。Google認為，目前手機製造商在審核相關AI服務時扮演重要角色，若外部App在缺乏同等防護下取得敏感系統權限，恐增加資安風險。至於在搜尋資料共享上，Google擔心使用者的私人搜尋內容可能在匿名化不足，且未經本人知情或同意的情況下流向第三方，進而危及個人隱私、企業機密甚或國家安全。

'

CISA警告Fortinet沙箱平臺重大漏洞遭到利用

來源：https://www.ithome.com.tw/news/177387

iThome資安新聞編輯團隊溫馨提醒

擔心錯過重要的資安新聞嗎？資安日報與資安週報即日起推出免費電子報訂閱，每天每週直送資安要聞，提供專業、易懂、便於轉述的最佳中文資安情報，助你掌握全球與臺灣最新資安脈動。

'

近8成組織將AI用於資安，但僅36%建立正式AI風險管理計畫

來源：https://www.ithome.com.tw/news/177383

資安教育與研究機構SANS Institute於7月發布調查報告指出，企業在資安工作中採用AI的比例大幅上升，但AI治理機制尚未同步成熟。

調查顯示，將AI納入資安策略的組織比例，從2025年的50%升至2026年的78%；建立正式AI風險管理與法規遵循計畫的組織比例，則僅從2025年的35%微幅增至2026年的36%。在已採用AI的組織中，僅27%的受訪者表示，AI部署已進入成熟階段，並融入日常作業。

隨著AI應用擴大，76%的IT與資安從業人員表示，資安團隊已承擔企業AI治理職責。不過，63%的受訪者表示，組織仍無法掌握AI模型的使用位置及可能暴露的資料；另有54%的受訪者表示，組織尚未建立AI稽核框架。

AI在攻防兩端的應用，也持續擴大。78%的IT與資安從業人員表示，所屬組織過去一年曾確認或懷疑遭到AI輔助攻擊；將AI導入紅隊作業的比例，也從2025年的33%升至2026年的61%。另有63%的受訪者表示，AI執行威脅偵測與回應時，仍會出現明顯問題，認可這類狀況的受訪者比例高於2025年的45%。報告分析指出，這不一定代表AI表現惡化，而可能是組織擴大部署後，更容易在實際作業中發現誤判、幻覺，以及無法辨識新型威脅等問題。

SANS建議企業持續檢驗AI系統表現，盤點使用中的AI工具、模型用途及資料存取情形，並將審查、核准及稽核機制納入日常作業，同時強化人員檢查AI輸出及必要時介入處理的能力。

'

微軟甫修補的SharePoint重大漏洞已被用於實際攻擊

來源：https://www.ithome.com.tw/news/177382

美國網路安全與基礎設施安全局（CISA）將CVE-2026-58644加入已遭利用的漏洞列表（KEV），此為SharePoint重大等級漏洞，CVSS評分達到9.8

'

G7提出金融業PQC轉型路線，以2035年為整體參考目標

來源：https://www.ithome.com.tw/news/177380

網路資安業者Forescout解析G7網路專家小組（Cyber Expert Group）今年1月發布的《金融業量子整備路線圖》（Quantum Readiness Roadmap for the Financial Sector）。這份發展藍圖的推出，可供金融機構、主管機關，以及支援關鍵金融服務的技術供應商與基礎設施營運商參考，用來規畫後量子密碼學（PQC）轉型。

G7將後量子密碼轉型分為6個階段，包括風險認知與準備、探查與資產盤點、風險評估與規畫、執行PQC轉型、轉型測試，以及驗證與持續監控。組織應先取得高階主管支持，盤點關鍵系統與敏感資料、各系統採用的密碼演算法與通訊協定，以及對第三方產品與服務的相依關係，再依系統重要性與曝險程度決定轉型的優先次序。

在時程方面，G7指出，各國主管機關、國際標準組織，以及國際清算銀行、世界經濟論壇等國際機構的現行規畫，多以2035年作為整體PQC轉型的參考目標，最關鍵系統則可優先在2030年至2032年間推動PQC遷移。金管會今年6月發布《金融業後量子密碼遷移參考指引》，同樣建議金融機構以2035年作為完成高風險系統PQC遷移的長期目標。

Forescout指出，G7強調採用量子安全技術並非一勞永逸，密碼演算法與標準仍會持續演進，也可能出現新的安全漏洞。組織應讓系統具備密碼學敏捷性（Crypto-Agility），避免將特定密碼學演算法寫死在基礎設施中，使系統日後不必重新設計整體架構，就能更換演算法，並在轉型期間支援混合式密碼學技術。

'

CISA要求聯邦機構緊急修補Oracle EBS重大漏洞

來源：https://www.ithome.com.tw/news/177379

iThome資安新聞編輯團隊溫馨提醒

擔心錯過重要的資安新聞嗎？資安日報與資安週報即日起推出免費電子報訂閱，每天每週直送資安要聞，提供專業、易懂、便於轉述的最佳中文資安情報，助你掌握全球與臺灣最新資安脈動。

'

德國開源主權AI模型Soofi S，主打高效率、長文本推理能力

來源：https://www.ithome.com.tw/news/177378

德國研究聯盟Soofi-Team本周公布開源Mamba–Transformer混合專家（mixture-of-experts，MoE）模型Soofi S 30B-A3B，為歐洲推動主權AI的最新專案。

SOOFI（Sovereign Open Source Foundation Models）是德國聯邦經濟和氣候保護部（BMWK）資助、在德國聯邦AI協會（KI Bundesverband）協調下，由歐洲知名的弗勞恩霍夫（Fraunhofer）研究所、DFKI等德國產學界多個機構組成的「Soofi-Team」開發的開源基礎大語言模型。它全程在德國電信慕尼黑營運的主權HPC AI基礎架構German Industrial AI Cloud上訓練開發。旨在提供一個在美國和中國模型之外由歐洲主導的開源模型給業界使用，主打強大推理和AI代理能力。

Soofi S採用Mamba–Transformer混合的混合專家（MoE）架構，類似Nvidia Nemotron，提供英文和德文版本。其混合設計下，每個token運算時僅啟動300億參數中的30億個，在脈絡增長時推論快取幾近保持不變（near-constant），這使它具備長文本的推論效率，在長脈絡、高併發（high-concurrency）環境下處理效能優於稠密模型。例如，Soofi S的每秒解碼token數（TPS）是傳統稠密模型（如14B到24B模型）的8到9倍，且在4K到256K的上下文長度下，吞吐量依然能保持平穩。

另一方面，Soofi S主打英、德語能力。Soofi S預訓練階段刻意為德文語料加權，以約27兆token進行訓練。開發團隊綜合英、德文的標竿測試中，Soofi S效能可比擬140億至270億參數的稠密模型（如Gemma 3 27B），而在混合英、德文的程式撰寫測試中，是17個開源模型（如EuroLLM、Apertus、Salamandra等）最佳，在英、德文中，Soofi S也取得全開源模型最高評分，超越Olmo 3 32B和Apertus 70B。甚至和知名模型如Nemotron 3 Nano （30B-A3B）及Mistral 3 14B、Qwen 3.5 （35B-A3B）及Gemma 3 27B相比，Soofi S在程式撰寫（英／德文）及數學（英／德文）項目拿下第一，而在MMLU、GPQA測試也拿下第二，僅落後Qwen 3.5。

Soofi S以高度寬鬆的授權開源，除了權重，訓練中間檢查點（Intermediate Checkpoints）、訓練與評測程式碼、超參數、特定過渡檢查點也都開源。此外，Soofi-Team也公開完整的預訓練語料庫統計數據與數據構建腳本，詳細列出各語言和數據源的比例，方便社群進行稽核與重現研究結果（reproduce）。

英文版Soofi-S可在Hugging Face上取得。

'

Google為ChromeOS修補逾300個第三方元件與瀏覽器漏洞，其中21個為重大等級

來源：https://www.ithome.com.tw/news/177377

Google於7月16日發布電腦版與Android版瀏覽器更新，與前一次修補相隔僅兩天受到關注。值得留意的是，同一天他們也對作業系統ChromeOS與ChromeOS Flex進行修補，發布16700.46.0穩定版更新，並升級瀏覽器為150.0.7871.150版，總共解決346個漏洞，這些問題存在瀏覽器與於第三方元件，其中有309個為瀏覽器弱點。

從漏洞的危險程度來看，有21個是重大等級、98個為高風險等級。根據漏洞的類型來看，記憶體使用後再存取利用（UAF）比例最高，有76個，元件不當實作居次，有63個。再者，不受信任的輸入未經充分驗證，以及政策未充分執行型態的弱點，分跑有44與42個。

'

Moonshot AI發表Kimi K3，效能逼近Claude與GPT最新模型

來源：https://www.ithome.com.tw/news/177376

中國AI業者Moonshot AI周四（7/16）發表最新模型Kimi K3。該模型採用混合專家架構，總參數量達2.8兆，號稱是目前全球參數規模最大的開放模型，支援100萬token脈絡長度，並在多項程式開發、代理人、推理及視覺測試中達到Claude Fable 5與GPT 5.6 Sol等頂尖模型水準。Kimi K3已透過Kimi、Kimi Work、Kimi Code及API提供，完整模型權重預計於7月27日釋出。

Moonshot AI將Kimi K3定位為「前沿智慧」（Frontier Intelligence）基礎模型，主要能力涵蓋程式開發、代理人、知識工作、推理及多模態理解，並強調可在較少人工介入下持續執行長時間、多步驟任務。

在技術架構上，Kimi K3採用Kimi Delta Attention（KDA）、Attention Residuals（AttnRes）及Stable LatentMoE等新架構，並進一步提高混合專家的稀疏程度，在896個專家中每次僅啟用16個。Moonshot AI表示，相較於前一代Kimi K2，新架構可將整體擴展效率提升約2.5倍，更有效率地將運算資源轉化為模型能力。

Moonshot AI展示多項Kimi K3的實際應用案例，包括自主最佳化GPU核心、從頭打造GPU編譯器、設計執行AI模型的晶片，以及完成互動式產業研究報告、重力波分析與影片剪輯等任務。其中，Kimi K3僅花約2小時便重現一項原本需資深研究人員花費1至2周完成的計算天文物理研究，展現其長時間自主執行複雜任務的能力。

在基準測試方面，Kimi K3在程式開發、代理人、推理及視覺四大類評測皆躋身第一梯隊。其中，程式開發能力與Claude Fable 5、GPT 5.6 Sol互有領先；代理人能力雖整體仍略遜於兩者，但在部分搜尋與自動化任務已取得領先表現；推理與視覺能力則與Claude及GPT最新模型維持相近水準。

在代表性測試中，Kimi K3於評估終端工程任務能力的Terminal Bench 2.1取得88.3分，僅次於GPT 5.6 Sol的88.8分，並高於Claude Fable 5與Claude Opus 4.8的84.6分；在衡量AI代理人完成一般知識工作能力的GDPval-AA v2中則取得1668分，落後Claude Fable 5與GPT 5.6 Sol，但領先Claude Opus 4.8、GPT 5.5及GLM-5.2。

Kimi K3現已整合至Moonshot AI旗下聊天服務Kimi、知識工作平臺Kimi Work、AI程式開發工具Kimi Code及Kimi API。Kimi API的快取命中輸入、一般輸入與輸出價格，分別為每百萬token 0.3美元、3美元及15美元；Moonshot AI表示，程式開發工作負載的快取命中率可超過90%。

英國金融時報（Financial Times，FT）則分析，Kimi K3的推出可能動搖中國前沿AI模型在效能上落後美國8至12個月的業界共識，此外，隨著美國模型服務價格上升，已有愈來愈多美國及歐洲企業為降低AI使用成本，轉向價格較低的中國模型。

'

可口可樂旗下乳品公司遭勒索軟體攻擊，美國生產作業停擺

來源：https://www.ithome.com.tw/news/177375

飲料巨擘可口可樂旗下乳品公司fairlife本周遭到勒索軟體攻擊，迫使全美工廠暫停運作。

fairlife是可口可樂旗下乳品生產子公司，主打以極濾技術提供比普通牛奶更多蛋白質、少50%糖分的強化乳品。根據維基百科，fairlife在美國製造商分別位於密西根、亞利桑納州及紐約州，另有一座位於加拿大安大略省。

根據可口可樂向美國證管會（SEC）提交的報告，fairlife於7月16日發現在一次和勒索軟體有關的事件中，第三方行為者未授權存取了公司部分系統，包括和生產相關的系統。該公司立即啟動事件回應措施及業務永續程序，並在外部顧問及資安專家協助下展開調查，也通知了執法單位。

雖然公司產品品質和安全未受影響，但勒索軟體事件導致fairlife美國生產運作暫時中止。加拿大生產目前未受影響。該公司目前正著手調查並致力於恢復系統和產線運作。fairlife表示目前還在調查事件屬性及整體後果，因而尚未能判斷事件對公司業務的影響。

fairlife並未對媒體透露是否有任何資料被竊、或是公司是否遭到勒索。目前也沒有勒索軟體組織出面聲稱是其所為。Bleeping Computer分析，若勒索軟體竊得資料，很快就會公開並要求聯繫，除非受害者支付贖金。

'

Google發布Chrome 150更新，修補3個重大等級漏洞

來源：https://www.ithome.com.tw/news/177374

自6月底Google發表Chrome 150大改版之後，已經進行兩次修補，值得留意的是，在本週二發布更新之後，短短兩天該公司又再修補一批新漏洞。

7月16日Google發布電腦版與Android版更新150.0.7871.128、150.0.7871.129，總共修補7個資安漏洞，全部都是與記憶體有關的問題，大部分屬於記憶體釋放後再存取使用（UAF）型態的弱點。從危險程度來看，有3個是重大等級，其餘為高風險等級。這些重大等級漏洞皆由Google自行發現，存在於CameraCapture、GPU、Network元件，都是記憶體釋放後再存取使用類型的弱點，登記為CVE-2026-15899、CVE-2026-15900、CVE-2026-15901。

'

Agent安全即Runtime安全！奧義智慧揭露代理式AI的關鍵風險

來源：https://www.ithome.com.tw/news/177369

迎向Agentic Workflow時代，企業在追求自動化效能的同時，伴隨而來的資安風險已成轉型首要挑戰。在CraftCon Taiwan 2026資安技術研討會上，奧義智慧資料科學研發處長楊政霖直言：「Agent Security本質上就是Runtime Security。」他並闡釋公司團隊研究人員歸納出的12種關鍵風險，以及Agent工具呼叫軌跡的評測基準TraceSafe-Bench，協助企業釐清Agent時代面對的挑戰。

Agent風險存在於執行的每一秒，追蹤執行軌跡至關重要

現在許多企業已經積極編列預算，投入大量運算資源，致力導入Agentic AI以優化業務流程。然而，在追求生產力紅利的同時，Agent的資安防禦思維必須同步升級。

楊政霖強調，大家對於Agent的資安風險要有清楚的認識，因為Agent風險存在於執行的「每一秒」，並非只有檢查AI最後給出的答案是否正確。在執行過程中，Agent可能早已觸發惡意工具呼叫或導致機密外洩。因此，追蹤執行軌跡比檢視最終答案更為重要。

針對這類難以偵測的中途執行軌跡（mid-trajectory）風險，楊政霖在演說中特別介紹今年4月出爐的一篇論文《TraceSafe: A Systematic Assessment of LLM Guardrails on Multi-Step Tool-Calling Trajectories》，指出這是由奧義智慧AI Lab與臺灣大學的研究人員共同發表。當中針對Agent工具呼叫（Tool-Calling）的威脅面，系統化歸納為4大領域、12個細項類別，並提出相應的評測基準TraceSafe-Bench，讓大眾能更瞭解Agent在複雜任務中的安全現況。

簡單來說，TraceSafe研究將Agent執行的風險畫分為4大領域：提示注入、隱私外洩、幻覺以及介面不一致。

首先是提示注入，可分為兩種風險類型：「輸入注入」是指有惡意或錯誤指令隱藏在工具描述（tool definition）中，誘導Agent執行非預期動作；「輸出注入」則是當Agent接收到工具回傳值（tool response）後，受其內容誤導而產生如重設系統等具破壞性的後續指令。

第二個領域是隱私外洩，可分為3種風險類型，其中「資料外洩」、「使用者資訊外洩」一直是企業相當重視的核心資安議題，還有「API Key外洩」的潛在威脅同樣不容忽視。楊政霖以API hijacking案例說明，攻擊者可能表面上發起get_weather函式的呼叫請求，實則在指令中暗藏陷阱，誘導Agent將私密的API Key填入參數欄位。

第三個領域是幻覺，共畫分5種語義模糊或幻覺相關的風險，當中常見的類型包含：「參數定義模糊」、「工具名稱幻覺」與「參數值幻覺」，其餘則為「冗餘參數」與「缺少型別提示」。楊政霖特別以「參數定義模糊」為例指出，若是工具定義（schema）不夠嚴謹，像是醫療場景中要求派發「1顆500mg退燒藥」時，Agent可能因無法精確區分數量與劑量參數，誤將500mg的劑量數值填入數量欄位，導致發放藥量從1顆暴增至500顆。

第四個領域是介面不一致，其中「版本衝突」是大家最容易忽略的部分，例如，當同時存在payment V1、V2兩個API，Agent可能呼叫到錯誤的API；「功能描述不符」也是此場景常發生的問題，楊政霖指出，若開發端在撰寫工具描述（function description）時過於簡略，將導致不同功能的語義特徵在語言模型中顯得過於接近，使其難以精確辨識差異而引發錯誤呼叫。

針對企業評估AI護欄提出四個核心思維

在建立這套風險框架後，研究團隊進一步建置TraceSafe-Bench評測基準，把12類風險轉成可逐步驟檢驗的測試案例，並測試市面上20種主流模型與AI護欄（Guardrail）方案。測試結果顯示，現有方案對多步驟工具呼叫的防護仍明顯不足。相較於單純的語意過濾，結構化軌跡的異常判定難度更高，且部分風險類別極難被有效阻擋。

面對這樣的現況，楊政霖整理出企業評估AI護欄時可思考的四個關鍵問題：

首先，能否看見Agent完整脈絡？AI護欄必須掌握工具清單、當下呼叫內容、先前輸出與整體流程，而非只看最後答案。

其次，Agent能否理解JSON與工具schema？許多方案擅長過濾聊天內容中的有害文字，卻難以從JSON格式的工具呼叫紀錄中，辨識參數錯誤、描述矛盾等細微異常。

第三，能否在工具被呼叫之前就攔截惡意？楊政霖強調，Agentic Security的關鍵在於執行時期防護；若只在工具執行後才審查，惡意呼叫或資料外洩可能早已發生。

第四，能否涵蓋四大風險領域？在審視AI護欄能力時，防護範圍應同時覆蓋提示注入、隱私外洩、幻覺與介面不一致。

最後，楊政霖也建議企業可進一步參考論文TraceSafe中的實驗數據。這項研究中有幾項值得留意的發現，例如，AI護欄的成效與其理解JSON、工具schema的結構化能力高度相關，未必與模型參數規模成正比；部分風險在執行步驟較長的軌跡中反而較易被察覺；而介面不一致這類開發端常忽略的問題，仍是現有方案最薄弱的環節。

'