はじめに

AIエージェント（Agent）が社内のCRM、データベース、または社内Wikiなどのシステムに直接接続し、業務を自動化する事例が増えています。しかし、この「エージェントの自律性」には重大なセキュリティリスクが潜んでいます。

従来のWebアプリケーションでは、ユーザーがログインしたセッション情報やトークンを使用してAPIを呼び出します。もしAIエージェントが「ユーザーになりすまして」システムにアクセスする場合、通常はユーザーと同じ広範な権限（フルアクセス）を持ってしまいます。これが問題なのは、エージェントが悪意あるプロンプトインジェクション攻撃を受けた際、あるいはバグによって誤った操作を行った際、その被害範囲が極めて大きくなる点です。

本稿では、この課題を解決する新たな標準として注目されているID-JAG（Identity Assertion JWT Authorization Grant）の概念を解説し、なぜそれが従来のOAuth2やサービスアカウントと異なるのか、そしてGo言語を用いた実装においてどのような設計判断が必要なのかを、技術的な深掘りを通じて述べます。

既存の権限委譲モデルの限界

AIエージェントが外部リソースにアクセスする際、一般的に以下の2つのアプローチが取られてきました。しかし、どちらも「最小権限の原則（Principle of Least Privilege）」の実装において課題を抱えています。

1. サービスアカウント（API Key）

エージェント専用のIDとパスワード、またはAPIキーを使用する方法です。これは設定が簡単ですが、問題があります。サービスアカウントは通常、特定のアプリケーション全体を代表する権限を持つため、権限が強すぎます（Over-provisioned）。また、誰の操作でリソースにアクセスしたかの監査証跡（Audit Trail）として、ユーザー固有のコンテキストが含まれない場合があります。

2. ユーザーセッションの委譲（OAuth2 Implicit/Device Flowなど）

ユーザーのブラウザ上での承認を得て、ユーザーに代わってAPIを呼び出す方法です。しかし、従来のOAuth2フローでは、取得したアクセストークンは「ユーザーの全権限」を表すことが多く、エージェントが「どのリソースに対して、どの程度の期間、何ができるのか」という詳細な制約（ダウンスコーピング）を適用するのが複雑でした。

さらに、エージェントが長時間プロセスを実行する場合、ユーザーのブラウザセッション切れに伴いトークンが無効化されるリスクもあり、信頼性の面で課題が残ります。

ID-JAGの核心：ダウンスコーピングとJWT Bearer

ID-JAGは、IETFのInternet-Draftとして提案されている仕組みで、AIエージェントがユーザーに代わってリソースサーバー（Resource Server）にアクセスする際の権限を、細かく制御することを目的としています。その鍵となる概念が「ダウンスコーピング（Downscoping）」です。

ダウンスコーピングとは、元のトークンが持つ権限の一部だけを切り取り、より制限された範囲の新しいトークンを発行するプロセスを指します。ID-JAGはこのプロセスを標準化し、エージェントごとに固有で最小限の権限付与を可能にします。

RFC 8693: Token Exchange

ID-JAGの実装基盤となるのは、RFC 8693（OAuth 2.0 Token Exchange）です。これは、既存の資格証明（ユーザーのトークンなど）を交換して、新しい、より制限された資格証明を取得するための標準プロトコルです。

従来のOAuth2では、認可コードフローで取得したトークンをそのまま使いましたが、Token Exchangeを用いることで、以下のような流れが可能になります：

  1. エージェントがリソースサーバーに対し、ユーザーの元のトークンと「希望する権限スコープ」を提示
  2. リソースサーバー（または権限管理サーバー）が、その要求を検証
  3. 条件を満たす場合、新しいアクセストークン（ダウンスコープされたもの）を発行

この新しいトークンは、元のユーザーの全権限ではなく、「エージェントに必要な最小限の操作」のみを含むJWT（JSON Web Token）として発行されます。これにより、仮にトークンが漏洩しても、被害を限定できます。

Go言語での実装設計：Athenzとの連携

ID-JAGの概念を実装する際、多くの事例でAthenzというオープンソースのアイデンティティ・アクセス管理システムが参照されます。Athenzは、サービス間の認証と承認を強力にサポートします。ここでは、Go言語を用いてMCP（Model Context Protocol）サーバーからID-JAGフローを実装する際の設計指針を示します。

アーキテクチャの概要

以下のコンポーネントが連携します：

  • Client（Agent）: ユーザーに代わってAPIを呼び出すAIエージェント。Goで実装されることが多い。
  • Token Server（STS）: 資格証明を交換し、新しいトークンを発行するサーバー。AthenzのSTS（Security Token Service）などが該当。
  • Resource Server: 実際のデータやAPIを提供するサービス。

Goでの実装ステップ

ID-JAGフローをGoで実装する場合、主要なステップは以下の通りです。ここでは具体的なライブラリ名に依存せず、論理的な手順を示します。

ステップ1: ユーザー資格証明の取得

