Skip to content
Published on

2026 IAM トレンド — AI エージェントアイデンティティ、MCP 認証、Verifiable Credentials

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

はじめに — 2026年 IAM の地形を変える3つの地殻変動

IAM(Identity and Access Management)は保守的な分野です。十数年前のプロトコルが現役で、変化は遅い。ところが2025〜2026年にかけて、3つの地殻プレートが同時に動きました。

  1. Passwordless のデフォルト化: パスキーが「オプション」から「デフォルト」になりました。新規サービスはパスワードなしで始めるほうが自然な設計になり、identity-first セキュリティ — ネットワーク境界ではなくアイデンティティこそがセキュリティの第一境界であるという Zero Trust の中核命題 — が実務標準として定着しました。
  2. Non-human identity の爆増: 人間のアカウントより機械のアカウントが多くなって久しいですが、AI エージェントの登場でその比率は一桁倍ではなく数十倍に開きつつあります。より深刻なのは量ではなく性質です — エージェントは自律的に行動し、権限を委任され、他のエージェントを呼び出します。
  3. エージェントとツール接続の標準化: MCP(Model Context Protocol)が AI エージェントとツール/データソースをつなぐ事実上の標準になったことで、「エージェントは私の API にどう認証するのか」という問いに OAuth 2.1 ベースの公式な答えが生まれました。

本記事はこの3つの流れを貫きながら、AI エージェント認証の難題、MCP authorization 仕様の詳細、Keycloak 26.6 の CIMD 実験サポートが持つ意味、token exchange と transaction token による委任チェーンの実装、そして verifiable credentials まで — 2026年の IAM 実務者の地図を描きます。

Non-human Identity — サービスアカウントから AI エージェントへ

伝統的な non-human identity(NHI)は比較的扱いやすいものでした。サービスアカウント、API キー、ワークロード証明書は**振る舞いが決定的(deterministic)**だからです。バッチジョブは決まった時間に決まった API だけを呼びます。SPIFFE/SPIRE のようなワークロードアイデンティティ標準がこの領域をうまく整理してきました。

AI エージェントはこの前提を崩します。

区分伝統的 NHI(サービスアカウント)AI エージェント
行動パターン決定的、予測可能非決定的、プロンプトによって変化
権限範囲固定された狭い scopeタスクに応じて動的に必要
委任構造ほぼなし(自分の権限で動作)ユーザーの代わりに行動(on-behalf-of)
寿命長い(数ヶ月〜数年)短い(セッション/タスク単位)
監査単位サービス単位ユーザー x エージェント x タスク単位
攻撃面キー漏洩キー漏洩 + prompt injection + ツール誤用

ワークロードの領域では SPIFFE/SPIRE が「シークレットレスなアイデンティティのブートストラップ」という模範解答を作ってきました。ワークロードはデプロイ時にシークレットを注入される代わりに、ランタイム属性(Kubernetes ServiceAccount、ノードの身元など)による attestation を経て、短寿命の SVID(X.509 または JWT)の発行を受けます。

SPIFFE ID の例:
spiffe://example.com/ns/payments/sa/payment-processor

発行フロー:
ワークロード ──(attestation: k8s SA, node)──> SPIRE Agent ──> SPIRE Server
   ^                                                              │
   └────────── 短寿命 SVID(自動ローテーション)──────────────────┘

エージェントアイデンティティも同じ原則の上に建てるべきです — 長寿命の静的シークレット(static secret)の代わりに、検証可能な属性に基づく短期クレデンシャル。ただしエージェントはワークロードと違い、「誰の代わりに行動するのか」という委任の次元が加わるため、SPIFFE だけでは足りず、OAuth の委任メカニズムと組み合わせる必要があります。

ここから3つの難題が出てきます。

難題 1 — on-behalf-of 委任チェーン

「ユーザー jane がエージェント A に指示し、A がツールサーバー B を呼び、B が内部 API C を呼んだ」というチェーンで、C は誰の権限で判断すべきでしょうか? jane? A? 両方?

