第三方 AI Skill 與 MCP Server 怎麼審？別人寫的擴充，可能借走你手上的資料權限
資安公司 Snyk 在 2026 年 2 月稽核了兩個公開市集上的 3,984 個 AI Skill，其中 36.82% 至少帶著一項安全問題。第三方 Skill 夾得了可執行腳本，第三方 MCP Server 是別人寫的程式，裝一個等於在自己的工作環境裡多開一條路。這篇給零售品牌主一套可執行的審查判準：裝之前問什麼、誰有權限裝、哪些情況必須拉資安進來、下架之後還要收回什麼。
行銷團隊手上的是會員資料，不是玩具資料。安裝那五分鐘沒有留下紀錄，之後就查不回來。
Snyk 掃了 3,984 個公開 Skill，其中 1,467 個帶著安全問題
資安公司 Snyk 在 2026 年 2 月 5 日發表了一份針對 AI Agent Skill 生態的稽核，掃描範圍是兩個公開市集上的 3,984 個 skill。結果是 36.82%，也就是 1,467 個 skill，至少有一項安全問題；其中 13.4%（534 個）帶有至少一項嚴重等級的問題；再往下，有 76 個被人工複核確認帶有惡意內容。這份報告發表的當下，那 76 個裡面還有 8 個公開掛在市集上，任何人都能下載。
先說清楚這組數字的邊界：它來自 Snyk 對這兩個市集在那個時間點的抽樣，能說明的是這批樣本，不能外推成所有 skill 市集的比例，更不能直接套到 MCP server 身上。即使如此，超過三分之一這個量級足以說明一件事：品牌不能靠「避開少數壞蘋果」來處理這個問題。
這些東西長什麼樣子？一個資料夾，裡面一份純文字說明檔，可能再附幾個腳本。沒有安裝精靈，沒有數位簽章提示，沒有「這個程式想要存取您的通訊錄」那種灰底對話框。企業買軟體有採購流程，資訊部門會問資料放哪、合約怎麼簽、出事找誰，但「裝一個擴充」不在那條流程上，這個決定每天發生在行銷團隊的個人電腦裡。
我們擔心的不是有人裝了東西，是沒有地方查得到
我們看這份稽核報告時，腦中浮現的是一個很普通的畫面。某個週三下午，行銷群組裡有人貼了連結，說這個超好用、一鍵就裝好；五分鐘之內，三個同事都裝上了。三個月後有人問「這個是誰裝的、現在還在用嗎」，多半只會換來沉默。
我們替品牌處理會員資料很多年，看過的外流成因多半不驚悚，就是這種很普通的畫面。真正讓我們擔心的，是出事的時候沒有一份清單可以翻。
安裝擴充的時候，權限是怎麼跟著移動的
第三方擴充目前主要有兩種形態。Agent Skill 是一個資料夾，裡面放一份叫 SKILL.md 的純文字說明檔，告訴 AI 助理某項任務該怎麼做，可以附帶腳本與參考文件。MCP Server 則是一支實際在跑的程式，負責把 AI 助理接到某個資料庫、系統或外部服務。兩者的差別我們寫過一篇入門可以先補。
這兩種東西在權限上的行為不一樣，混為一談會導致錯誤的判斷。大致分成三類：
純文字的 skill 本身不執行程式，影響的是 AI 助理怎麼運用手上既有的工具，風險落在指令層，也就是它寫了什麼、要 AI 去做什麼。
附帶腳本的 skill，以及裝在自己電腦上跑的 MCP server，是實際會執行的程式。執行時用的通常是啟動它的那個帳號的權限，你的電腦碰得到的檔案與網路，它多半也碰得到。
遠端的 MCP server 是別人的服務。它拿到的是你的用戶端實際送出去的資料，以及你在授權畫面上點頭同意的範圍，而那個範圍常常沒人看清楚就按下去了。
所以安裝不是一次把所有權限交出去，比較像是打開幾條之後可能被走的路。安裝、啟用、載入指令、呼叫工具、完成授權、真的傳出資料，這些步驟往往分開發生，而中間每一步都不會再問你一次。
| 你以為裝的是 | 可能實際開啟的 |
|---|---|
| 一份告訴 AI 怎麼做事的說明書 | 一段會進到 AI 工作脈絡、被當成自己人指令看待的內容 |
| 一個獨立運作的小工具 | 一條借用你帳號權限執行、或代你向外部服務要授權的通道 |
| 一次性的方便 | 一條沒有版本控管、沒有下架流程、沒有人負責的相依關係 |
從官方規格到公開稽核，這條供應鏈的風險已經有據可查
官方規格本身就寫明，skill 可以夾帶可執行的程式碼
Agent Skills 的公開規格把一個 skill 定義成一個資料夾，裡面必須有 SKILL.md，另外三個是選用目錄。其中 scripts/（程式腳本資料夾）的說明白紙黑字寫著「Contains executable code that agents can run」，也就是 AI 助理可以直接執行的程式碼。規格裡還有一個標示為實驗性的欄位叫 allowed-tools，作用是預先指定這個 skill 可以動用哪些工具，是否生效視各家產品的實作而定。值得注意的是，這份宣告寫在檔案裡，是作者填的，你按下安裝的時候它跟著進來。
提供這套格式的公司，自己在文件裡放了警告
Anthropic 在介紹 Agent Skills 的工程文章裡，同一頁就放了安裝建議：「We recommend installing skills only from trusted sources. When installing a skill from a less-trusted source, thoroughly audit it before use.」翻成白話，只從可信來源安裝；來源沒那麼可信的，用之前要徹底稽核過。同一份文件也提醒要檢查 skill 的程式相依性、附帶的資源檔，以及有沒有指示 AI 去連外部來源的內容。
這段話值得零售品牌的行銷主管讀兩次。它是提供這套格式的公司自己寫的使用說明，而「thoroughly audit it before use」預設的執行者，是一個看得懂程式碼的人。
稽核的結果顯示，問題散布在整批樣本裡
回到 Snyk 那份報告。除了前面的比例，另一個數字是 2026 年 2 月 5 日的掃描中，其中一個市集的樣本有 10.9% 被偵測到寫死的金鑰、密碼或其他機密資訊。這類發現包含作者不小心留下的，也包含刻意埋進去的，來源沒有區分兩者的比例。
「有安全發現」不等於「已經被利用」，這組數字說的是暴露面，不是災情。品牌要從裡面讀出來的訊息在分布：問題不集中在少數幾個項目上，個案式的閃避幫助有限，得靠流程。
市場正在補，但補的位置分散在三端
登錄站這一端，Snyk 與 skill 登錄站 Tessl 在 2026 年 3 月宣布合作，讓 Tessl Registry 上的每一個公開 skill 都帶著一個安全評分，把套件管理器那套信任訊號搬進 skill 生態。這只涵蓋該登錄站，不是所有市集都有。
企業身分管理這一端，MCP 官方在 2026 年 6 月 18 日發表了 Enterprise-Managed Authorization 擴充，開頭講的問題非常直白：「Every employee has to authorize every server individually」以及「Security teams cannot enforce consistent policy」。每個員工各自去授權每一台伺服器，資安團隊沒辦法執行一致的政策。這個擴充把「哪些 server 被允許、誰可以用、什麼時候收回」搬回企業原本的身分供應商（公司用來管員工帳號與權限的系統）。要用得上有前提：用戶端、server 與身分供應商三方都要支援，公告當時首先支援的身分供應商是 Okta。用戶端這一端則是各家產品自己的安裝確認與沙箱設定，程度差異很大。
三端指向同一個判斷：解法不在「叫每個使用者更小心」，在把安裝與授權變成組織層級的、有紀錄的決定。至於自家團隊寫的 skill 該怎麼維護、怎麼從個人玩具變成團隊資產，是另一條線的功課，我們另外寫過一篇。
這是舊的軟體供應鏈風險，換上了一個人畜無害的外殼
軟體供應鏈風險講了十幾年：你的系統依賴別人寫的套件，別人的套件被動了手腳，你的系統跟著中招。OWASP 在 LLM 應用安全風險清單裡，把供應鏈列為 LLM03:2025，明文點出第三方元件、供應商來源證明薄弱、授權條款不清這幾類風險，並建議品牌要查供應商條款、維護元件清冊、驗證來源、持續監控並訂出更新政策。這幾條建議放在第三方擴充上完全適用。
那為什麼還要專門寫一篇？因為載體換了之後，原本的三條防線各自出現破口。
掃描這條線的破口在覆蓋範圍。只比對已知漏洞編號與程式碼樣式的工具，讀不出自然語言指令裡的意圖。要抓得到，需要能同時看指令內容、腳本、相依套件與對外連線的工具，Snyk 那份研究本身就是這樣做的，但這類工具是近一年才出現，多數品牌的資安流程還沒接上。
採購這條線的破口在門檻。買一套系統要走簽核，裝一個擴充不用；門檻低到不需要工程師參與，也就意味著沒有工程師會看到。
權限這條線的破口在繼承。傳統元件跑在系統裡，權限是系統配給的；附腳本的 skill 與本機 MCP server 借用的是使用者的權限，而那個使用者往往是手上資料最多的人。這一層我們談過，當 AI 開始以「非人類身分」在系統裡活動，權限與稽核紀錄要怎麼跟著它走，是治理層要先想清楚的事。
再看規模。Anthropic 在 2025 年 12 月 9 日把 MCP 捐給 Linux Foundation 底下的 Agentic AI Foundation 時，公告裡寫的是公開 MCP server 已超過 10,000 個，SDK 每月下載量超過 9,700 萬次；九天後的 2025 年 12 月 18 日，Agent Skills 被發布為開放標準，同一份 SKILL.md 可以被多家客戶端讀取。安裝的成本降到幾乎為零，資料的價值沒有跟著降，中間那段落差就是風險。
還有一個容易混淆的地方。MCP 官方也有一份安全最佳實務文件，內容相當完整，但它開宗明義寫了受眾：實作授權流程的開發者、MCP server 的營運者、評估 MCP 系統的資安專業人員。這份文件不是寫給行銷團隊看的，可是在多數台灣零售品牌裡，按下「連接」那個按鈕的人就是行銷團隊。
縮小資料範圍不等於免疫，但那是品牌自己說了算的一段
到這裡，多數人會得到一個結論：那就一個一個審吧。我們的經驗是這條路走不遠。行銷團隊沒有能力逐行讀腳本，也沒有時間；擴充還是持續增加，今天審完，下週又多三個。把品質壓在每一次的個人判斷上，遲早會漏。
要換一個問法，得先把「最壞後果」拆清楚。它由四個條件共同決定：這個擴充讀得到哪些資料、它能執行哪些動作（只能讀，還是能寫、能刪、能發訊息、能動金流）、它能把東西送到哪裡去，以及它拿到的權限會存活多久。資料範圍只是其中一個條件，卻是品牌完全說了算、也最容易先動的那一個。
這正是顧客資料平台在這件事上的位置。當會員資料散在各處，行銷同事的桌面有一份匯出的名單、廣告投手的雲端硬碟有另一份、客服系統裡還有一份聯絡資料，那麼任何一個擴充碰到的都是完整母體，而且沒有人知道它碰過。當分群與名單的產出集中在一個有帳號權限層級的平台裡，「誰在什麼權限下取得了什麼」才變成可管的事。
91APP CDMP 在客戶那邊的實務作用大致是這樣。線上線下的消費紀錄先做 OMO 歸戶，變成單一的會員身分；之後的分群與受眾產出都在平台裡完成，符合條件的名單可以直接送到通路端使用，例如一鍵傳送到 LINE 官方帳號的後台，不必每次都先落地成一份檔案再手動上傳。平台本身仍支援多種名單下載格式，實際可匯出的範圍依功能與帳號權限而定；重點在於「什麼時候必須下載、下載給誰、下載完放哪裡」從隨手動作變成有邊界的決定。少掉那些散落各處的匯出檔，第三方擴充能碰到的範圍就少了一塊。
另一半是責任歸屬。名單用錯了該算誰的、資料從哪來、誰核准的，這些問題平常沒有答案，出事的時候更不會有。我們專門寫過一篇談資料責任沒人認領這個坑，那裡的觀察放在第三方擴充上同樣成立：治理卡住的地方通常不在技術，在沒有人被指定要回答那個問題。至於 AI 應用已經走到會自己執行任務的階段時，執行環境要不要與正式資料隔離，是更前面的設計題，91APP 在 AgentOne 這一側的做法是資料獨立加上 Sandbox 執行環境，細節我們另外寫過。
把裝擴充從個人決定變成有紀錄、有分流的決定
以下是我們建議台灣零售品牌可以先動的幾件事。多數起步動作不需要工程團隊，但其中有一條刻意把資安拉進來，因為有些情況真的擋不住。
- 收回安裝權，指定具名的核准人。不禁止使用，但工作用的 AI 帳號要裝擴充得先提申請，由少數幾個人核准。預期效果是把擴充清單從不可知變成可知；建議週期是第一週盤點目前每個人裝了什麼，之後每月更新。
- 依風險分兩條路，不要一套標準走到底。只讀公開資料、不連外、沒有腳本的，走業務單位快審。碰到會員個資、可以寫入或刪除、會對外傳送資料、附帶腳本或需要金鑰的，一律要有資訊或資安同仁參與；驗不出來的就不接正式資料，先在測試環境用假資料跑。預期效果是把有限的審查人力花在真的會痛的那一類；建議週期是每次新增時判斷，分流規則寫成一頁貼在內部文件裡。
- 走快審那條路的，先要三個可查的答案：維護者是誰（具名的組織或個人，不是一個帳號代號）、它會連到哪些外部位址、它需要碰哪些資料。有一題答不出來就先不裝。另外把版本記下來，維護者換人或版本更新時重審一次，因為你當初審的是那個版本。預期效果是擋掉來源不明與悄悄換手的擴充；建議週期是每次安裝與每次更新。
- 把兩種紀錄分開留。人工清冊記來源、版本、核准範圍、核准人、安裝日期，一份共用文件就夠開始；實際存取紀錄要從 AI 產品、MCP server、帳號管理系統與資料平台的日誌去看，人工清冊證明不了「它真的讀了什麼」。這跟個資法修正後品牌要能說清楚資料從哪來是同一件事的兩面。預期效果是出事時查得回去；建議週期是清冊即時更新，日誌每季確認一次調得出來。
- 下架不等於收回。移除一個擴充之後，先前給過的授權、API 金鑰、背景執行的程序可能還有效，已經傳出去的資料更收不回來。停用之後要跟著撤銷授權、輪替金鑰，並保留一份調查用的紀錄。預期效果是縮小長期暴露面；建議週期是每季清一次超過兩個月沒用到的擴充，順手把權限收掉。
那五分鐘，決定了誰碰過你的會員名單
回到週三下午那個群組訊息。那五分鐘裡發生的事，其實是一次沒有紀錄的採購。
一份純文字檔沒有重量，讀起來像備忘錄，裝起來像貼一張便利貼。可是它替自己開的那條路有重量，路的另一頭是你花很多年、很多預算、很多客服對話累積起來的會員資料。這兩件事的落差，是目前多數品牌還沒補上的那一塊。
補起來不必一步到位。先讓清單存在、讓核准有人具名、讓高風險那一類走不同的路，剩下的可以慢慢長。等到有人問「這個是誰裝的」，你答得出來。
品牌最常問的第三方 AI 擴充審查問題
Q1：第三方 AI Skill 是什麼？跟裝一個瀏覽器外掛有什麼不一樣？
A1：Skill 是一個資料夾，裡面至少有一份叫 SKILL.md 的純文字說明檔，告訴 AI 助理某項任務怎麼做，也可以附帶可執行的腳本、參考文件與範本。跟瀏覽器外掛的差別在兩點。瀏覽器外掛安裝時會列出它要的權限，而 skill 沒有統一的權限清單可看，附腳本的那一類執行時通常用的是啟動它的帳號的權限。另外，外掛的內容是程式碼，一般掃描工具讀得懂；skill 的核心是自然語言寫的指令，只比對已知漏洞與程式碼樣式的工具會漏掉它。
Q2：這跟 AI Agent 平台選型的資安檢查是同一件事嗎？
A2：不是同一個階段。平台選型的資安檢查發生在採購前，看的是模型、資料存放、治理機制這些平台層的條件，通常一年做幾次。第三方擴充的審查發生在採購之後，是每天都在發生的行為，看的是「今天要不要讓這個外來的東西進來」。兩者要分開設計流程，選型檢查表擋不住每天新增的擴充。
Q3：行銷團隊沒有工程師，要怎麼審一個第三方擴充？
A3：先分流，不要用同一套標準審全部。只讀公開資料、不連外、沒有腳本的，用三個非技術問題當門檻就夠：維護者是誰、它會連到哪裡、它需要碰哪些資料，有一題答不出來就先不裝。碰到會員個資、可寫入、會對外傳送資料或附帶腳本的，這三題不夠，必須有懂技術的人看過；找不到人看，就別讓它碰正式資料，先用假資料在測試環境跑。
Q4：預算有限的小品牌做得到嗎？
A4：起步的成本主要是紀律不是預算。列一份「誰可以裝」的名單、開一份共用文件記來源與版本、每季清一次沒在用的擴充，這些都不需要採購新工具。真正需要外部協助的是高風險那一類，而小品牌可以把策略設成盡量不讓擴充碰到那一類資料，用範圍換掉審查成本。
Q5：從開始管到看得到效果，大概要多久？
A5：以下是建議目標，實際會依團隊人數、工具數量與日誌完整度而不同。盤點現有擴充、產出第一份清單，通常一到兩週做得完；分流規則與核准流程穩定下來，多半要一到兩季，因為需要團隊習慣「先問再裝」。風險有沒有下降短期看不到訊號，這類治理的成效體現在事情發生時查得到、收得回。
Q6：關於第三方擴充風險，最常見的誤解是什麼？
A6：最常見的誤解是把它當成純技術問題，交給資訊部門就好。實際上按下安裝鍵的是業務單位，被暴露的是業務單位手上的顧客資料，資訊部門往往連清單都拿不到，所以第一步是業務與資訊共同維護一份擴充清冊與分流規則，讓兩邊看同一份東西。另一個常見誤解是覺得「知名的市集應該有審過」。目前只有部分登錄站提供安全評分，上架本身不等於背書。