まず、エージェントがユーザーから承認を得て、元のアクセストークン（またはRefresh Token）を取得する必要があります。これは通常のOAuth2フローと同様です。

// 擬似コード: ユーザーからの承認トークンの取得
userToken := oauth2.GetAccessToken(userID, scope="full_access")

この段階では、まだエージェント固有の制限は適用されていません。

ステップ2: トークン交換リクエストの構築

次に、STSに対して「ダウンスコープされたトークン」を要求します。ここで重要なのは、subject（対象者）とrequested_scope（要求されるスコープ）を明確に指定することです。

// 擬似コード: トークン交換リクエストの生成
tokenExchangeRequest := &TokenExchangeRequest{
    GrantType: "urn:ietf:params:oauth:grant-type:token-exchange",
    SubjectToken: userToken,
    SubjectTokenType: "urn:ietf:params:oauth:token-type:access_token",
    // ここでエージェント固有の最小スコープを指定する
    Scope: "read:crm_contacts write:crm_opportunities",
    Audience: "resource-server-api",
}

このリクエストは、HTTPS経由でSTSに送信され、JWT Bearer Grantとして扱われることが多いです。Goの標準パッケージやなどのライブラリを用いて、JWTの署名と検証を行います。

ステップ3: トークンの検証と使用

STSから返された新しいトークンは、元のユーザートークンとは異なるクレームセットを持っています。エージェントはこのトークンをResource Serverのヘッダー（Authorization: Bearer ...）に設定してAPIを呼び出します。

Resource Server側では、このJWTを検証し、scopeフィールドに基づいてアクセス制御を行います。例えば、「write:crm_opportunities」のスコープしか持たないトークンが「delete」操作を試みた場合、403 Forbiddenを返すことができます。

設計上のトレードオフと落とし穴

ID-JAGの実装には、いくつかの重要な判断点があります。

1. トークンのライフタイム管理

ダウンスコープされたトークンは、元のユーザーセッションよりも短い有効期限（TTL）に設定するのが一般的です。これにより、漏洩時のリスクを軽減します。しかし、エージェントが長時間のプロセスを実行する場合、頻繁なトークン更新が必要になり、オーバーヘッドが増加します。対策として、Refresh Tokenを用いた自動更新フローを設計するか、STS側でセッションの継続性を保証する仕組みを導入する必要があります。

2. スコープの粒度

スコープを細かくしすぎると、管理が複雑になります（スコープ爆発）。逆に粗すぎると、最小権限の原則が生きてきません。Goでの実装では、スコープ定義をコード内でハードコードせず、外部設定ファイルやAthenzなどの中央管理システムから動的に取得する設計が推奨されます。

3. 監査証跡の確保

ID-JAGの最大の利点は、誰が（どのエージェントが）、いつ、何を行ったかを追跡できることです。Resource Serverのログには、ダウンスコープされたトークンに含まれるsub（サブジェクト）やiss（発行者）IDを必ず記録する必要があります。これにより、問題発生時に「ユーザーAのエージェントBが操作Xを実行した」という具体的な因果関係を追跡できます。

なぜGoなのか？

AIエージェントの実装言語としてGoが選ばれる理由はいくつかあります。

  • JWT処理の標準ライブラリ: Goにはgolang.org/x/oauth2やJWT用の成熟したライブラリがあり、RFC 7519（JWT）やRFC 8693（Token Exchange）の要件を満たす実装が比較的容易です。
  • 高性能な並行処理: AIエージェントは複数のAPI呼び出しを並列に行うことが多く、Goのgoroutineとchannelによる軽量な並行処理モデルは、高いスループットを実現するのに適しています。
  • シングルバイナリ配布: 依存関係が少ないため、Kubernetesなどのコンテナ環境へのデプロイが容易で、セキュリティパッチの適用管理がシンプルになります。

まとめ

AIエージェントの普及に伴い、「権限委譲」は単なる技術課題から、セキュリティとガバナンスの核心的な課題へと変貌しました。ID-JAGおよびその基盤となるToken Exchange（RFC 8693）は、エージェントに必要最小限の権限のみを付与する「ダウンスコーピング」を実現するための重要な標準です。

実装においては、単にトークンを交換するだけでなく、スコープの粒度、ライフタイム管理、監査証跡の確保といった設計判断が求められます。Go言語は、これらのセキュリティ要件を満たす堅牢な基盤を提供します。

中小企業やスタートアップであっても、AI導入初期からID-JAGのような現代的な権限管理モデルを採用することで、将来のスケーラビリティとセキュリティリスクを同時に軽減することができます。技術選定の際は、従来のOAuth2慣習にとらわれず、エージェント固有のセキュリティ要件を見直してみてください。

参考

本記事は海外の技術トレンド「[Learning Notes][Golang] Authorization Challenges in the AI Agent Era: What is ID-JAG and Why I Re-implemented It in Go」（DEV）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。

記事一覧に戻る