AIエージェント認証、OAuthトークンが有効でも「実行許可」は別問題——confused deputy攻撃と実行前判断の分離設計が焦点に

MCP仕様がOAuth 2.1を認可基盤に採用する一方、トークン検証と実行直前の許可判断を分離する新提案「VATE」やCSA ATFの最小特権設計が広がる

AIエージェントの認証で、OAuthトークンの有効性確認と実行許可判断は別責任と位置づける動きが進む。confused deputy攻撃対策として短命トークンや実行前判断記録の枠組みが提案されている。

AIエージェントが外部サービスへ自律的にアクセスする場面が増える中、「OAuthトークンが有効であること」と「その操作を実行させてよいこと」を別の責任として設計すべきだという議論が具体化している。トークン検証さえ通ればエージェントの行動を無条件に許可する設計は、悪意ある指示に乗っ取られた際に重大な被害を招くためだ。

OAuthとは？仕組み・認証との違い・危険性と対策をわかりやすく解説 — 出典: AIsmiley

AIエージェントの認可・認証設計｜最小特権とトークン管理 — 出典: ailead.app

MCP仕様がOAuth 2.1を認可基盤に採用

生成AIとツールを接続する標準仕様Model Context Protocol(MCP)は、2026年7月28日版の仕様でHTTPベース接続の認可方式としてOAuth 2.1を土台にすることを推奨した。AIsmileyによれば、この仕組みはMCPの認可機能自体は任意であり、同一端末内でプロセス間通信を行うSTDIO接続はOAuth認可フローの対象外とされ、実行環境から直接認証情報を受け取る設計が推奨される点が特徴だ。一方、nhimg.orgの分析では、MCPクライアント(AIエージェント)がOAuthクライアントとして振る舞い、MCPサーバーがリソースサーバー、企業のIDプロバイダが認可サーバーとして機能する構成を説明し、公開クライアントにはPKCEが必須になる点を強調している。同記事は、OAuth 2.1が「取引の認証」はできても「意図や業務上の必要性」までは証明できないと指摘し、これを技術的な欠陥ではなく「エージェントアクセスのガバナンスギャップ」だと位置づけた。

トークン検証と実行許可は別責任——VATEの提案

この境界を具体的に扱う仕様ドラフトとして、noteで公開された「VATE(Verifiable Agent Trust Envelope)」が注目される。ポケヌシ氏の解説では、AIエージェントが120ドルの支払いを実行しようとする場面を例に、JWTアクセストークンが署名・発行者・宛先(audience)・有効期限の検証をすべて通過していても、受け入れ側のローカルポリシーが25ドルを上限に定めていれば、そのまま実行を許可してよいことにはならないと説明する。VATEはこの実行前判断を「認める(allow)」「狭めて認める(attenuate)」「拒否する(deny)」のいずれかとして記録し、後から検査可能にする枠組みで、判断理由や評価対象のリクエストをハッシュ値として保持する設計になっている。

confused deputy攻撃と最小特権の実装

この分離設計が求められる背景には、いわゆる「confused deputy」攻撃がある。Netskopeの分析によれば、攻撃者が汚染された文書やコードリポジトリのコメントに悪意ある指示を埋め込み、エージェントがそれに従って自身の正規トークンで攻撃者の意図を実行してしまう構造だ。結果として発行されるAPI呼び出しはすべて有効な資格情報とスコープを伴うため、通常の監査では検知しづらい。対策として、DPoP(RFC 9449)によるトークンのクライアント固定や、Rich Authorization Requests(RFC 9396)による呼び出しごとのスコープ限定が技術的基盤として整備が進んでいるとされる。EU AI Actでは、OAuthアクセスを持つ自律型エージェントがAnnex IIIの高リスクシステムに該当し得るとし、2026年8月2日から監査義務が発生する点も指摘されている。

企業側の実装例として、CSA Agentic Trust Framework(ATF)の5柱に基づく設計を紹介するaileadのブログでは、マシンID分離、OAuth2 Client Credentials＋15分TTLの短命JWT、RBAC/ABACによる最小特権、SPIFFE/SPIREによるワークロードID、7項目スキーマの監査ログを基本構成として挙げる。監査ログは主体・時刻・トークン種別・対象リソース・操作種別・結果・JTIの7項目で構成し、SIEMへ転送して夜間アクセスや権限拒否率、トークンID再利用の異常を検知する運用が実務例として示されている。

ユーザー単位OAuthの実装パターン

実装レベルでは、freeCodeCampが解説するper-user OAuth方式も参考になる。エージェントはトークンそのものではなく利用者を示す識別子(例:alice@example.com)だけを扱い、呼び出しの瞬間にその識別子からトークンへ変換する関数を経由させることで、トークンがモデルの入力やツールスキーマ、ログに直接触れない設計を実現する。この仕組みは社内向けエージェントでも顧客向けエージェントでもコードは同一で、識別子の解決元だけが変わる点が特徴だ。

認証と認可を区別する基本原則

Qiitaに公開された整理記事では、認証(AuthN)と認可(AuthZ)の違いを空港のたとえで説明している。パスポートによる本人確認が認証、搭乗券による搭乗可否の判断が認可に対応し、両者を混同すると「ログインできたのだから自由に操作してよい」という誤った理解につながると警告する。OAuth 2.0は本来認可の仕組みであり、本人確認機能を加えたものがOpenID Connectだ。この区別はAIエージェント時代においても土台であり、エージェントは利用者の代理として最小限の権限で動くべきだとされる。企業がAIエージェントを業務に組み込む際は、機能面だけでなくOAuth連携方式、要求スコープ、トークン管理方法、そして実行直前の許可判断をどこで行うかまで確認する必要がある。