Durin を使用して MCP アクセスを一元管理する

MCP 接続を一元化する理由は何ですか?

従業員は、1 つの AI クライアントをコーディングに使用し、別の AI クライアントを研究に使用する場合があります。それぞれが複数のツールに接続できます。これらの接続が増加するにつれて、IT 部門は、接続の所有者、接続が使用する認証情報、公開されるリソース、問題が発生した場合の証拠をどこで見つけるかを把握する必要があります。すべてのクライアントでその作業を繰り返すと、変更の調整が難しくなります。

Durinは、クライアントと承認済みの接続先の間でMCPアクセスを管理します。各ユーザーは専用のエンドポイントを使い、管理者はワークスペースで接続先、ポリシー、変更操作の確認、監査記録をまとめて管理できます。ポータルやゲートウェイを使う利点は、複数のツールで運用手順をそろえられることです。全員で1人分のURLを共有する必要はありません。

変更前: 各クライアントは個別に接続先システムに接続します。変更後: クライアントは独自の Durin エンドポイントと共通の接続制御セットを使用します。破線の直接パスは、Durinを通過することなく接続先システムに到達します。その所有者はそのルートを個別に制御する必要があります。

図を原寸で開く： 個別の接続は共有管理ルートとなり、直接アクセスはその外部にあります。

ダイレクト MCP サーバーには、すでに効果的な認証、リソース制御、および監査が備わっている場合があります。一元化は、チームが複数のクライアントまたはシステムにわたってこれらの責任を一貫して管理する必要がある場合に役立ちます。まず、既存のコントロールの一覧を作成し、共有する必要がある決定事項を特定します。

そのインベントリ上のダイレクト パスを保持します。別のプロバイダー認証情報を持つユーザーは、引き続き Durin の外部の同じシステムにアクセスできます。クライアント構成、アップストリーム権限、およびネットワーク制御は、ロールアウトの一部として残ります。管理された呼び出しが成功すると、ルートが機能していることが証明されます。他のすべてのルートが閉鎖されたことを証明するものではありません。

アーキテクチャがどのように組み合わされるか

AI クライアントがツール呼び出しを提案します。 Durin は個人用 MCP エンドポイントでリクエストを受信し、リクエスト者を認証します。エンドポイントはそのアカウントに属します。そのアドレスを知っていても、他の人がそのエンドポイントを使用することは許可されません。ブラウザーのサインインと認証された MCP クライアントは別の手順です。

クライアントとそのモデルはDurinの外に残ります。個人用エンドポイントは、アイデンティティにバインドされたエントリ ポイントを選択します。 Durin 内部では、現在のチェックとポリシーが接続に先行します。リモート MCP リクエストは接続先のMCPサーバーに送信されます。ネイティブ アダプターはプロバイダー API を呼び出します。意思決定と結果のメタデータが監査証跡を形成します。デモ用サンドボックスは Durin 内に留まり、プロバイダーには連絡しません。

図を原寸で開く： 個人のイングレスおよびアクセス チェックは、リモート MCP またはネイティブ API 接続にルーティングされます。

承認された接続は、ワークスペースが利用可能にしたシステムを表します。アクセスは、申請者ーの現在のメンバーシップとチームの範囲、接続の状態、選択した認証情報、レビューされたツール、リソース、および検査によって異なります。ツールの検出により、使用可能なカタログが公開されますが、ツールを表示しても、それを呼び出すことが永続的に許可されるわけではありません。

リモートMCP接続は接続先のMCPサーバーと通信し、ネイティブコネクタは外部サービスのAPIでツールを実行します。仕組みは異なりますが、どちらも同じルールでアクセスを管理できます。Durinのサンドボックスでは、外部サービスに接続せず、デモ用の文書やチケットで操作を試せます。実際のシステムを設定する前に、管理機能を確認するのに役立ちます。

モデルはクライアントが選択した環境で引き続き実行されます。 Durin はそれをホストしたりトレーニングしたりしません。クライアントに返されるツールの結果はそのモデル プロバイダーに到達できるため、組織のデータ処理ルールをクライアントにも適用します。上流の承認は、選択したプロバイダー アカウントがアクセスできるものに対する権限を維持します。

エージェントがツールを呼び出すとどうなりますか?

影響のない読み取りを試してみましょう。resource を engineering/handbook にして sandbox__read_document を呼び出します。サンドボックスには短いデモ用ハンドブックがあり、会社の文書は含まれません。クライアントがツール名と引数を送信すると、Durin は、このリクエスト元が現在その呼び出しを実行できるかを評価します。

アクセスを認証して確認し、ポリシーの決定を記録します。拒否すると呼び出しが止まります。承認が必要な場合は、独立したレビューと要求者の正確な再試行のためにアクションが一時停止されます。現在許可されているリクエストのみが引き続きディスパッチされます。試行後、記録される結果は、成功が確認されたか、失敗が確認されたか、または不確実かです。不確実性が成功として示されることはありません。

図を原寸で開く： ツールのリクエストは、必要な確認とポリシーの判定を経て送信されます。実行結果は、その判定とは別に記録します。