正解は「両方」です。行為者(actor)と委任者(subject)の両方を追跡しなければなりません。エージェントが jane のすべての権限をそのまま継承すれば過剰権限であり、エージェント自身の権限だけを使えば監査の追跡が切れます。このための標準装置が、後で扱う token exchange(RFC 8693)の act クレームです。

難題 2 — 最小権限の動的適用

エージェントの作業は動的なので、「このエージェントに必要な権限リスト」を事前に固定するのは困難です。かといって広範な scope を与えると、prompt injection 一発で全権限が奪取されます。実務の方向性は、タスク単位の短寿命トークン + きめ細かい認可(ReBAC/ABAC)のリアルタイム評価 + human-in-the-loop 承認の組み合わせです。

難題 3 — 監査と帰属(attribution)

規制の観点では、「誰がこの作業をしたのか」に「エージェントです」という答えは通用しません。すべてのエージェント行為は(委任した人間、エージェント識別子、タスクコンテキスト、使用されたトークンチェーン)に帰属可能でなければなりません。ログスキーマを今設計しておかないと、後から遡及できません。

MCP Authorization — OAuth 2.1 ベースの標準の詳細

MCP(Model Context Protocol)は AI アプリケーションとツール/データソースを接続するオープンプロトコルです。2025年を経て MCP の authorization 仕様が OAuth 2.1 ベースに整備され、これがエージェント認証の事実上の標準軌道になりました。

中核構造: MCP サーバーは OAuth 2.1 の resource server(RS)であり、MCP クライアントは OAuth クライアントであり、トークン発行は別の authorization server(AS)が担当します。MCP サーバーが直接トークンを発行せず、既存の IdP(例: Keycloak)に委任できる点が、エンタープライズ統合の鍵です。

全体のフローは次のとおりです。

MCP Client                MCP Server (RS)           Authorization Server
    |                          |                          |
    | 1. MCP リクエスト(トークンなし)                    |
    |------------------------->|                          |
    | 2. 401 + WWW-Authenticate|                          |
    |    (resource_metadata URL)                          |
    |<-------------------------|                          |
    | 3. GET /.well-known/oauth-protected-resource        |
    |------------------------->|                          |
    |    (authorization_servers のリストを返却)           |
    | 4. GET /.well-known/oauth-authorization-server      |
    |---------------------------------------------------->|
    |    (AS メタデータ: endpoints、PKCE 対応など)        |
    | 5. Authorization Code + PKCE フロー                 |
    |---------------------------------------------------->|
    |    (resource パラメータで対象 MCP サーバーを明示)   |
    | 6. access_token (aud = MCP サーバー)                |
    |<----------------------------------------------------|
    | 7. MCP リクエスト + Bearer トークン                 |
    |------------------------->|                          |
    |    トークン検証 (aud、署名)                         |

構成要素をひとつずつ分解します。

Authorization Server Discovery

MCP クライアントはどの AS を使うべきか事前知識がありません。そこで2段階のディスカバリを経ます。

  1. Protected Resource Metadata(RFC 9728): MCP サーバーが 401 レスポンスの WWW-Authenticate ヘッダーで自分のリソースメタデータ URL を知らせ、クライアントがそれを照会して、そのリソースを保護する AS のリストを得ます。
{
  "resource": "https://mcp.example.com",
  "authorization_servers": ["https://sso.example.com/realms/agents"],
  "bearer_methods_supported": ["header"],
  "scopes_supported": ["mcp:tools:read", "mcp:tools:execute"]
}
  1. Authorization Server Metadata(RFC 8414): 続いて AS の well-known エンドポイントから、認可/トークンエンドポイントやサポート機能(PKCE、DCR など)を取得します。

Resource Indicators — トークン誤用の防止

