AIエージェントと人間を結びつける方法：KYAの技術的側面

主なポイント

• Know Your Agent（KYA）は、エージェントに名前を付けるだけでは解決しません。永続的な制御は、認証された人物、登録されたクライアント、付与されたスコープ、組織コンテキスト、および結果として生じる各アクションをリンクする委任チェーンです。
• Diditのホスト型Model Context Protocol（MCP）エンドポイントは、19のドメインにわたる115のツールを公開し、Proof Key for Code Exchange（PKCE）と動的クライアント登録を備えたOpen Authorization（OAuth）2.1を使用しています。
• MCPは、サインインしたDiditユーザーとして機能します。そのユーザーの組織ロールを継承するため、接続されたエージェントは、その人物がすでに持っていなかった権限を取得することはできません。
• 設定ファイルに保存されたアプリケーションキーは、資格情報の所持を証明するものであり、特定の行動を委任した人間を証明するものではありません。共有キーは、複数のオペレーターとエージェントを1つのアプリケーションIDにまとめます。
• 説明責任には、強制と証拠の両方が必要です。行動前のスコープ付きトークンとロールチェック、そして誰が何を変更したかを示す監査記録です。

Diditはすでにこのメカニズムを出荷しています。そのホスト型MCPサーバーは、エージェントをアプリケーションシークレットの匿名所有者として扱うのではなく、サインインしたユーザーを通じてAIクライアントをIDおよび詐欺対策操作に接続します。このエンドポイントは無料で、ステートレスなストリーマブルHTTPを使用し、115のツールを公開しています。この実装は、MITライセンスの公開GitHubリポジトリでも利用できます。

この成果物は、有用な疑問を変えます。KYAの別の定義を求める代わりに、エージェントが検証セッションを作成したり、決定を読み取ったり、ワークスペースデータを変更したりするとき、どの人物がそれを許可し、その人物が何を許可し、どの組織がその行動を受け入れたかを証明するものは何ですか？と問いかけます。

人間との紐付けは委任チェーンです

エージェント名、モデル識別子、公開鍵、またはソフトウェア認証は、機械のアクターを特定するのに役立ちます。しかし、それらのどれも単独では、エージェントが行うことについて誰が責任を負うかを確立するものではありません。人間との紐付けには、明確なリンクを持つチェーンが必要です。

• プリンシパル：エージェントが代理で行動する、認証されたユーザーまたはサービス所有者。
• クライアント：アクセスを要求したAIアプリケーション。
• 委任：そのクライアントに付与されたスコープと同意。
• 認証コンテキスト：リクエストに適用される組織ロールとアプリケーション境界。
• 証拠：行動とその結果のレビュー可能な記録。

各リンクは異なる質問に答えます。認証は誰がサインインしたかを伝え、OAuthはどのクライアントが委任されたアクセスを受け取ったかを伝え、スコープはどの種類の操作が承認されたかを伝え、ロールはユーザーが組織内で何ができるかを伝え、監査記録は何が実際に起こったかを伝えます。これらの制御を単一の「検証済みエージェント」バッジにまとめることは、最も重要な部分を隠してしまいます。権限は状況に応じて変化し、取り消し可能です。

信頼できるエージェントは、単に識別可能であるだけではありません。責任あるプリンシパルから特定の許可された行動までの途切れないパスを示すことができる必要があります。

設定ファイルのキーが説明責任テストに失敗する理由

アプリケーションAPIキーは、制御されたサーバー間統合には適切かもしれませんが、それ自体が人間とエージェントの紐付けメカニズムではありません。コピーされたキーは通常、「この呼び出し元がこのアプリケーションで受け入れられる資格情報を持っているか？」という1つの質問に答えるだけです。誰がエージェントを起動したか、誰が現在のタスクを承認したか、または同じキーを使用する2つの呼び出しが異なる人物から来たかについては答えません。

障害モードは予測可能です。チームはローカル環境間でキーを共有します。エージェントプロセスは設定ファイルからそれを継承します。2番目のエージェントがコピーを受け取ります。その後、ログはすべての呼び出しを同じアプリケーション資格情報に帰属させます。その資格情報を失効させると、それを使用するすべてのワークロードが中断されますが、個々の委任イベントは不明確なままになります。

