1. 從一次真實的 Plugin 事故說起Claude Code 的 Marketplace 機制讓第三方 Plugin 可以注入 Skills、Commands、Agents、Hooks、MCP Servers、LSP Servers 和 Scripts。能力能被加載不代表能力應該被無條件信任。一個 Plugin 可能只是提供代碼規(guī)范和文檔也可能攜帶可執(zhí)行 Shell 腳本、自動觸發(fā)的 Hook、遠程 MCP Server、本地 MCP 進程、具有工具權限的 Skill、擁有獨立執(zhí)行循環(huán)的 Agent。我見過一個團隊在內部倉庫里提交了.claude/settings.json里面聲明了enabledPlugins和extraKnownMarketplaces。新成員 Clone 倉庫后Claude Code 提示安裝 Plugin成員點了確認Plugin 里的 PostToolUse Hook 就開始在每次 Write/Edit 后自動執(zhí)行一個上傳腳本。沒有人顯式調用過這個 Hook它只是在生命周期事件里被觸發(fā)。問題不在于這個 Plugin 本身惡意而在于團隊沒有在落地前審查權限邊界。這篇文章面向的是準備在團隊里落地 Claude Code Marketplace 的工程師和平臺負責人。我會給出一份可復制的settings.json權限骨架一份供應鏈校驗清單以及逐步驗證動作幫你確認配置生效、風險收斂。核心檢索詞是 Claude Code 權限、安全、供應鏈治理、Marketplace。適合誰正在評估第三方 Plugin 引入流程的團隊、需要給 Claude Code 建立企業(yè)級來源控制的平臺工程師、以及想搞清楚 Skill allowed-tools 和 Hook 到底能做什么的開發(fā)者。2. 落地前的 TaoToken 前置準備在開始配置權限骨架之前你需要一個穩(wěn)定的模型接入點來驗證配置是否生效。TaoToken 提供 Claude Code 兼容的 API 接入官網(wǎng)地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端點是 https://taotoken.net/api 。如果你只是想在本地驗證權限配置和 Skill 行為用模型對話就夠了https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。如果你要長期跑編碼任務或 Agent 循環(huán)Coding Plan 更合適https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。接入文檔在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite API Keys 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。拿到 Key 之后你可以在 Claude Code 的配置里指向這個端點然后用它來測試 Skill 的 allowed-tools 是否按預期生效、Hook 是否在正確的生命周期觸發(fā)、MCP Tool 的權限規(guī)則是否被正確裁決。這一步的意義是你有一個可控的模型后端可以在不引入額外變量的情況下單獨驗證權限配置的行為。3. 可復制的 settings.json 權限骨架下面這份骨架覆蓋了來源控制、Plugin 信任、Skill 權限、Hook 限制和 MCP Tool 治理五個層面。你可以直接復制到項目的.claude/settings.json或用戶級的~/.claude/settings.json然后按團隊實際情況調整。3.1 來源控制strictKnownMarketplaces 與 disableSideloadFlags企業(yè)級來源控制的核心是strictKnownMarketplaces。它有三種狀態(tài)未配置時用戶可以添加任意 Marketplace空數(shù)組[]禁止添加所有 Marketplace來源列表則只允許精確匹配的來源。{ strictKnownMarketplaces: [ { source: github, repo: acme-corp/approved-plugins, ref: v2.0 } ], disableSideloadFlags: true }這里有幾個關鍵點。第一ref固定到具體 Tag 或 Commit SHA避免main分支內容變化導致供應鏈漂移。第二disableSideloadFlags阻止用戶通過單次 CLI 參數(shù)直接加載 Plugin 目錄、Agent 或臨時 MCP Server。第三Claude Code 會在 Marketplace 添加、Plugin 安裝、更新、刷新和自動更新之前執(zhí)行校驗而且 Managed Settings 不能被用戶或項目覆蓋。精確匹配意味著github.com/company/plugins、github.com/company/pluginsv2、github.com/company/plugins/path-a被視為不同來源。URL 尾部斜杠、.git后綴以及 SSH/HTTPS 形式也可能被視為不同來源。信任一個倉庫不等于信任倉庫中的所有 Branch、Tag 和子目錄。3.2 Plugin 信任extraKnownMarketplaces 與 enabledPluginsextraKnownMarketplaces用于向用戶推薦 Marketplace但它不是安全邊界。它解決的是分發(fā)便利性不是來源封鎖。{ extraKnownMarketplaces: { company-tools: { source: { source: github, repo: acme-corp/approved-plugins, ref: v2.0 } } }, enabledPlugins: { security-reviewcompany-tools: true, audit-hookscompany-tools: true } }項目可以在.claude/settings.json中聲明enabledPlugins但這不意味著其他團隊成員拉取倉庫后 Plugin 會在沒有確認的情況下直接運行。Claude Code 要求每條 Plugin 加載路徑都先讓用戶安裝并信任 Plugin。項目設置只能表達項目期望狀態(tài)不能替每個用戶完成信任決策。完整流程是項目聲明 Plugin用戶打開倉庫接受 Workspace TrustClaude Code 發(fā)現(xiàn)缺少 Marketplace 或 Plugin向用戶展示安裝和信任提示用戶確認Plugin 才進入本地 Cache 和 Runtime。這阻止了惡意倉庫提交.claude/settings.json后受害者 Clone 倉庫導致 Plugin 靜默安裝并執(zhí)行的攻擊路徑。3.3 Skill 權限allowed-tools 與 disallowed-toolsSkill 通過 Frontmatter 聲明allowed-tools和disallowed-tools。allowed-tools的作用不是新增底層工具而是讓指定工具在 Skill 被調用的當前 Turn 中無需重復請求用戶批準。--- name: commit description: Stage and commit current changes disable-model-invocation: true allowed-tools: - Bash(git status *) - Bash(git add *) - Bash(git commit *) disallowed-tools: - Write - Edit --- Review the current changes and create a commit.關鍵特點只在調用 Skill 的當前 Turn 生效下一條用戶消息后清除沒有列出的工具仍受普通 Permission Settings 管理不會刪除或隱藏其他工具。權限計算可以理解為Skill Temporary Grant ∩ Harness Permission Policy ∩ Sandbox Boundary 最終有效能力。對于需要運行自己目錄內腳本的 Skill使用${CLAUDE_SKILL_DIR}做精確授權allowed-tools: - Bash(${CLAUDE_SKILL_DIR}/scripts/render.sh *)這比Bash(*)安全得多因為它只預批準特定腳本而不是整個 Shell。3.4 Hook 限制allowManagedHooksOnly 與 HTTP Hook AllowlistHook 由生命周期事件自動觸發(fā)包括 SessionStart、PreToolUse、PostToolUse、Stop、SubagentStart、ConfigChange。它可以執(zhí)行 Shell Command、HTTP Request、LLM Prompt、Agent、MCP Tool。因此 Hook 更接近運行時 Middleware而不是普通上下文說明。{ allowManagedHooksOnly: true, allowedHttpHookUrls: [ https://audit.acme-corp.com/hooks/* ], httpHookAllowedEnvVars: [ AUDIT_TOKEN ] }allowManagedHooksOnly阻止用戶、項目和普通 Plugin Hook只保留 Managed Hook。由 Managed Settings 強制啟用的 Plugin其 Hook 可以作為已審查企業(yè)能力繼續(xù)運行。allowedHttpHookUrls和httpHookAllowedEnvVars分別限制 Hook 可以訪問哪些 URL、哪些環(huán)境變量允許插入 Header。這些 Allowlist 會作用于所有來源的 HTTP Hook包括 Managed Policy。3.5 MCP Tool 治理命名空間與權限規(guī)則Plugin MCP Tool 使用完整命名空間mcp__plugin_plugin_server__tool。該完整名稱可以用于 Permission Rule、Skill allowed-tools、Agent tools、Hook Matcher。{ permissions: { allow: [ mcp__plugin_github-tools_github__get_issue, mcp__plugin_github-tools_github__list_pull_requests ], deny: [ mcp__plugin_github-tools_github__delete_repository, mcp__plugin_github-tools_github__force_push ] } }這允許企業(yè)把同一 MCP Server 中的不同 Tool 分開治理。Plugin MCP Server 與手工配置的 Server 一樣可以訪問用戶環(huán)境變量包括DB_URL、GITHUB_TOKEN、AWS credentials、內部 API Token。因此企業(yè)不應只檢查 MCP 的 Tool 名稱還要檢查 Server Command、Server URL、Arguments、Environment Variables、Headers、Headers Helper、Transport Type。4. 逐步驗證配置生效配置寫完之后你需要逐步驗證每一層是否按預期工作。下面是我實測下來比較可靠的驗證順序。4.1 驗證來源限制先嘗試添加一個不在 Allowlist 里的 Marketplaceclaude marketplace add https://github.com/unknown-org/plugins如果strictKnownMarketplaces生效你應該看到拒絕提示而不是成功添加。然后嘗試添加 Allowlist 里的來源確認可以正常添加。注意檢查ref是否精確匹配v2.0和v2.0.0可能被視為不同來源。4.2 驗證 Workspace Trust在一個新 Clone 的倉庫里打開 Claude Code觀察是否彈出 Workspace Trust 提示。在接受 Trust 之前項目.claude/settings.json中的權限 Allow Rule、項目 Skill 中的allowed-tools、項目聲明的額外 Marketplace 都不應產(chǎn)生完整效果。接受 Trust 后這些配置才生效。你可以在~/.claude.json中查看每個項目的 Trust 狀態(tài)。用戶級配置位于~/.claude/settings.json、~/.claude/skills/、~/.claude/agents/這些文件通常由當前用戶自己維護默認信任級別較高不需要同樣的 Trust 流程。4.3 驗證 Skill allowed-tools 的單 Turn 生效創(chuàng)建一個測試 Skill聲明allowed-tools: Bash(git status *)。調用該 Skill觀察git status是否無需確認就執(zhí)行。然后在同一條用戶消息里嘗試執(zhí)行git push應該仍然需要確認。再發(fā)送下一條用戶消息再次嘗試git status應該重新需要確認因為 allowed-tools 已經(jīng)清除。4.4 驗證 Hook 限制如果allowManagedHooksOnly生效普通 Plugin 的 Hook 應該被阻止。你可以查看 Claude Code 的日志或 Hook 執(zhí)行記錄確認 Managed Hook 正常運行而第三方 Hook 被跳過。對于 HTTP Hook嘗試訪問不在allowedHttpHookUrls里的 URL應該被拒絕。4.5 驗證 MCP Tool 權限在/mcp中查看已安裝的 Plugin Server確認 Tool 名稱帶有完整命名空間。然后嘗試調用deny列表里的 Tool應該被拒絕。嘗試調用allow列表里的 Tool應該無需額外確認。如果 Tool 既不在 allow 也不在 deny應該走默認的詢問流程。5. 本篇常見錯排查5.1 strictKnownMarketplaces 配置了但沒生效最常見的原因是配置寫在了項目級或用戶級 settings.json而不是 Managed Settings。strictKnownMarketplaces需要在 Managed Settings 中配置才能保證用戶和項目無法覆蓋。另一個原因是ref不匹配比如 Allowlist 里寫的是v2.0實際添加的是v2.0.0或沒有指定 ref。5.2 Plugin 安裝后 Hook 沒有觸發(fā)先確認 Plugin 是否被正確啟用檢查enabledPlugins中的名稱和 Marketplace 后綴是否匹配。然后確認 Hook 的事件類型和 matcher 是否正確。如果allowManagedHooksOnly為 true普通 Plugin Hook 會被阻止這是預期行為。Plugin Hook 也會作用于 SubagentHook 輸入中會攜帶 Agent ID 和 Agent Type可以用來識別調用來源。5.3 Skill allowed-tools 沒有預批準檢查 Skill 的 Frontmatter 格式是否正確allowed-tools的縮進和列表語法是否合法。確認 Skill 被調用的當前 Turn 中工具名稱是否精確匹配。Bash(git status *)和Bash(git status)可能被視為不同規(guī)則。另外如果 Managed Policy 明確 Deny 某個命令Skill 的 allowed-tools 不能繞過企業(yè)策略。5.4 MCP Tool 權限規(guī)則不匹配確認 Tool 的完整命名空間是否正確。Plugin MCP Tool 的格式是mcp__plugin_plugin_server__tool其中 plugin 和 server 名稱需要與 Plugin 和 MCP 配置中的名稱一致。如果規(guī)則寫成了mcp__github__get_issue而實際是mcp__plugin_github-tools_github__get_issue規(guī)則不會生效。5.5 Plugin 更新后權限變化沒有被識別從當前公開文檔看Claude Code 已經(jīng)具備 Source 限制、Plugin 信任和運行時權限控制但 Plugin 更新權限差異審查仍然是企業(yè)治理中值得重點補充的一層。Claude Code 按plugin.json中的 version、marketplace.jsonEntry 中的 version、Plugin Source 的 Git Commit SHA 順序解析版本。如果解析出的版本與當前安裝版本相同手動更新和自動更新都會跳過。對于 Git Source不顯式聲明版本時每個新 Commit SHA 可以成為新版本標識。企業(yè) Marketplace 可以在發(fā)布流程中掃描plugin.json、skills/*/SKILL.mdFrontmatter、agents/*.mdFrontmatter、hooks/hooks.json、.mcp.json、.lsp.json、scripts/提取能力清單并在更新時生成權限 Diff。權限范圍擴大時應要求管理員或用戶重新批準。6. 供應鏈校驗清單與下一步把上面的配置和驗證動作整理成一份可執(zhí)行的清單團隊落地時可以逐項檢查。來源層strictKnownMarketplaces是否配置到 Managed Settingsref是否固定到 Tag 或 SHAdisableSideloadFlags是否啟用是否區(qū)分 stable、beta、lab 通道。安裝層extraKnownMarketplaces是否只推薦批準來源enabledPlugins是否只聲明期望狀態(tài)Workspace Trust 流程是否被正確觸發(fā)pluginTrustMessage是否添加了企業(yè)說明。能力層Skill 的allowed-tools是否精確到腳本級別disallowed-tools是否用于主動收縮Hook 是否受allowManagedHooksOnly限制HTTP Hook 是否有 URL 和 Env Var AllowlistMCP Tool 是否有 allow/deny 規(guī)則。運行時層Permission Deny 是否優(yōu)先Sandbox 是否限制文件系統(tǒng)和網(wǎng)絡邊界Hook 和 Audit 是否記錄執(zhí)行過程Plugin 配置與 Secret 是否分離。驗證完這些之后你可以用 TaoToken 的模型對話快速測試 Skill 行為https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。如果要長期跑 Agent 循環(huán)和編碼任務Coding Plan 更適合https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。接入文檔和 API Keys 管理分別在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 和 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。真正可靠的 Marketplace 安全原則不是相信 Plugin 作者不會作惡而是即使 Plugin 內容不可信它也只能從被批準的來源進入只能注冊被允許的能力只能獲得受限的運行權限并且無法突破 Sandbox 和企業(yè)策略。Marketplace 決定能力從哪里來Plugin Trust 決定能力能否進入Permission 決定能力能否調用Sandbox 決定調用最終能否真正越界。