AIエージェントのIdentity・付与権限・実行結果の整合性検証
実験前。認証の成功を信頼の終点とせず、誰が・何を許可され・実際に何が起きたかを突き合わせる
AIエージェントのAuthentication、付与Scope、MCP Session、Tool Call、Backend Operationを一つの鎖として関連付け、認証の成功後も「許可された主体が、許可された操作を行っているか」を継続的に評価する方式を検証する。認証結果だけを見る構成から、実効果まで確認する構成まで段階的に比較する。本ページは実験前の研究計画であり、「予想される結果」は予測であって実測値ではない。
| 方法 | 研究用Identityを複数作り、それぞれ異なるScopeを割り当てる。正常シナリオでは許可された操作だけを行い、隔離環境内でScopeと要求操作の不整合、SessionとIdentity contextの不整合、認可判断とBackend効果の不整合を人工的に作る。検知はPolicyの整合性検査と行動の基準線を組み合わせ、認証結果のみの構成から実効果まで見る構成までを同一条件で比較する。 |
|---|---|
| 結果 | 実験は未実施であり、実測結果はまだ無い。本文の「予想される結果」は検証前の仮説である。 |
| 知見 | 本研究の中心的な問いは、Identityを固定的なLogin情報ではなく、Session全体にわたって維持される継続的なsecurity contextとして扱うことが、権限逸脱の検知にどれだけ寄与するかという点にある。 |
| 限界 | Policy定義そのものが誤っている場合は検知できないこと、複雑な委譲やAgent間連携、Identity Providerへの依存、実運用で使われる多様な認可方式、監査可能性とPrivacyの釣り合いは未確定である。 |
状態：実験前。本ページは研究の目的、仮説、方法を公開するための記録である。以下に記す「予想される結果」は検証前の予測であり、実測値として扱わない。
背景と現状の課題
認証の成功は、その後に行われる操作がすべて正当であることを意味しない。正規のCredentialが使われていても、Policyの誤設定、Agentの予期しない動作、権限設計の不整合によって、意図しない操作が要求されることがある。
AIエージェントでは、IdentityとToolの利用の間にMCPというプロトコル層が入る。認証はGatewayで、認可はTool呼び出しの時点で、実際の効果はBackendで生じる。この三つは別々のログに残るため、「誰として認証されたか」「何を許可されたか」「実際に何が起きたか」が同じ主体の同じ活動として結ばれていないことが多い。
本研究は、この鎖を一つのCorrelation IDで結び、認証の成功後も継続して整合性を評価する方式を検証する。
先行研究と本研究の位置
Zero Trust Architectureは、ネットワーク上の位置を暗黙に信頼せず、主体と資源へのアクセスを継続的に評価する原則を示した。NIST SP 800-207Aは、これをクラウドネイティブなApplicationとService間のアクセス制御へ展開している。OAuth 2.0とその安全性に関するBest Current Practiceは、Scopeの付与と保護資源側の検証について実装上の指針を与え、Token Exchangeは委譲された権限の表現を扱う。
MCPの安全性を扱う近年の研究は、Tool Poisoning、Prompt Injection、過剰な権限、Serverの信頼境界を論点としている。SMCPのように、統一的なIdentity管理、相互認証、security contextの伝播、細粒度のPolicy強制、監査記録をプロトコル層へ組み込む提案もある。
本研究が加えるのは新しい認可方式そのものではない。アクセス許可の判断だけでなく、Identity、Scope、Tool、Backend上の実効果という四点の一貫性を観測対象とし、どの段階までを結べば何が検出できるかを段階的に測る点にある。
研究の問いと仮説
- H1：認証の成功だけでは、Agent活動の正常性を十分に表現できない。
- H2：付与ScopeとTool categoryの不整合は、有効な異常信号になる。
- H3：Tool認可とBackend上の実効果を関連付けると、権限逸脱の検知性能が上がる。
- H4：Identity contextをSession全体で維持すると、誤報を減らせる。
観測する鎖と、三つの不整合
基本となる流れは、Identity、Authentication、付与ScopeとPolicy、MCP Session、Tool Call、Authorization Decision、Backend Operationの順である。各段階にCorrelation IDを付け、同一主体の同一活動として時系列に並べる。
| 不整合 | 照合する二点 | 現れ方の例 |
|---|---|---|
| 権限と要求 | 付与Scope ⇄ Tool category | 読み取り権限しか持たない主体が書き込み系Toolを要求する |
| 主体とSession | Identity context ⇄ MCP Session | Session途中で主体の対応が切れる、別Sessionの文脈が混ざる |
| 判断と実効果 | Authorization result ⇄ Backend effect | 拒否されたはずの操作の後に資源が変化する、許可された読み取りの後に書き込みが生じる |
Identityの生情報は必要以上に保存せず、不可逆に匿名化したIDと権限の分類だけを記録する。Token、Password、個人データは研究データへ含めない。
実験方法
隔離環境に、異なるScopeを持つ研究用Identityを複数作る。
| 研究用Identity | 付与Scope |
|---|---|
| agent-reader | document.read |
| agent-writer | document.read、document.write |
| agent-search | search.execute |
正常シナリオでは、各Identityが許可された操作だけを通常の頻度と順序で実行する。異常シナリオは隔離環境内でのみ生成し、上表の三つの不整合を人工的に作る。第三者のシステムを対象にした操作は行わない。
検知はPolicyの整合性検査と行動の基準線を組み合わせる。前者は定義されたPolicyに照らして矛盾を見る規則的な検査、後者は同じ主体の通常の振る舞いからの偏りを見る統計的な検査である。両者を分けて評価し、どちらがどの不整合に効いたかを区別する。
比較対象
- B1：認証結果のみ。
- B2：認証結果と付与Scope。
- B3：Identity、Scope、MCPのTool Call。
- B4：B3にBackend上の実効果を足す。
Train／TestはSession単位で分け、閾値はTest dataを見ずに固定する。Policyの定義、Identityの構成、Scenario ID、乱数Seed、評価スクリプトを記録する。
評価指標
- Precision、Recall、F1 Score、PR-AUC
- False Positive Rate、False Negative Rate、Detection Latency
- Authorization consistency detection rate：三つの不整合それぞれの検出率
- Session attribution accuracy：イベントを正しい主体とSessionへ結べた割合
- Policy evaluation overhead：整合性検査による追加負荷
Session attribution accuracyを別に測るのは、検知性能の改善が本当に整合性検査によるものか、単に対応付けを誤ったことで生じた見かけの異常かを分けるためである。曖昧な対応を正解として固定せず、correlation confidenceを残す。
予想される結果
この節は予測であり、実測結果ではない。
認証結果のみのB1では、認証後に生じる異常を識別できない場合が多いと予想する。付与Scopeを足したB2は、権限と要求の不整合に効く一方、Scopeの範囲内で起きる異常には反応しないと考えられる。Tool Callまで結んだB3では権限逸脱のRecallが上がり、Backend上の実効果まで確認するB4では、要求と実際に起きたことの食い違いをより正確に評価できると予想する。
ただしB4は、Backendログの欠損や時刻のずれに弱い可能性がある。整合性の判定が実は対応付けの失敗を見ていた、という誤りを避けるため、欠損件数と相関に失敗したイベント数を結果と併せて開示する。
考察で検討する論点
- Identityを固定的なLogin情報ではなく、継続的なsecurity contextとして扱うことの有効性。
- Least Privilegeの設計が、検知のしやすさにどう影響するか。
- Alertから主体、要求、認可、実効果まで運用者が遡れるか。
- 監査可能性とPrivacyの釣り合い。記録を厚くするほど追跡もしやすくなる。
限界と安全方針
- Policyの定義そのものが誤っている場合、整合性検査はその誤りを正常として通す。
- 複雑な委譲やAgent間の連携では、主体の対応付けが難しくなる。
- 結果はIdentity Providerの実装に依存し得る。
- 実運用で使われる認可方式は多様であり、本研究の構成がそのすべてを代表するわけではない。
- 実験は所有・管理する隔離環境だけで行い、第三者の公開システムを対象にしない。
- 実Credentialと個人情報を研究データに含めず、実測していない数値を結果として公表しない。
現在地
研究チームは2名である。現在はIdentityの構成、Policy定義、正常・異常シナリオ、共通のイベント項目を固定し、整合性検査の実装を進めている段階にある。Dataset件数、各構成のConfusion Matrix、不整合別の検出率、Session attribution accuracy、追加負荷は実測後に追記する。
参考文献
- Rose, S., Borchert, O., Mitchell, S., Connelly, S. Zero Trust Architecture. NIST SP 800-207, 2020. DOI: 10.6028/NIST.SP.800-207.
- Chandramouli, R., Butcher, Z. A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments. NIST SP 800-207A, 2023. DOI: 10.6028/NIST.SP.800-207A.
- Hardt, D. (Ed.) The OAuth 2.0 Authorization Framework. RFC 6749, 2012. DOI: 10.17487/RFC6749.
- Lodderstedt, T., Bradley, J., Labunets, A., Fett, D. Best Current Practice for OAuth 2.0 Security. RFC 9700, 2025. DOI: 10.17487/RFC9700.
- Jones, M., Nadalin, A., Campbell, B., Bradley, J., Mortimore, C. OAuth 2.0 Token Exchange. RFC 8693, 2020. DOI: 10.17487/RFC8693.
- Model Context Protocol. Specification, Draft version accessed 2026-09-16. https://modelcontextprotocol.io/specification/draft
- Hou, X., Wang, S., Zhang, Y., Xue, Z., Zhao, Y., Fu, C., Wang, H. SMCP: Secure Model Context Protocol. arXiv:2602.01129, 2026.
- Errico, H., Ngiam, J., Sojan, S. Securing the Model Context Protocol (MCP): Risks, Controls, and Governance. arXiv:2511.20920, 2025.
arXiv文献は査読済み出版物と同等には扱わず、研究進行中の関連研究として位置付ける。最終報告では出版状況と最新版を再確認する。