ホームへ戻る
SecurityAuthenticationAPI Management

MCP-identity: MCPサーバー向けのリクエストごとの暗号化認証

Ed25519署名を使用してMCPサーバー向けのリクエストごとの暗号化認証を提供します。OAuth 2.1の代替ではなく、追加のセキュリティ層として機能します。

2026年5月6日·IndiePulse AI Editorial·記事·出典
発見元GLOBALENHN

ベータMCP-identity

タグラインMCPサーバー向けのリクエストごとの暗号化認証
プラットフォームother
カテゴリSecurity · Authentication · API Management
訪問github.com
出典
発見元GLOBALENHN

MCP-identityは、モデルコンテキストプロトコルの重大な建築上の盲点に対処します:セッション認証と意図検証の違いです。OAuth 2.1はユーザーがログインしており、サービスがアクセス権を持っていることを確認しますが、特定のユーザーが特定の瞬間に特定のペイロード(データベース削除やファイナンス取引の実行など)を意図的に承認したことを証明できません。正確なリクエストボディに対する署名を導入することで、MCP-identityは自律エージェント操作の重要な否認防止を提供します。

技術的には、実装は軽量です。PythonサーバーのASGIミドルウェアパターンを活用し、リクエストスコープに検証ステータスを注入します。セキュリティモデルは、リプレイ攻撃を緩和するためのタイムスタンプウィンドウ(デフォルト30秒)とノンスストアの組み合わせに依存しています。これは重要な詳細です。プロジェクトは、`InMemoryNonceStore`が分散環境には不十分であることを正確に認識し、負荷分散インスタンス間の一貫性を維持するためのRedis統合プロトコルを提供しています。

主な摩擦点は鍵管理です。v0の状態では、ライブラリはユーザーがローカルJSONキーファイルを処理できることを前提としており、これは一般消費者のUXでは受け入れられませんが、現在のターゲット層である開発者やセキュリティ監査人には許容されます。「寛容」モードは賢明な製品決定であり、チームが既存の統合を壊すことなく認証を展開し、後に「厳格」な強制に切り替えることができます。

このツールは、破壊的または不可逆的なアクションを実行するMCPサーバーを構築する開発者にとって不可欠です。サーバーが単にドキュメントを読んでいるだけなら、これは過剰です。サーバーがLLMに代わってお金を移動したり、本番状態を変更したりする場合、この暗号化証明のレイヤーは真剣な監査証跡の前提条件となります。

記事タグ

indiesecurityauthenticationapi management