すべての AI エージェントプロジェクトには、こんな瞬間があります: デモは完璧に機能し、エージェントは自然言語を解釈し、正しい API を呼び出し、正しいデータを返します。そして実際のユーザーについて考え始めます。
あるユーザーのエージェントセッションが別のユーザーのデータを見るのを何が防ぐのでしょうか？エージェントがプロンプトインジェクションで騙された場合はどうなるでしょうか？予期しない方法でツールを呼び出した場合はどうなるでしょうか？
これらはエッジケースではありません。これらはリリース前に行うべき設計上の決定です。
Curity と Microsoft による新しい azd テンプレートは、まさにこの問題に対して機能するリファレンスを提供します。
核心的な問題: 認証 ≠ 認可
ほとんどのエージェントサンプルはユーザー認証をうまく処理しています。認可の処理は不十分です。ユーザーが誰であるかを知っていても、彼らが見るべきデータが何かはわかりません。
従来のクライアントアプリは予測可能な API 呼び出しを行います。AI エージェントは非決定論的です — 自然言語を解釈し、何を呼び出すかを決定します。創造的になれます。また間違える可能性もあります。プロンプトインジェクションによって操作される場合、AI が適切に動作することに依存しないルールが必要です。
このテンプレートが示す解決策: 各ホップに正確に正しい情報を運ぶ短命のトークン。
トークンチェーンの仕組み
テンプレートは OAuth 2.0 アクセストークンとトークン交換を使用して、各ステップで権限を絞り込みます。ユーザートークンは MCP サーバーに到達する前に 2 回交換されます:
- 最初の交換 — スコープを絞り込み、不透明なトークンを JWT に変換
- 2 番目の交換 — エージェント ID と MCP サーバーホップのための新しいオーディエンスを追加
MCP サーバートークンがどのように見えるか:
{
"scope": "stocks/read",
"sub": "62c839b8...",
"aud": "https://mcp.demo.example",
"customer_id": "178",
"region": "USA"
}
customer_id は認可サーバーによってトークンに組み込まれており、エージェントが制御するパラメータとして渡されません。API はエージェントの指示ではなく、トークンをチェックします。
これが意味すること: エージェントが別の顧客のデータを取得しようとするよう騙されたとしても、トークンはそれを認可しません。
テンプレートがデプロイするもの
いくつかの azd コマンドで次のものが得られます:
- Microsoft Foundry 上のバックエンドエージェント（C#、Microsoft A2A および MCP SDK）
- サンプルポートフォリオ API を公開する MCP サーバー
- 認可サーバーとして Curity Identity Server、認証のために Entra ID と並行して
- トークン交換と監査ログを処理する外部および内部 API ゲートウェイ
- Azure インフラストラクチャ全体の Bicep: Container Apps、VNet、ACR、Azure AI Foundry、Key Vault、Azure SQL Database、ストレージ
パターン全体は検査可能でカスタマイズ可能です。
借りる価値のある設計原則
Curity を使用しない場合でも、パターンは転用可能です: エージェントは永続的な API アクセスを決して持つべきではありません。すべてのアクションは、その特定の呼び出しに必要な最小スコープを持つ短命のトークンを使用し、特定のエージェント ID に対して発行され、API が認可の決定を行うために必要なクレームを運ぶべきです。
これは創造的なエージェント、ミス、プロンプトインジェクションに対して「エージェントが悪いことをしないようにするだけ」では決して耐えられない方法で耐えます。
まとめ
AI エージェントのセキュリティパターンは、業界全体でまだ整理されています。このテンプレートは私が見た中で最も完全なリファレンス実装の 1 つです — 認証だけでなく、実際の認可フローをカバーしています。
元の投稿: Least privilege AI agents: A new azd template from Curity and Microsoft
