Anthropic Knowledge Work PluginsはMCP接続前に権限をどう審査する？2026

接続前に、プラグイン一式・MCPの接続先・必要な認証情報を確認し、最小権限のテストアカウントで実際の呼び出しを検証してください。公式リポジトリにあることや接続成功だけでは、組織の安全審査を通過したことにはなりません。
機密データを扱う場合や書き込みを許す場合は、通常の試験導入と分けて承認を取るのが基本です。

このガイドは、Anthropic Knowledge Work Pluginsを評価する開発者、プラグインのファイル構成を確認したい担当者向けです。
MCPコネクターを導入する管理者は、接続先と認証情報の境界を確認できます。
セキュリティ審査担当者は、公開者の名前ではなく、記録に残せる根拠をもとに導入可否を判断できます。

最終確認日：2026年10月9日。確認対象は、公開リポジトリ、リポジトリの審査方針、MCPのプロトコル解説などの公式資料です。プラグインと接続先の内容は更新されるため、導入対象のブランチとコミットを特定して再確認してください。

接続前に見るべきものはREADMEだけではありません

READMEは導入の説明として有用ですが、プラグインが何を指示し、どの処理を実行するかを確認するには不十分です。公式のKnowledge Work Pluginsリポジトリで、対象プラグインのディレクトリとファイルを確認し、存在する構成要素を一つずつ追ってください。すべてのプラグインに同じ種類のファイルが含まれるとは限りません。

ファイル名だけで安全性を判断せず、Skillの指示からHookやスクリプトまで流れをたどりましょう。公式リポジトリの審査方針も参照しつつ、組織の基準に合うかは別途評価します。公開や保守の実績は確認材料にはなりますが、導入承認の代わりにはなりません。

MCP設定と認証情報はどう切り分けますか？

接続設定を見て、少なくとも接続先のサービス、MCPサーバー、認証方式、要求される操作をそれぞれ特定します。コネクターの説明資料とMCPの認可手順を照らし合わせ、設定に書かれていることと、実際に認可される内容を分けて記録してください。

ユーザーの認証情報が、そのユーザー自身の接続先サービスで使われるのか、それとも別のサービスへの要求に引き継がれるのかも確認が必要です。コネクター名だけでは、どの情報がどこへ渡り、どの操作が許可されるかは確定しません。接続設定、認可画面、実際の呼び出しを組み合わせて確認します。

認証情報そのものを審査記録へ貼り付けないでください。権限名や対象サービスは記録しても、トークン、秘密鍵、Cookieなどは残さず、必要ならマスキングしたログを使います。

MCPの接続が成功しても、接続確認や認可の完了を示すだけで、データの扱いが組織の規程に適合しているとは限りません。MCPのプロトコル解説は2026年7月28日付の資料を含め、接続方式の確認に使えますが、個別のプラグインに与える権限は別に審査してください。

説明と実装のずれ、過剰な権限をどう見つけますか？

「検索」や「要約」と説明されていても、実装がファイルを書き換えたり、別サービスへデータを送ったりする可能性は残ります。タスクに必要な操作と、Skillの指示、Hookの発火条件、MCP経由の呼び出しを対応付け、目的に不要なファイルアクセスや書き込みがないか確認します。

たとえば社内文書の検索だけを予定しているのに、設定から外部サービスへの送信が見つかった場合、説明だけで正当化せず、その送信先と対象データを明らかにしてください。説明と実装が一致しない、または目的に不要な権限を取り除けない場合は、試験導入を止めて再審査を依頼します。

過剰な権限は、認証情報の漏えいや意図しない変更につながるリスクです。OWASPが「LLM08: Excessive Agency」として整理するリスクも参考にし、タスクに必要な範囲を超える操作を審査対象に含めてください。Claude Codeプラグインであっても、呼び出し元のツール名だけでアクセス範囲を推定してはいけません。

最小権限のテストと承認判断をどう進めますか？

本番の認証情報や実データを使わず、アクセス範囲を絞ったテストアカウントと非機密のサンプルで検証します。次の手順を、対象プラグインの特定から記録まで続けて実施してください。

• 対象プラグインのブランチ、コミット、確認日を記録し、README、manifest、Skill、コマンド、Agent、Hooks、MCP設定、関連スクリプトを確認します。
• MCPサーバー、接続先サービス、認証方式、要求される操作を一覧にし、認証情報がどのサービスのために使われるかを整理します。
• 読み取り専用のテストアカウントと非機密サンプルを用意し、検索など予定している操作だけができるかを確かめます。
• 書き込みがある場合は、別の試験対象として承認を得てから検証します。変更内容と対象を限定し、試験後に状態を確認します。
• 外部への要求先と送信されるデータを確認します。許可されない操作や接続失敗時に、データが漏れたり意図しない処理が続いたりしないかも確認します。
• 脱敏したログ、試験範囲、確認したバージョン、承認者、未解決事項を残します。実際の鍵やトークンは審査記録に含めません。

導入前後の確認手順をチームで共有するなら、AI Agentの受け入れ確認に使えるインフラ情報も参照できます。掲載情報からセキュリティ機能を推測せず、実際に使う環境の権限や認証情報の扱いは個別に確認してください。審査手順を運用に組み込む際は、サポート情報も参照し、問い合わせ先や確認の進め方を整理できます。

試験導入・制限付き導入・保留を選ぶ条件

導入判断は、データの機密性、権限を狭められるか、外部依存を把握できるか、呼び出しを監査できるかで分けます。以下は判断条件の例です。表の区分は審査の整理に使い、組織の承認基準に置き換えてください。

• 接続先と認証情報の用途を特定でき、非機密サンプルで必要な操作だけを確かめられるなら、範囲を限定して試験導入します。
• 書き込み、機密データへのアクセス、外部送信があるなら、通常の接続許可と分けて承認を取り、操作と記録の条件を定めます。
• 権限を絞れない、意図しない通信がある、実行内容を監査できない場合は、接続成功や公式公開を理由に進めず、導入を保留します。

Anthropicのソフトウェアディレクトリに関する安全性・互換性ポリシーも、確認資料の一つとして使えます。ただし、掲載や公式メンテナンスは、自社のデータ分類や承認要件への適合を保証しません。既存の申請手順と合わせる際は、対象データと承認の記録方法も確認してください。

MCPコネクターを試す環境は、本番データや広い権限から切り離せるほど判断しやすくなります。まずはチームのプラグイン受け入れ手順と、リモート環境でのAgentの認証情報・プロジェクトアクセス方針に、今回の確認項目を加えてください。試験用の環境をどう用意するか比較する場合は、自前のMacや既存のクラウド環境の運用負担も含めて検討し、短期間の検証に限るならKvmjetのMacレンタルも選択肢として確認できます。