MCP 仕様は RFC 8707 Resource Indicators を必須としています。クライアントはトークンを要求するとき、resource パラメータで「このトークンはこの MCP サーバー用」と明示し、AS はトークンの aud(audience)をそのサーバーに限定します。

POST /realms/agents/protocol/openid-connect/token HTTP/1.1
Host: sso.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=AUTH-CODE-VALUE
&code_verifier=PKCE-VERIFIER-VALUE
&client_id=my-agent
&resource=https://mcp.example.com

これが防ぐのは confused deputy / トークン再利用の攻撃です。resource の限定がなければ、悪意ある MCP サーバーが受け取ったトークンを別の MCP サーバーに再提出する攻撃が可能になります。MCP サーバー側も必ず自分を aud としないトークンを拒否しなければならず、受け取ったトークンを上流 API にそのまま渡す(passthrough)ことは明示的に禁止されています。

OAuth 2.1 という土台

MCP が OAuth 2.0 ではなく OAuth 2.1 draft を土台にしたことの意味は大きい。OAuth 2.1 は RFC 6749 + PKCE(RFC 7636)+ Security BCP(RFC 9700)を統合しつつ、Implicit/ROPC グラントを削除し、すべてのクライアントに PKCE を義務化しました。エージェントのような自動化されたクライアントが大量に登場する環境で、安全でない選択肢そのものをなくしたのです。

CIMD — Client ID Metadata Document と Keycloak 26.6

MCP エコシステムには、OAuth の古典的な前提と衝突する点がひとつあります。クライアントの事前登録です。数万の MCP クライアント(エージェント、IDE、デスクトップアプリ)が任意の MCP サーバー/AS と初めて出会う状況で、管理者がいちいちクライアントを登録するモデルはスケールしません。Dynamic Client Registration(RFC 7591)はありますが、匿名登録を開放するとゴミクライアント登録が積み上がる運用負担があります。

これに対する新しい答えが CIMD(OAuth Client ID Metadata Document) です。アイデアはシンプル — クライアント ID として HTTPS URL を使い、その URL でクライアントメタデータ文書をホスティングします。

