技術分享
AI 卓越中心 vs. 傳統 IT 部門:為何 AI CoE 不能附屬於 IT?
許多企業將 AI CoE 設在 IT 部門下,但這個選擇往往限制了 AI 員工的推廣力道。本文解析 AI CoE 應該獨立設置的五大原因。
深入了解專業知識與最新技術趨勢
MCP(Model Context Protocol)在過去一年成為 AI Agent 連接企業系統的事實標準,讓 Agent 能直接查資料庫、發信件、改程式碼。但 2026 年 5 月,美國國家安全局(NSA)罕見地針對這個單一協定發布安全指引《Model Context Protocol: Security Design Considerations for AI-Driven Automation》,開宗明義指出:MCP 的採用速度已超過安全防護機制的發展,許多組織正暴露在協定設計者未充分預期的風險中。指引內容涵蓋存取控制、提示處理、工具執行權限、稽核性與第三方整合治理,並特別點名「不受控的自動化行動」與「缺乏輸入檢查」兩大風險。當國家級資安機構為一個問世不到兩年的協定專門出指引,代表這已不是理論風險,而是正在發生的事。
第一類是「受騙代理人(confused deputy)」。2026 年 7 月,資安公司 Manifold Security 揭露微軟官方 Azure DevOps MCP Server 的漏洞:攻擊者只要在 Pull Request 描述裡藏入一段網頁上看不見的 HTML 註解,當受害者請 AI Agent 審查該 PR 時,隱藏指令就會進入 Agent 的上下文並劫持它的目標——而 Agent 持有的是受害者的憑證,因此能觸及攻擊者原本到不了的專案、帶走裡面的資料。
第二類是「工具下毒(tool poisoning)」:把惡意指令埋在 MCP 工具的描述欄位裡,使用者在介面上看不到,模型卻會照做。2025 年 8 月發表的 MCPTox 研究以 45 個真實 MCP Server、20 個主流模型進行測試,攻擊成功率最高達 72.8%,且模型幾乎不會拒絕;微軟也在 2026 年 6 月正式警告此類攻擊可導致資料外洩。兩類攻擊的共通點是:問題不在模型不夠聰明,而在部署架構沒有設好信任邊界。
看懂攻擊型態之後,以下是把 AI Agent 接上內部系統前,企業應該逐項核對的五個面向:
這份清單的用法很直接:五個面向全部能打勾,才算通過部署前驗收;任何一項答不出來,就先暫停串接、補完再上。特別提醒,最常被跳過的是第二項——多數企業願意管權限,卻習慣性信任 Agent 讀進來的內容,而近期的實際攻擊幾乎都是從這個缺口進來的。
恩梯科技長期投入經營的開源 AI Agent 專案 OpenClaw,其技能市集 ClawHub 在 2026 年初也遭遇大規模惡意技能上架事件:資安業者清查後發現數百個偽裝成加密貨幣工具的惡意技能,企圖竊取使用者憑證。我們選擇正視而非迴避——這正說明開放生態的供應鏈治理是所有 Agent 框架的共同課題,也是為什麼 OpenClaw 在企業部署上特別強調權限紅線、技能來源控管與完整審計追蹤:框架本身是開放的,治理層必須由部署方嚴格把關。對正在評估開源 Agent 框架的企業,正確的解讀是:選型時把「治理功能是否完整」納入評估項目,而不是只看功能清單。
MCP 帶來的整合效率是真的,風險也是真的。正確的結論不是「先不要接」,而是把上面這份清單變成導入流程的驗收關卡:PoC 階段就用最小權限跑、上線前完成暴露面掃描與紅線設定、上線後持續審計。多數企業缺的不是工具,而是把資安納入 AI 專案時程的決心——在整合排程裡預留安全驗收的時間,遠比事故發生後重建信任便宜。恩梯科技的 AI 導入顧問服務即依此流程協助企業評估與部署,涵蓋 OpenClaw 與 MCP 整合的安全架構設計;若貴公司正準備把 AI Agent 接上內部系統,歡迎在動手之前,先讓這份清單替你把關。
技術分享
許多企業將 AI CoE 設在 IT 部門下,但這個選擇往往限制了 AI 員工的推廣力道。本文解析 AI CoE 應該獨立設置的五大原因。
技術分享
企業知識散落各處是規模化的最大障礙。本文提供三個步驟建立有效知識管理系統:從高價值知識開始盤點優先項目、設計讓知識真正被找到的搜尋架構、建立知識持續更新的機制,以及 AI 語意搜尋和自動知識提取如何讓知識管理升一個量級。
技術分享
中小企業不必一開始就導入昂貴的 ERP 系統,只要從取代一份 Excel 開始,就能有效轉型為可控、可查、可維運的資訊管理系統。