owner wildcard 這種比對方式，跟過去逐一列出儲存庫名稱的做法，在安全性上有沒有實質差異？
這個功能改變的是「維護成本」，而不是「單一規則本身的安全強度」。逐一列出儲存庫名稱的做法在規則本身的精確度上其實更高——因為每一條規則都對應到一個明確、具體的儲存庫；owner wildcard 則是用組織這個更大的信任單位取代個別儲存庫的信任判斷，一旦組織底下任何一個儲存庫的內容出問題（例如被入侵、或某個協作者的權限被濫用），wildcard 規則會讓這個問題自動涵蓋在原本已放行的範圍內，不會被額外攔下。
這代表使用 owner wildcard 實際上是把信任層級從「儲存庫」上移到「組織」，安全性是否足夠，取決於這個組織本身的存取控制與治理是否嚴謹——這也是為什麼這項功能比較適合用在自己組織內部確實可控的情境，對外部第三方組織如果選擇用 wildcard 放行，等於把風險判斷的顆粒度放大了，需要對這整個組織有相應的信任基礎才合理。
為什麼這次連 SHA-256 完整性驗證也一起加進來，這跟 owner wildcard 是同一個脈絡下的功能嗎？
這兩項功能雖然解決的是不同層面的問題，但確實可以放在同一個脈絡下理解：owner wildcard 處理的是「哪些來源可以被信任」，SHA-256 驗證處理的是「即使來源被信任，實際下載到的內容有沒有在傳輸過程中被竄改」。這兩者合起來才構成一套相對完整的供應鏈信任機制——光是信任一個組織，不代表這個組織發布的每一個檔案在傳輸過程中都不會被竄改（例如中介者攻擊、或散布用的伺服器本身被入侵）；反過來，光是驗證檔案雜湊值沒有幫助，如果一開始就從一個不受信任的來源下載，驗證的只是「這是攻擊者原本想給你的那個檔案」。
把這兩項功能放在同一批更新裡，某種程度上反映了 Anthropic 在 Plugin 生態系規模擴大之後，同時從「來源治理」與「內容完整性」兩個角度加強供應鏈安全，這跟近期針對第三方 Skill 上傳掃描、GitHub repo Skill 信任邊界的一系列動作，方向上是一致的。
如果我的組織已經設定了 strictKnownMarketplaces 允許清單，之後某個原本允許的儲存庫被駭客入侵了，這條規則會自動阻止嗎？
不會。strictKnownMarketplaces 檢查的是「這個 marketplace 來源本身是否在允許清單裡」，這是一種來源層級的靜態比對，不是內容層級的持續監控。換句話說，只要儲存庫的位置（例如 acme-corp/approved-plugins）沒有變，就算裡面的內容被入侵者竄改過，這條規則依然會判定「這是允許的來源」而放行——因為規則核對的是「這是不是我認得的地址」，不是「這個地址現在放的東西是不是還安全」。
這正是 SHA-256 完整性驗證能補上的一塊：如果 marketplace 裡的個別 Plugin 條目有設定 sha256 欄位，那麼即使來源本身被信任，只要實際下載到的檔案雜湊值跟預先設定的不吻合，安裝依然會被拒絕。但這只涵蓋透過 archive 來源的 Plugin，透過 git 來源（github、url、git-subdir）的 Plugin 目前沒有這種雜湊比對機制，比較接近的防護是透過 sha 欄位固定住某個明確的 commit，防止內容在你不知情的情況下被替換成別的版本，但這仍然假設你當初固定的那個 commit 是乾淨的。
如果我要幫組織設計一套 Plugin marketplace 治理政策，這兩項功能該怎麼實際搭配使用？
比較穩健的做法是把兩項功能放在不同層級分工：owner wildcard 用來處理「組織範圍的粗顆粒度信任判斷」——例如放行公司自己的 GitHub 組織（your-org/*）、封鎖已知有問題的外部組織；針對個別關鍵 Plugin（尤其涉及較高權限、會被廣泛安裝的），則額外要求發布者提供 SHA-256 雜湊值，或者要求走 git 來源並固定明確的 commit sha，讓內容完整性有一層獨立於「來源是否可信」之外的保障。
實務上還有一個容易被忽略的細節：owner wildcard 是精確比對，acme-corp/* 只涵蓋這個擁有者底下的儲存庫，不會意外涵蓋到名稱相似但屬於別的擁有者的儲存庫；同時 strictKnownMarketplaces 是在新增 marketplace、以及每次安裝、更新、重新整理、自動更新時都會檢查，如果某個 marketplace 是在政策設定之前就已經新增、且來源不再符合允許清單，規則生效後會直接拒絕該來源後續的安裝與更新，這代表政策異動後，值得主動盤點一次目前已安裝的 marketplace 清單，確認沒有意外被擋下的必要來源。
Claude Code 近期的更新為管理者提供了更精細的 Plugin Marketplace 控管工具：透過 strictKnownMarketplaces 這項受管理設定，管理者現在可以用「擁有者萬用字元」（owner wildcard）的形式，一條規則放行或封鎖某個 GitHub 組織底下所有的 marketplace 儲存庫，不需要逐一列出每個儲存庫名稱；同時新增了封存（archive）這種新的 Plugin 散布方式，讓 Plugin 可以直接透過 HTTPS 下載 zip 檔安裝，不需要 git 或 npm，並且能附上 SHA-256 雜湊值來驗證下載內容有沒有被竄改。
strictKnownMarketplaces 這項設定原本就存在，用來限制使用者可以新增哪些 marketplace 來源，未設定時預設不受限制，若設成空陣列則會完全封鎖包括官方 marketplace 在內的所有來源，或者也可以列出一份允許清單。這次的更新新增的是萬用字元的比對方式：管理者可以寫一條規則涵蓋 acme-corp/* 這樣的寫法，讓組織底下任何一個儲存庫都能自動被允許（或用在封鎖清單 blockedMarketplaces 裡，一次封鎖某個不信任組織底下所有儲存庫），這項功能需要 Claude Code v2.1.223（含）以上版本才支援。
另一項新增功能是讓 marketplace 可以用 封存來源（archive source） 散布 Plugin：把 Plugin 打包成 zip 檔，放在任何靜態檔案伺服器上（例如 S3、Artifactory），Claude Code 透過 HTTPS 下載這個 zip 檔來安裝，整個過程不需要使用者的機器上有 git 或 npm 環境。這個來源類型可以額外附上 sha256 欄位，指定這個檔案的雜湊值；一旦設定，Claude Code 每次下載都會核對雜湊值是否吻合，不吻合就直接拒絕安裝並回報「Plugin archive integrity check failed」的錯誤，不會裝進一個內容被竄改過的版本。官方文件也明確指出，這項來源類型只接受 HTTPS，且會拒絕內網位址、雲端中繼資料位址等有安全疑慮的下載目標，任何重新導向的過程也必須符合同樣的規則。
如果你是個人開發者，這兩項更新不會直接改變你的日常操作，但封存來源多了一個不依賴 git／npm 就能散布 Plugin 的管道，對於想要用內部檔案伺服器散布私有 Plugin、又不想額外架設 git 服務的團隊，是一個更輕量的選項；附上 SHA-256 雜湊值也讓你可以在安裝前就確認下載到的內容跟發布者原本提供的完全一致。如果你是企業或組織的管理者，owner wildcard 讓白名單／黑名單政策的維護成本大幅降低——過去如果要放行一個活躍開發中的內部組織，可能得隨著新儲存庫不斷新增而持續更新規則清單，現在一條萬用字元規則就能涵蓋，同時也代表反過來要封鎖一個已知有問題的外部組織時，不必等到列出它底下每一個儲存庫才能生效。