{
  "client_id": "https://agent.example.dev/oauth/client-metadata.json",
  "client_name": "Example Coding Agent",
  "client_uri": "https://agent.example.dev",
  "redirect_uris": ["https://agent.example.dev/oauth/callback"],
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

AS は初めて見る client_id(URL)に出会うと、その URL からメタデータを取得して検証/キャッシュします。事前登録なしでも、クライアントの身元(ドメイン所有に基づく)と redirect URI の完全性を確保できます。

Keycloak 26.6 がこの CIMD を実験的にサポートし始めたことは大きなシグナルです。意味を解きほぐすと:

  • Keycloak が MCP エコシステムの authorization server の役割を公式に狙い始めました。企業はすでに運用中の Keycloak realm をそのままエージェント/MCP 認証基盤に拡張できます。
  • 26.6 の他の機能 — JWT Authorization Grant、Federated client authentication、FAPI 2.0 final 対応 — と合わせて見ると、「人間のログイン用 IdP」から「人間 + ワークロード + エージェントの統合トラストアンカー」への方向転換が読み取れます。
  • 実験(preview)機能なので、本番適用前に機能フラグと制限(メタデータキャッシングポリシー、信頼ポリシー設定)を必ず確認すべきです。
# Keycloak 26.6 で preview 機能を有効化する例
/opt/keycloak/bin/kc.sh start \
  --features=preview \
  --hostname=sso.example.com

実践 — MCP サーバーを Keycloak で保護する

概念をコードに移してみます。社内の MCP サーバー(例: 社内 Wiki 検索ツールサーバー)を Keycloak realm で保護する最小構成です。

まず MCP サーバー用の client scope と audience を準備します。

# 1. MCP サーバーを表す client scope を作成
/opt/keycloak/bin/kcadm.sh create client-scopes -r agents \
  -s name=mcp-wiki \
  -s protocol=openid-connect

# 2. audience マッパーを追加 — トークンの aud を MCP サーバーに限定
/opt/keycloak/bin/kcadm.sh create \
  client-scopes/SCOPE-ID/protocol-mappers/models -r agents \
  -s name=mcp-wiki-audience \
  -s protocol=openid-connect \
  -s protocolMapper=oidc-audience-mapper \
  -s 'config."included.custom.audience"=https://mcp-wiki.internal.example.com' \
  -s 'config."access.token.claim"=true'

MCP サーバー側は一般的な OAuth resource server です。Spring ベースなら設定は見慣れた形です。

# application.yaml — MCP サーバーのリソースサーバー設定
spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://sso.example.com/realms/agents
          audiences:
            - https://mcp-wiki.internal.example.com

// aud 検証 + トークン passthrough 禁止を明示したセキュリティ設定
@Configuration
@EnableWebSecurity
public class McpSecurityConfig {

    @Bean
    SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/.well-known/**").permitAll() // RFC 9728 メタデータ
                .anyRequest().authenticated())
            .oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()));
        return http.build();
    }

    // 重要: このサーバーが受け取った Bearer トークンを上流 API 呼び出しに
    // そのまま転送しない。上流の権限が必要なら、
    // token exchange で別の aud 限定トークンを取得する。
}

そして 401 レスポンスに RFC 9728 ディスカバリ用のヘッダーを付けます。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata=
  "https://mcp-wiki.internal.example.com/.well-known/oauth-protected-resource"

この4つのピース — audience 限定の発行、issuer/aud の検証、メタデータの公開、passthrough の禁止 — が MCP サーバーセキュリティの骨格です。

Token Exchange と Transaction Tokens — 委任チェーンの実装

エージェントの委任チェーンを標準トークンで実装する道具が RFC 8693 Token Exchange です。エージェントはユーザートークンを受け取り、ダウンストリーム API 用の**権限縮小(scope-down)+ 行為者明示(act クレーム)**トークンに交換します。

POST /realms/agents/protocol/openid-connect/token HTTP/1.1
Host: sso.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=USER-ACCESS-TOKEN
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&requested_token_type=urn:ietf:params:oauth:token-type:access_token
&audience=internal-api
&scope=tickets:read

交換されたトークンのペイロードには委任構造が明示されます。

{
  "iss": "https://sso.example.com/realms/agents",
  "sub": "user:jane",
  "aud": "internal-api",
  "scope": "tickets:read",
  "act": {
    "sub": "agent:support-bot"
  },
  "exp": 1781234567
}

sub は依然として jane(委任者)であり、act.sub が実際の行為者(エージェント)です。チェーンが深くなると act がネストし、委任経路全体がトークンの中に保存されます。監査ログはこの2つの値を両方記録すればよいのです。Keycloak は 26.2 から標準の token exchange(V2)を正式サポートしています。

さらに一歩進んだものが、IETF OAuth WG で議論中の Transaction Tokens(draft) です。外部から入ってきたトークンをゲートウェイで単一トランザクション範囲の短寿命(分単位)の内部トークンに交換し、マイクロサービスチェーンの内部で外部トークンが出回るのを防ぎ、呼び出し経路全体にユーザー/エージェントのコンテキストを不変に伝播します。エージェントが複数の内部サービスを連鎖呼び出しするアーキテクチャで特に注目に値します。

外部                          ゲートウェイ                内部サービス群
user/agent token  ──────>  Token Service で交換    ──>  txn-token (寿命5分、
(寿命1時間、広範)          (RFC 8693 スタイル)          トランザクション限定、
                                                        委任チェーンクレーム入り)

transaction token のペイロードの概念例です。トランザクション識別子(txn)、リクエストコンテキスト、委任チェーンが不変に焼き付けられます。

{
  "iss": "https://txn-token-service.internal.example.com",
  "aud": "internal-services.example.com",
  "txn": "97f2dbd1-2275-4f4c-a8b3-1e9d2c4f5a6b",
  "sub": "user:jane",
  "exp": 1781234867,
  "purp": "ticket-escalation",
  "azd": {
    "actor_chain": ["agent:support-bot", "svc:ticket-api"],
    "client_ip": "203.0.113.10"
  }
}

Verifiable Credentials — アイデンティティの脱中央集権化

もうひとつの大きな流れが**検証可能な資格証明(Verifiable Credentials、VC)**です。W3C VC Data Model 2.0 が2025年に公式勧告となり、EU の eIDAS 2.0 規則はすべての加盟国に EU Digital Identity Wallet の提供を義務付け、巨大な実利用ケースを作り出しています。

VC モデルの三角形は次のとおりです。

   Issuer(発行者)                       Verifier(検証者)
   例: 政府、大学、雇用主                例: 銀行、サービス提供者
        \                                      /
         \  VC 発行(署名)        VP 提示   /
          \                               /
           v                             v
              Holder(保有者)— ウォレットアプリ
              資格証明を保管し、選択的に提示

OIDC との決定的な違いは、提示(presentation)の時点で発行者がオンラインである必要がなく、発行者が利用履歴を追跡できない点です。selective disclosure(SD-JWT VC)を使えば、「成人であること」だけを証明して生年月日は隠すという最小開示も可能です。SD-JWT の概念を単純化した例です。

{
  "iss": "https://issuer.gov.example",
  "vct": "https://credentials.example/identity_credential",
  "cnf": {
    "jwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." }
  },
  "_sd": [
    "hash-of-given-name-disclosure",
    "hash-of-family-name-disclosure",
    "hash-of-birthdate-disclosure",
    "hash-of-age-over-18-disclosure"
  ],
  "_sd_alg": "sha-256"
}

資格証明の本文には各属性のハッシュだけが入っており、保有者は提示時点で公開する属性の disclosure(原文 + salt)だけを選んで同封します。検証者はハッシュ照合で完全性を確認できますが、同封されなかった属性は知り得ません。cnf クレームの鍵で保有者バインディング(holder binding)まで証明されるため、盗まれた資格証明の再利用も遮断されます。

OpenID Foundation の OID4VCI/OID4VP プロトコルが発行/提示フローを標準化しており、Keycloak も OID4VCI 発行者機能を実験的に育てています。

エンタープライズ観点での短期的な活用先は、B2C の本人確認(KYC の再利用)、従業員オンボーディング(学位/経歴の検証)、そして B2B パートナーの資格証明です。

ディープフェイク時代の Identity Proofing

パスキーが認証(authentication)を守っても、身元確認(identity proofing) — アカウント開設やアカウント復旧時の「この人は本当にその人か」の確認 — が弱ければ全体が崩れます。そして2026年の身元確認は、生成 AI との軍拡競争の真っ只中にあります。

  • ビデオ通話ベースの確認はリアルタイムディープフェイクで迂回された事例が多数報告されています。ヘルプデスクを騙して MFA をリセットさせるソーシャルエンジニアリング(2023年の MGM 事件のパターン)は、いまや音声/映像合成で武装しています。
  • 対応の方向性: 書類 + 生体 + アクティブなライブネス検証(指示反応型)、デバイスシグナルとのクロスチェック、NIST SP 800-63A の IAL レベルに応じた段階的手続き、そして高リスク操作(復旧、権限昇格)に対する多チャネル確認。
  • 構造的な解決策は上で扱った VC です。政府発行のデジタル身分証明をウォレットから提示してもらえば、映像ベースの確認自体を減らせます。

ヘルプデスクのアカウント復旧手続きをディープフェイク前提で再設計すること — これが2026年に最も過小評価されているセキュリティ課題かもしれません。

エージェント IAM アンチパターン — 今止めるべきこと

新しい領域ほど悪い慣行が早く固まります。現場ですでに観察されているアンチパターンです。

  1. 人間のアカウント共有: エージェントに従業員の ID/パスワードや個人 API トークンをそのまま持たせる方式です。監査の追跡が消え、従業員の退職でエージェントが止まり、トークン漏洩時には人間の全権限が露出します。エージェントは必ず独立したアイデンティティ + 委任トークンで。
  2. 万能 service account: エージェントプラットフォーム全体がひとつのスーパーサービスアカウントですべてのダウンストリームを呼ぶ構造。どのエージェントのどのタスクだったのか区別が不可能で、最小権限が根本から壊れます。
  3. 長寿命の静的 API キー: エージェントの設定ファイルに埋め込まれた無期限のキーは、prompt injection で漏洩した瞬間にゲームオーバーです。短期トークン + 自動ローテーションが基本です。
  4. scope なしの広域トークン: 「とりあえず動かそう」と admin scope のトークンをエージェントに付与すること。エージェントの誤動作/誤用が即座にシステム全体の損傷につながります。
  5. ツール応答を信頼境界の内側に: MCP ツールが返したコンテンツに含まれる指示文をエージェントがそのまま従う indirect prompt injection は、認可バイパスの新しい経路です。ツール応答は外部入力として扱い、権限変更系の行為には別途の承認ゲートを置いてください。
  6. MCP トークン passthrough: MCP サーバーが受け取ったトークンをそのまま上流に渡すのは仕様違反であり、confused deputy への近道です。必ず token exchange で再発行してください。

実務者が今準備すべきこと — チェックリスト

最後に、上記の流れを実行可能なチェックリストにまとめます。

インベントリとガバナンス

  1. NHI インベントリを作ってください — サービスアカウント、API キー、ワークロード証明書、そしてエージェント。「我々の組織にエージェントアイデンティティはいくつあるか」に答えられないなら、それが最初の課題です。
  2. エージェントアイデンティティのライフサイクル(作成/権限付与/失効/廃棄)ポリシーを、人間のアカウントとは分離して定義してください。
  3. 監査ログのスキーマに委任チェーンのフィールド(subject、actor、task context)を追加してください。

プロトコルとインフラ

  1. OAuth 2.1 基準で既存クライアントを点検してください — Implicit/ROPC の残存有無、PKCE 未適用のクライアント。
  2. IdP(Keycloak など)の token exchange サポートを検証し、scope-down 交換パターンを標準ライブラリ化してください。
  3. MCP サーバーを運用しているなら、RFC 9728 メタデータ、aud 検証、トークン passthrough 禁止を実装してください。
  4. Keycloak 26.6 の CIMD のような実験機能をステージングで評価し、エージェントクライアントのオンボーディングモデル(DCR vs CIMD)を決定してください。

セキュリティ運用

  1. エージェント用トークンの寿命をタスク単位(分)に短くし、refresh ポリシーを保守的に設定してください。
  2. 高リスクのツール呼び出しに human-in-the-loop 承認ゲートを入れてください。
  3. アカウント復旧/ヘルプデスク手続きをディープフェイクシナリオで脅威モデリングしてください。
  4. VC/デジタルウォレットの規制動向(eIDAS 2.0、各国のデジタル身分証)を四半期単位で追跡し、KYC フローでの VC 受け入れ可能性を評価してください。

おわりに

2026年の IAM は「人間がパスワードでログインするシステム」から「人間、ワークロード、エージェントが検証可能なアイデンティティと委任チェーンで相互作用するシステム」へと移行中です。幸いなのは、この転換がまったく新しい技術の上ではなく、OAuth 2.1、token exchange、WebAuthn、VC という既存標準の延長線上で起きているという点です。

だから最良の準備は、華やかな新技術の導入ではなく基本です。トークンに aud を限定し、委任を act で明示し、権限を短く狭く発行し、すべての決定を監査可能な形で残すこと。エージェントの時代でも、良い IAM の原則は変わりません — 適用対象が爆発的に増えるだけです。

参考資料

Discuss on Twitter • View on GitHub