Microsoft Entra Agent IDログにより、見過ごされがちながら重大な脅威ベクトルが明らかになりました。それは、OAuth On-Behalf-Of（OBO）フローを利用して委任されたユーザー権限で動作し、外部メール送信などのリスクある操作を実行するアシスティブエージェントの存在です。
調査対象のインシデントでは、件名「Here is your invoice」のメールが、AgentIdによって開始された「送信」操作としてExchange Purviewに記録されていました。
初期のフィールド情報はクライアントIP 40.126.23.26と、macOS上のPowerShellを示すユーザーエージェント文字列を指していました。
しかし、その情報だけでは不完全でした。AppAccessContext.UniqueTokenIdとClientRequestIdを手掛かりにMicrosoftGraphActivityLogsへと調査を展開したところ、/users/{user}/microsoft.graph.sendMailへのGraph POSTリクエストが確認され、実際の送信元IP 51.3.97.221が判明しました。
さらに同一のユニークトークンを使ってAADNonInteractiveUserSignInLogsと照合した結果、Agent001（AppId: 8cd0a10f-0be8-413a-9bf2-f44bc568d1e4）がMail.SendおよびMail.ReadWriteを含むスコープで、[email protected]の代理トークンを取得していたことを示すエージェントサインインレコードが得られました。
Red Canaryの調査によると、Purview Exchangeアクティビティ、Microsoft Graph APIテレメトリ、Azure AD非インタラクティブサインインログを正確にクロスログ相関させることで、エージェントIDがユーザーの代わりに実行したアクションを特定し、その真の発信元とスコープを把握できることが示されています。
Agent.agentTypeには「agenticAppInstance」、agentSubjectTypeには「notAgentic」が設定されており、この2つのフィールドを組み合わせることで、従来のサービスプリンシパルや自律型エージェントのサインインではなく、アシスティブ（OBO）フローであることを識別できます。
この一連の証拠により、最低限必要な事実が明らかになります。すなわち、2026-05-08T15:27:05Zに、Agent001がMicrosoft Graph（ベータ版）を使用して[email protected]の名義で[email protected]へメールを送信しており、その発信元はIP 51.3.97.221、ユーザーエージェントは「Mozilla/5.0 … PowerShell/7.6.1」であったということです。
Microsoft Entra Agent IDログ
記録されたMicrosoft Graphスコープには、ユーザーがaccess_agentスコープに同意した際にエージェントブループリントプリンシパルへ付与された委任権限が示されており、サインインの詳細によるとトークン内のクレームを通じてユーザーごとのMFAが満たされていたことも確認できます。
運用上の教訓は明確かつ即座に実践できるものです。第一に、アシスティブエージェントはエージェントスコープの権限とエンドユーザーに割り当てられたロールの交差点に合致した高インパクトなアクションを実行し得ます。高リスクなGraph権限をブロックすることでリスクは軽減されますが、完全に排除することはできません。
第二に、防御担当者はPurview/Exchangeログ、MicrosoftGraphActivityLogs、AADNonInteractiveUserSignInLogsを横断的に相関分析し、エージェントの活動をユーザーやサービスプリンシパルの活動と明確に区別できるようにする必要があります。
主な相関ピボットは、AppAccessContext.UniqueTokenId ↔ SignInActivityId、ClientRequestId ↔ ClientRequestId、そして一致するSessionId値です。
第三に、agent.agentType == agenticAppInstanceとagent.agentSubjectType == notAgenticの組み合わせはアシスティブOBOフローの信頼性の高い指標です。一方、agentSubjectType == agentIDuserやサインインテーブルの差異は、参照資料に記載されたその他のエージェントシナリオを示しています。
検知ルールの設計者は、呼び出し元がエージェントIDである場合、発信元IPが通常のユーザー所在地と異なる場合、またはスコープセットにMail.ReadWrite/Mail.Sendが含まれる場合に、予期しないMail.Send Graphコールをフラグするルールを実装する必要があります。
On-Behalf-Ofフローとエージェント IDに関するMicrosoftのドキュメント（元の調査内のリンク参照）およびEntra Agent IDに関するRed Canaryのシリーズは、これらのログを解釈するための実践的なガイダンスを提供しています。
ハントワークフローでは、access_agentの同意がどのように付与されたか（リダイレクトURI、同意ダイアログ、ローカルホストキャプチャの可能性）を検証し、エージェントブループリントプリンシパルを確認した上で、federatedCredentialIdとparentAppIdフィールドを調べてブループリントの起源を特定する必要があります。
エージェントの普及が加速する中、防御担当者はアシスティブエージェントを一級のIDタイプとして扱わなければなりません。ログを計測し、相関プレイブックを構築し、エージェントブループリントと同意サーフェスに対して最小権限とモニタリングを徹底することで、エージェントを介した悪用を防止し、または迅速に修復できる体制を整えることが求められます。
翻訳元: https://gbhackers.com/entra-agent-id-logs/