1. 要求者を特定します。認証は、個人のエンドポイントと現在のワークスペースのメンバーシップと一致する必要があります。
2. アクセス条件を確認します。接続先が有効かつ検証済みであり、チームの範囲、個人の権限、認証情報、確認済みツール、許可されたリソース、内容検査のすべてでリクエストが認められる必要があります。
3. ポリシーを評価します。レビューされたリクエストは、必要なチェックの後、デフォルトで許可されます。管理者は、デフォルトの拒否を選択したり、個別に書き込み承認を要求したり、書き込みを拒否したりできます。チームの制限とカスタム ポリシーにより、結果がさらに制限される場合があります。
4. 許可された場合のみリクエスト送信します。拒否されたリクエストは、ツールが実行される前に停止します。承認が必要な応答は、レビューと再試行が必要であることを意味します。アクションは実行されていません。
5. 結果を検査します。デモデータの読み取りは、成功するとハンドブックのテキストを返します。決定と執行の記録には、何が許可されたのか、そして実際に何が起こったのかが別個の事実として記述されます。

Durinで許可されても、接続先で処理が成功するとは限りません。認証の期限切れやサービス障害で失敗したり、変更後の応答を受け取れなかったりすることがあります。Durinは「完了」「失敗」「結果不明」を区別して記録します。結果が不明な変更操作を繰り返すと、処理が重複するおそれがあるため、まず接続先で状況を確認してください。

クライアントを Durin に接続する

接続リクエストを確認できる管理者を使用して、既存の Durin ワークスペースから開始します。初めての場合は、まずオンボーディング中に表示されるアカウントとワークスペースの手順を完了してください。以下の演習では Durin のデモ用サンドボックスを使用しており、サードパーティのプロバイダー アカウントは必要ありません。サインアップする前のデモンストレーションについては、以下のリンクにあるパブリック リクエスト シミュレーターをお試しください。

1. [マイ ワークスペース] で、[接続] を開き、[エージェントに接続] を展開します。 MCP エンドポイントを見つけます。プロンプトが表示されたら、[エンドポイントのセットアップ] を選択します。次に、「URL をコピー」を使用します。コピーしたアドレスを自分のアカウントに関連付けたままにしておきます。
2. 「接続」→「利用可能」を開き、Durin サンドボックスをリクエストします。管理者は「承認」でリクエストを開き、「リクエストの承認」を選択します。これにより、必要に応じてサンドボックスが作成されます。既存のアクセス ポリシーが引き続き適用されます。無効なサンドボックスを有効にするには、管理者が必要です。
3. コピーしたエンドポイントを MCP クライアントに追加します。以下のClaude コードの例は、Web サイトで使用されているのと同じセットアップ ジェネレーターからのものです。 YOUR_PERSONAL_ENDPOINT_ID を、コピーした独自の URL の識別子に置き換えます。表示されているアドレスは単なるプレースホルダーです。

claude mcp add --transport http --scope user durin 'https://mcp.getdurin.com/mcp/u/YOUR_PERSONAL_ENDPOINT_ID'

Claude Code を開き、/mcp を使用して Durin を認証します。

エンドポイントを所有するアカウントを使用して認証を完了し、クライアントのツールを更新します。プロバイダー トークンをエンドポイント URL に貼り付けたり、他の人のアドレスをチーム構成として共有したりしないでください。 durin という名前のサーバーがすでにある場合は、別のサーバーを追加する前に、その既存のエントリを調整します。クライアント セットアップ ガイドでは、コーデックス、カーソル、接続固有の URL についても説明しています。

保存された接続を 1 つだけ表示する必要があるクライアントの場合は、その接続を開いて、[接続 URL の設定]、[接続 URL のコピー] の順に選択します。その正確なアドレスを所有者として認証します。完全な個人用エンドポイントと接続固有のエンドポイントには別個の承認対象者があり、一方のトークンは他方のトークンと交換できません。リソースのアクセス許可と現在のポリシーは、選択した接続に引き続き適用されます。

クライアントに、resource を engineering/handbook にして sandbox__read_document を呼び出すよう依頼します。成功すると、応答にはデモ用の開発ハンドブックであり、会社のデータは含まれないことが示されます。アクティビティでリクエストと結果を確認してください。組織全体の状況が必要な場合は、管理者に組織の監査証跡の確認を依頼します。

管理者は、このサンプルの会社ハンドブックのセットアップ要求を承認しました。表示される「承認済み」「セットアップ保留中」ステータスとレビューメモは、アクティブ化の前にプロバイダーアクセスの検証がまだ必要であることを意味します。この接続リクエストは、1 つのツール アクションの承認とは別のものです。

図を原寸で開く： 会社ハンドブックの接続レビュー中に、「承認済み」「セットアップ保留中」と表示されます。