Diditは、ホスト型MCPエンドポイントにアプリケーションキーパスを意図的に提供していません。バックエンド統合では、アプリケーション資格情報を使用してDiditのREST APIを引き続き使用できますが、リモートMCPアクセスにはユーザーOAuthフローが必要です。この分離が重要です。REST資格情報はアプリケーション統合を表し、MCPトークンはサインインしたユーザーからの委任されたアクセスを表します。

OAuth 2.1、PKCE、および動的クライアント登録

OAuthは、この設計における委任のプリミティブです。このフローは、ユーザーのパスワードをエージェントに渡すことも、MCP構成に再利用可能なプラットフォームシークレットを配置することもありません。代わりに、ユーザーがDiditで認証し、アクセスを承認した後、AIクライアントは制限付きアクセストークンを取得します。

1. クライアントを登録する

動的クライアント登録により、互換性のあるMCPクライアントは、手動で事前プロビジョニングされたクライアント識別子なしでDidit認証サーバーに登録できます。これにより、認証サーバーは、アクセスを発行できる個別のクライアント登録を持つことができます。登録はOAuthクライアントを識別しますが、それ自体がクライアントのソフトウェアが信頼できることを証明するものではありません。

2. 認証応答をクライアントにバインドする

PKCEは、認証試行のための使い捨ての検証者とチャレンジを作成します。フローを開始するクライアントは、認証コードを交換するときに検証者を提示する必要があります。これにより、傍受されたコードの価値が制限されます。なぜなら、別のプロセスが検証者なしでそれを引き換えることができないからです。

3. 認証と同意

ユーザーは、認証サーバーとして機能するDidit Business Consoleにサインインし、要求されたスコープを承認します。Diditは、検証操作にはdidit:verificationを、ワークスペース管理にはdidit:managementをアドバタイズします。クライアントは、タスクに必要なスコープのみを要求する必要があります。

4. すべての呼び出しを検証する

ホスト型MCPリソースサーバーは、ツール呼び出しをディスパッチする前にベアラートークンを検証します。検証されたユーザートークンと組織コンテキストは、リクエストとともにDiditに送信されます。その後、下流サービスは、そのユーザーの既存のロールと権限を評価します。その結果、エージェントのために作成された新しいスーパーユーザーIDではなく、ユーザーとして行動するセマンティクスが得られます。

MCP認証ガイドはフローを文書化し、MCP概要はホスト型エンドポイントとクライアントモデルを説明しています。

ユーザーとして行動することで権限が明確になる

コンプライアンスオペレーターがAIクライアントをDiditに接続すると仮定します。クライアントは最初にdidit_context_getを呼び出します。これにより、サインインしたユーザーがアクセスできる組織とアプリケーションが返されます。ユーザーが明確な組織とアプリケーションを1つ持っている場合、コンテキストは自動的に解決できます。いくつか利用可能な場合、操作は明示的な組織とアプリケーションに絞り込むことができます。

エージェントはその後、didit_session_createを呼び出して検証セッションを作成し、didit_session_get_decisionを呼び出してその結果を取得できます。これらは、現在のMCPカタログにある実際のドメインファーストのツール名です。必要な権限を持たないユーザーは、エージェントを接続してもその権限を得ることはありません。同じ組織の認証境界が依然として適用されます。

これは、共有アプリケーション資格情報との中心的な違いです。OAuthモデルでは、リクエストは、宣言されたスコープを持つ登録済みクライアントを介して操作する既知のユーザーとして到着します。共有キーモデルでは、下流システムはアプリケーション資格情報を見ますが、別の制御プレーンがそのコンテキストを提供しない限り、特定の呼び出しの背後にいる人間とエージェントは区別できません。

監査可能性：「誰が行動できるか？」から「誰が何をしたか？」へ

認証は、スコープ外の行動を防止します。監査可能性は、行動が発生した後にそれを説明します。Diditはdidit_audit_log_listを公開しており、認証されたユーザーは、誰が何を変更したかを記述するアプリケーション監査エントリを検査できます。各ホスト型MCPリクエストは、サインインしたユーザーのベアラートークンと解決された組織コンテキストを保持するため、その行動は匿名のエージェントプロセスではなく、その呼び出し元に帰属させることができます。

