AIエージェントが実際のビジネスデータを扱う「本番環境」に踏み込み始めると、デモ段階では見えなかった問題が一気に顕在化する。「誰でも全部見える」状態でよかったプロトタイプが、リリース直前になって「データ境界をどう守るか」という根本的な問いを突きつけてくる。

CurityとMicrosoftがAzure SDK Blogで公開した新しいazdテンプレートは、まさにその問いに正面から答える試みだ。AIエージェントへの最小権限（Least Privilege）アクセスの実装パターンを、すぐ試せる形で提供している。

問題の本質：エージェントは「予測できない」クライアントだ

従来のクライアントアプリはAPIを決まった手順で呼ぶ。コードを読めば何をするか分かる。しかしAIエージェントは違う。自然言語を解釈して、何を呼ぶかを自分で決める。賢いが、予測不能でもある。

さらにプロンプトインジェクション——悪意あるユーザーが入力を細工してエージェントの動作を乗っ取る攻撃——のリスクも現実にある。エージェント側でいくら「正しい判断」をしようとしても、それだけでは足りない。APIレイヤーで「このトークンではここまでしか見えない」という制約を設けなければ、AIの不完全さや悪用に対して無防備のままだ。

テンプレートの核心：短命トークンと2段階のトークン交換

このテンプレートのポイントは、OAuth 2.0の短命アクセストークンによる認可だ。エージェントはAPIへの恒久的な権限を持たない。必要なときだけ、必要な範囲に絞ったトークンを取得して使う。

注目すべきは2段階のトークン交換設計だ。

  • 第1交換: ユーザーの初期トークンのスコープを絞り込み、不透明トークン（Opaque Token）からJWT（JSON Web Token）に変換する
  • 第2交換: エージェントのIDを付加し、MCPサーバー向けの新しいaudienceに変換する

最終的にPortfolio MCPサーバーに届くトークンには、scope: stocks/read（読み取り専用）、customer_id: 178（Entra IDの属性から取得）、region: USA（参照可能な株式の地域制限）、client_type: ai-agentが含まれる。APIはこれらのクレームを見て、「このリクエストは誰のためのものか・何が許可されているか」を判断できる。エージェントがどんな指示を受けたかは関係ない。

テンプレートの構成

インフラとしては以下が含まれる。

  • バックエンドエージェント: Microsoft Foundry上でC#実装（Microsoft A2A・MCP SDK使用）
  • MCPサーバー: サンプルポートフォリオAPIを公開
  • 認可サーバー: Curity Identity Server（ユーザー認証はMicrosoft Entra IDと連携）
  • ゲートウェイ: 外部・内部APIゲートウェイでトークン交換と監査ログを担当
  • IaC: Bicepで完全自動プロビジョニング（Container Apps、Azure AI Foundry、Key Vault、Azure SQL Database等）

azd up数コマンドでAzureサブスクリプション上に全体が動く状態になる。

実務への影響

日本のエンジニアが今すぐ取り組めるヒント：

まずこのテンプレートをそのまま動かし、トークンの内容がどう変わるかを自分の目で確認してほしい。JWTデコーダーで中身を覗きながら「誰が・何のスコープで・どのAPIを呼べるか」の流れを追うことで、設計の全体像がつかめる。

次に、既存のAIエージェント実装を振り返ってみる価値がある。エージェントに渡しているトークンに有効期限は設定されているか？スコープは最小化されているか？ 「動いているからOK」は安全の証明にならない。特権アカウントやサービスプリンシパルに権限を無期限で与えている構成は、早急に見直すべきだ。

Microsoft Entra IDを使っている環境では、ユーザー属性（部署・地域・ロール等）をトークンのクレームとして活用するカスタムクレームの設定も検討に値する。属性ベースのアクセス制御（ABAC）は、エージェント時代のきめ細かいデータ境界を実現する重要な武器になる。

筆者の見解

AIエージェントがNon-Human Identity（NHI）として組織内で動き始める今、「誰がAPIを呼んでいるか」だけでなく「何のためにどこまで呼べるか」を制御する仕組みが不可欠になっている。

このテンプレートが示す「短命トークン＋2段階交換」のパターンは、ゼロトラストの原則をエージェントに忠実に適用したものだ。常時アクセス権を与えず、必要なときだけ必要なスコープで動かす——これはJust-In-Timeアクセスの考え方そのものであり、特権アカウント管理の世界ではすでに常識になっている。AIエージェントという新しいアクターにも、この原則を妥協なく貫く必要がある。

Microsoft Entra IDをエージェントの「管制塔」として使い、その上でサードパーティの認可サーバーと組み合わせるアーキテクチャは、Azureプラットフォームの強みを素直に活かした設計だ。この方向性は正しいと思う。

あとは、このパターンがテンプレートで終わらず、公式ドキュメントやベストプラクティスとして広く普及するかどうかが鍵だ。設計パターンをいかに「開発者が自然と選ぶ道」にするかが、セキュアなAIエージェント普及の分水嶺になる。

出典: この記事は Least privilege AI agents: A new azd template from Curity and Microsoft の内容をもとに、筆者の見解を加えて独自に執筆したものです。