実際のプロバイダーに移行する場合は、そのプロバイダーのセットアップ ガイドと現在の接続画面を使用してください。保存されたドラフト、リストされたプロバイダー、または承認されたセットアップ要求は、アクティブな接続の証拠にはなりません。プロバイダーの認証、ツールの検出とレビュー、バリデーター、準備テスト、およびアクティベーションを必要に応じて完了する必要があります。個人プロバイダーの同意も必要な場合があります。サンドボックスのアカウント不要の設定がすべての統合に適用されると想定するのではなく、表示されるチェックポイントに従ってください。

機密性の高い書き込みは慎重に処理してください

レビューを安全に行うには、管理者に「書き込みには別の管理者を要求する」を発行してもらいます。リソース エンジニアリング/ロードマップと短い合成タイトルを付けて、sandbox__create_ticket を送信します。別のアクティブな管理者がアクションをレビューする必要があります。たとえその人が管理者アクセス権を持っていたとしても、同じ人がリクエストと承認の両方を行うことはできません。

申請者は書き込みを送信し、保留中のアクションを受け取ります。別のアクティブな管理者がそれをレビューします。正確に承認されると、ディスパッチせずに制御が要求者に戻ります。要求者は、有効期限が切れる前に、承認参照を使用して同じ呼び出しを再試行します。 Durin は、現在のアクセスと許可を消費して 1 回の試行を要求する前に再検証します。拒否された、期限切れ、または無効になった付与は停止されます。不確実な試みについては、別の書き込みの前に調査が必要です。

図を原寸で開く： 別の管理者が承認し、要求者が再試行し、現在のチェックによって 1 回の実行試行がゲートされます。

レビュー担当者は、「承認」でアクションを開き、申請者ー、ツール、リソース、引数ダイジェスト、バージョン、および有効期限を確認して、「個別の操作を承認」または「拒否アクション」を選択します。承認は、1 つのリクエストをその ID、接続、認証情報コンテキスト、ツール、引数、リソース、および関連するバージョンにバインドします。以降の書き込みに対する一般的なアクセス許可は付与されません。

再試行は現在のアクセスに対して評価されます。期限切れの承認、取り消されたメンバーシップ、変更されたポリシー、変更された引数、または変更されたツールまたは認証情報コンテキストでは、古いアクションを承認できません。使用可能な許可は、実行の試行に対して消費されます。重複配信は別の書き込みを許可しません。新しいレビューが必要な場合は、別のリクエストを作成する前に理由を調査してください。

たとえば、レビュー後にデモ用チケットのタイトルを変更すると、引数が変更されます。別のロードマップ リソースを選択すると、ターゲットが変更されます。どちらも確認担当者が許可した行為ではありません。正確な再試行のために元のリクエストをそのまま保持するか、独自の評価のために変更されたアクションを送信します。これにより、管理者は、エージェントが後で書き込みを即興で実行できる無制限の権限ではなく、制限付きの決定を行うことができます。

最後に、実行結果を検査します。サンドボックスの場合、成功が確認されるとデモ用チケットが生成されます。実際のプロバイダーの場合、応答が失われた場合、結果が不確実になる可能性があります。新たに書き込みを試みる前に、プロバイダーと記録された証拠を確認してください。冪等キーを変更して別の試行を強制すると、すでに発生したアクションが重複する可能性があります。

展開前に境界を理解する

呼び出しが失敗した場合は、アクセス許可を変更する前にチェックポイントを見つけます。認証が失敗した場合は、正しいアカウントとエンドポイントの承認が必要になります。ポリシーを拒否する場合は、その理由、メンバーシップ、チームの範囲、ツールのレビュー、およびリソースのアクセスを確認する必要があります。利用できない接続は、無効になっているか、未検証であるか、ユーザーに対して切断されているか、使用可能な認証情報が欠落している可能性があります。これらの条件は、アクションを承認しても解決されません。

期限切れまたは無効になった承認については、現在のリクエストを再度レビューする必要があります。アップストリーム エラーの場合は、プロバイダーとその権限を調査する必要があります。これらのケースは、アクションがすでに行われている可能性がある不確実なディスパッチ書き込みとは別にしてください。すべてのエラーを再試行の理由として扱うことは避けてください。

監査証拠は、決定と実行のメタデータを記録します。すべてのプロンプト、引数、または応答をアーカイブすることを約束するものではありません。オペレータが必要とする証拠を決定し、キャプチャと保持の設定を確認し、誰が記録を検査できるかを確認します。接続先サービスとモデルのプロバイダーは、独自のセキュリティとデータ処理の責任を負います。

• 各接続の所有者に名前を付け、Durin ルートに沿った直接アクセス パスをインベントリします。
• 対象のメンバー 1 人を接続し、低リスクの読み取りを確認し、記録された理由で拒否を検証します。
• 書き込みアクセスを拡張する前に、独立したレビュー、正確な再試行、有効期限、取り消しをテストします。
• 失敗した不確実な試みを誰が調査し、実際の効果をどこで確認するかについて合意します。
• より広範な展開を計画する前に、現在の価格設定と必要なアカウント機能を確認してください。

チームがルート、許可の決定、試行の結果を説明できたら展開します。開発者ガイドは、クライアント統合の次のステップです。ガバナンス チェックリストは、この 1 つの演習を運用プロセスに変えるのに役立ちます。