完全なフォレンジック記録は、エージェント側の証拠も保持する必要があります。影響の大きいワークフローの場合、エージェント実行識別子、クライアント登録、要求されたスコープ、ターゲット組織とアプリケーション、ツール名、タイムスタンプ、承認状態、および入力と出力の安全な表現を記録します。アクセストークンや機密性の高いIDペイロードはログに記録しないでください。プラットフォーム監査証跡とエージェント実行ログは、秘密や規制対象の個人データを重複させることなく関連付けることができるはずです。

帰属は否認防止と同じではなく、監査ログは最小特権の代替ではありません。これらの制御は互いに補強し合います。

• 永続的な共有資格情報ではなく、短命のアクセスと制御された更新を使用します。
• 最も狭いOAuthスコープと最小特権の組織ロールを付与します。
• 破壊的または異常に影響の大きい操作には、人間の確認を要求します。
• 複数のターゲットが利用可能な場合は、組織とアプリケーションのコンテキストを明示的にします。
• 委任を終了する必要がある場合は、ユーザーセッションまたはクライアント付与を取り消します。
• 予期しないアクター、ツール、ターゲット、またはタイミングについて監査記録を監視します。

紐付けが証明するもの、証明しないもの

このパターンは、認証されたDiditアカウントがOAuthクライアントにスコープ付きアクセスを委任し、各リクエストがそのユーザーの組織権限で評価されることを証明します。これにより、アカウントに対する実用的な説明責任と、プラットフォームアクションのレビュー可能なチェーンが作成されます。

ただし、アカウント所有者が検証済みの市民IDを持っていること、承認されたクライアントバイナリが変更されていないこと、または人間がすべてのステップを積極的に監視していることを自動的に証明するものではありません。これらには追加の保証が必要です。法的ID保証が必要な場合は、オンボーディング中に本人確認（KYC）管理でプリンシパルを検証し、その結果をアカウントに紐付けます。ソフトウェアの出所が重要である場合は、クライアント認証と署名付きリリースを追加します。存在が重要である場合は、機密性の高いアクションの瞬間にステップアップ承認を要求します。

この多層的な視点は、KYAを誠実なものにします。エージェントID、人間ID、委任された認証、ランタイムポリシー、および監査証拠は、交換可能なラベルではなく、関連する制御です。

検査可能な実装例

Diditの実装は、同様の説明責任境界を設計するチームにとって具体的なリファレンスを提供します。ホスト型サーバーは、サインインしたDiditユーザーとして認証し、そのユーザーの組織ロールを継承し、そのIDをすべてのツール呼び出しに適用します。その115のホスト型ツールは、コンテキストや検証セッションからワークフロー、組織、分析、監査ログまで、19のドメインにわたります。現在のツールカタログには、正確なインターフェースが記載されています。

製品のコンテキストとして、フルKYCバンドルは0.33ドルで、ID検証、パッシブライブネス、顔照合、IP分析を組み合わせたものです。Diditには毎月500回の無料検証が含まれており、2,000社以上の企業が本番環境で使用しています。MCPサーバー自体は無料なので、チームは別途コネクタ料金を追加することなく、委任と権限モデルを評価できます。

このメカニズムがより広範なエージェントワークフローにどのように適合するかについては、AIエージェント向けにIDと詐欺対策MCPがどのように機能するか、およびDidit MCPツールリファレンスをご覧ください。

行動を信頼する前にエージェントを紐付ける

エージェントIDにおける難しい問題は、ソフトウェアの永続的な名前を発明することではありません。それは、ソフトウェアがインターフェースを越え、機械の速度で動作するときに、人間の説明責任を維持することです。OAuth 2.1は委任されたアクセスを提供し、PKCEは認証交換を保護します。動的クライアント登録は接続クライアントを識別し、スコープと組織ロールは権限を制約します。監査記録は結果をレビュー可能にします。

Didit MCPリポジトリでアーキテクチャを検査したり、認証ドキュメントを確認したり、DiditをClaudeに接続したりできます。有用なテストはシンプルです。提案されたエージェントの行動について、責任あるユーザー、クライアント、付与されたスコープ、組織境界、および結果として得られる監査証拠を特定できますか？いずれかのリンクが欠けている場合、エージェントは完全にバインドされていません。