Investigating suspicious AI workflows in Microsoft Entra Agent ID: Autonomous agents

AI agents are rapidly on their way to becoming the dominant actor within the environments we’re responsible for securing. Fortunately, vendors are starting to treat this new reality seriously by giving agents their own unique class of identity that can be managed, governed, and audited independent of human and traditional workload identities. However, detecting and responding to threats targeting this new class of identities will be fundamentally different than traditional identity threat detection and response. For example, establishing a baseline for what constitutes expected agent behavior will be distinctly unique from human identities. Additionally, when an agent behavioral baseline deviates from expected behavior, the approach to investigation will also be unique.

In order to detect and investigate agent identity activity, it’s important to bear in mind the following paradigm:

1. You can’t respond effectively to what you don’t understand.
2. You can’t investigate what you can’t detect.
3. You can’t detect what you can’t see.

As with any security domain, it’s essential to be aware of what data sources are available and just as importantly, how to tell an effective story so that defenders can develop detective controls that confidently and efficiently identify threats.

In the realm of agent identities, distinguishing an agent identity from human and workload identities is foundational to detection and response.

In this three-part series, we will investigate three potentially suspicious behaviors originating from each of Microsoft’s Entra Agent ID supported agent workflows, specifically:

1. Autonomous agents (covered in this post) – aka Agent autonomous app OAuth flow
   • Scenario: An autonomous agent made unauthorized changes to the Entra tenant that could be used to perform privilege escalation and persistence.
2. Agent’s user account – aka Agent’s user account impersonation
   • Scenario: An agent user sent a suspicious link in a Teams channel to a human user.
3. Assistive agents – aka the On behalf of flow
   • Scenario: An assistive agent, acting on behalf of a human user sent a suspicious email.

For each scenario, we will apply the “minimum viable storytelling” methodology to identifying key data fields, assessing data quality, and articulating the event in an approachable manner.

Before proceeding, I’d like to offer my gratitude to Jared Atkinson, Chief Technology Officer at SpecterOps, who prompted me to start learning about and investigating Microsoft Entra Agent ID.

Background and helpful references

This series assumes some knowledge of Microsoft Entra Agent ID terminology and concepts. To learn more, we recommend the following resources:

1. Agent 365 and Agent ID Overview
2. What is Microsoft Entra Agent ID?
3. Digging deep into Entra agent identities – #1

The following key concepts will be most important to understand:

Agent identity blueprint

An agent identity blueprint is an extension of an application object, aka App Registration, in Entra but tailored specifically to agent identity scenarios. As the name implies, it serves as the blueprint or template for agent identities that share a common purpose, specifically, in terms of what permissions it requires. So if a vendor wanted to host the agentic app, they would create an agent identity blueprint that you, in your tenant, would create an instance of. The instance of a blueprint in your tenant is an agent identity blueprint principal, highlighted in the next section.

Among all the Agent ID components, authentication via supplied credentials occurs only with the blueprint. This means that if an adversary either compromises existing blueprint credentials or has permission to add credentials to blueprints, as will be highlighted in this post, they will have the ability to authenticate as any blueprint principal and subsequently, any agent identity.

The privileged Agent ID Administrator role was designed to manage Agent ID as well as the AgentIdentityBlueprint.* app roles. If an agent is assigned any of these privileged roles, as we will see, your tenant risks compromise. Additionally, blueprints, blueprint principals, and agent identities can all have an owner assigned to them: a human user who is responsible for managing the agent lifecycle. If an owner is compromised, then regardless of their assigned Entra roles, they will have permission to authenticate as and tamper with agent infrastructure.

Agent identity blueprint principal

An agent identity blueprint principal comprises an instance of an agent identity blueprint in your tenant. It is an extension of a service principal object, aka enterprise application, but specifically tailored to facilitate the creation of and authorization of agent identities (described in the next section).

By default, all blueprint principals are assigned the AgentIdentity.CreateAsManager app role as it is one of their primary roles to create child agent identities. As will be seen in the log entries below, when an agent identity performs an action, it is always tied to its parent blueprint principal.

Agent Identity

An agent identity is a new Entra identity class (e.g. user, service principal, managed identity) that is the identity that an agent assumes. It is an extension of a service principal object and is the entity that is designed to perform autonomous actions within the tenant. In most cases, when suspicious agent activity is being investigated, it will originate from an agent identity. While it is technically possible for an agent blueprint principal to perform actions beyond agent identity creation and authorization, it is less likely.

In the following scenario, we will investigate an agent identity that performed a suspicious action on an agent identity blueprint to which it is not a child, which breaks the expected blueprint/principal/agent inheritance. By understanding the relationship between agent identities, blueprint principal, and blueprints, you will be able to better investigate and reason over real-world incidents and differentiate between benign and malicious behaviors.

Scenario: An autonomous agent performed a suspicious, privileged action in your Entra tenant

Imagine receiving the following alert:

Alert summary

At 2026-05-07T17:41:25Z, within Entra ID tenant ID adcb5820-70a1-4272-b79c-32f2bba44ddc, the agent identity Agent001 added a client secret New Blueprint Secret to the agent identity blueprint Prod Agent Identity Blueprint. The action originated from IP address 51.3.97.221 via a Microsoft Graph API POST request with the following user-agent string: Mozilla/5.0 (Macintosh; macOS 26.4.1; en-US) PowerShell/7.6.1.

Alert enrichment context

Agent001 authenticated and was authorized as an autonomous agent which was previously assigned the AgentIdentityBlueprint.AddRemoveCreds.All app role, resulting in the conditions that permitted this action to occur. AgentIdentityBlueprint.AddRemoveCreds.All is a privileged app role that should only be granted to privileged identities, for example, user identities assigned the Agent ID Administrator Entra role.

An agent identity should not be able to add credentials to an agent identity blueprint, as it creates a scenario that breaks the intended agent security model. This action indicates potential privilege escalation and persistence. Additionally, Agent001 is not a child identity of the Prod Agent Identity Blueprint agent identity blueprint principal resulting in an impact outside of the scope of the blueprint to which Agent001 belongs, Dev Agent Identity Blueprint - NOT FOR PROD.

Client secret credentials should never be added to an agent identity blueprint in production unless it is explicitly used for temporary testing purposes.

Corresponding raw data

What is generally hard to come by is the raw event data that was used to derive the alert. The raw data helps to form the complete picture of the action that occurred and should be used as the basis for a complete and relevant threat timeline.

The following raw Log Analytics events constitute a complete timeline:

AuditLogs event analysis

This log supplies the details surrounding the actual behavior that occurred in the Entra tenant. Here is the raw log data, followed by analysis: