Introducing Attack Path Management for Entra Agents in BloodHound Enterprise 

AI agents are becoming a new layer of enterprise infrastructure and enterprise identity. 

They answer questions, invoke tools, execute workflows, access data, authenticate to downstream services, communicate with other agents, and increasingly act on behalf of users and applications. In Microsoft’s Entra ecosystem, those capabilities span Entra Agent ID, Copilot Studio, Power Automate, Azure AI Foundry, MCP servers, and external agent-to-agent integrations. 

From a security perspective, that creates a fundamental problem: The identity that invokes an agent is not necessarily the identity the agent ultimately acts as. 

A low-privileged user may invoke an agent that accesses a downstream service using its maker’s identity. A public agent may provide anonymous access to capabilities backed by an authenticated identity. A Power Automate flow may execute through embedded connections, completely decoupled from the identity of the person who triggered it. A Foundry agent may rely on a shared project identity with high Azure privileges.

Compromising a single agent identity blueprint may expose multiple child identities, each with its own access to Entra ID and Azure resources. These issues should not be treated as isolated permission problems, but rather through the adversary’s lens as attack paths. That is what Attack Path Management for Entra agents brings to BloodHound Enterprise.

Attack Path Management for Entra Agents in BloodHound Enterprise

With the BloodHound Enterprise Entra Agents extension, teams can begin modeling these systems as part of the broader BloodHound Enterprise attack graph, connecting agents, identities, users, flows, credentials, cloud resources, and external systems to understand how control propagates through an agentic environment to solve the hidden root cause rather than the obvious symptoms. 

AI agents introduce a rapidly growing class of identities, execution contexts, and trust relationships that existing security tools rarely analyze together. BloodHound Enterprise extends Identity Attack Path Management across Entra Agent ID, Copilot Studio, Power Automate, selected Azure AI Foundry control-plane relationships, and the broader enterprise identity graph. 

These risks are already appearing in real platforms and security research. Microsoft has introduced administrative controls specifically to restrict maker-provided credentials and anonymous agent access, while researchers have demonstrated risks involving Copilot Studio configuration changes and the expanded blast radius of Entra Agent ID blueprints. 

The goal is not simply to inventory AI agents but rather to understand what an attacker can do through these interconnected components. 

Agents Introduce a New Kind of Identity Problem 

Traditional identity security generally starts with a straightforward question: Who is the principal seeking access? 

With agents, that question becomes more complicated. For example, imagine a Copilot Studio agent that a low-privileged user is allowed to invoke. The agent may use maker-provided credentials to access SharePoint, Azure resources, or another downstream system. In this configuration, Microsoft documents that the agent authenticates to the connected service using the maker’s credentials rather than invoking the user’s credentials. The invoking user does not necessarily need direct access to those resources. What matters is the identity the agent uses when performing the action. 

That creates an access-divergence path: 

The user’s direct permissions are no longer enough to determine effective access. The maker’s permissions are what matter, and the access control system is oblivious to the identity transition that occurred.  

This same pattern appears repeatedly across agent platforms. A user invokes an agent. An agent delegates to another agent. A workflow executes through an embedded connection. A Foundry agent assumes an identity. An MCP server influences an agent that also has access to other tools. Each transition can change the security context under which the next action occurs. 

That is precisely the kind of problem BloodHound Enterprise is designed to solve. 

Answer Attacker-Relevant Questions 

The Entra Agents extension is designed around questions that cannot be answered solely through a configuration/access review. 

A configuration review can show who may invoke an agent, which connection it uses, and what permissions the connection owner holds. It generally cannot correlate those facts across Copilot Studio, Power Platform, Entra ID, and Azure; follow changes in execution identity across each hop; or calculate the downstream resources that become reachable. BloodHound Enterprise’s attack graph performs that correlation and transitive analysis. 

Who can invoke an agent that acts as someone else? 

One of the most important relationships in the Entra Agents extension is the AZAgent_ActsAs relationship. 

Consider the simple attack path demonstrated above: An agent configured to authenticate to a downstream service using maker-provided credentials. A low-privileged user may be authorized to invoke the agent, but the agent’s outbound actions execute using the maker’s identity. This is where an apparently harmless permission, such as “can use this agent,” becomes much more interesting. 

BloodHound Enterprise answers the questions of what identity the agent uses after invocation, what that identity can reach, and whether the invoking user would otherwise have had access to those resources. 

Edit access can be even more powerful. A co-author may be able to modify an agent’s instructions, topics, or tool configuration while the agent continues to operate using another identity’s credentials. That gives the attacker influence over both what the agent does and the security context (i.e., identity) under which it does it. 

Seeing each permission separately does not tell the full story. BloodHound Enterprise’s extensible attack graph does. 

Which public agents create a bridge to authenticated resources? 

Now, consider the same problem with no authenticated invoking user in the flow. 

An agent may be configured with no user authentication, allowing anyone with the link to interact with it, while still using maker-provided credentials for outbound actions. In that case, an unauthenticated caller can potentially access resources through an authenticated identity. 

The attack path becomes: 

This is an anonymous-to-authenticated bridge. 

The security violation, or clean source principle violation, is not simply that the agent is public. Public access may be intentional. The problem emerges from the combination of public invocation and a privileged outbound identity. The agent becomes a security dependency of the outbound identity; however, the agent is not as trustworthy as the outbound identity because it can be invoked anonymously. 

Those two configurations may be reviewed by different teams, live in different administrative surfaces, and appear individually as acceptable. Their combined effect is what creates a security violation and an attack path. 

BloodHound Enterprise models these identity transitions directly, allowing defenders to discover where agent execution changes security context, prioritize the resulting attack paths, and understand what critical assets become reachable. 

The issue is rarely one setting in isolation. It is what multiple valid configurations collectively allow an attacker to do. 

What happens if an agent identity blueprint is compromised? 

Entra Agent ID introduces another important control relationship through agent identity blueprints. 

A blueprint may own multiple child agent identities. Those agent identities are also service principals, which means they can have Azure RBAC assignments, Entra ID roles, and other downstream relationships present in the broader environment. 

The extension models that chain directly: 

This matters because the compromise of a blueprint is not necessarily the compromise of just one identity. It may be a path to every child agent identity associated with that blueprint.  

This risk is not merely architectural. Recent security research into Entra Agent ID demonstrated how compromising a blueprint could allow an attacker to authenticate as identities associated with that blueprint, extending the impact across multiple identities, tenants, and permission contexts. 

The new BloodHound OpenGraph extension for Entra Agent ID connects the dots between those identities to existing Entra ID service principal nodes, allowing the discovery of attack paths beyond the agent boundary. The hybrid attack path continues into the Azure environment, where the attack graph can reveal which identities, roles, and resources become reachable through those blueprints.

That is one of the most important aspects of extending the existing enterprise attack graph to cover Entra Agents rather than analyzing them in isolation. The real risk often exists downstream. 

Agents Do Not Operate in Isolation 

As mentioned earlier, the most important part of the Entra Agents model is, arguably, that it does not treat the agent as the end of the path. Agents connect to other systems. 

Copilot Studio agents can invoke Power Automate flows. Flows can invoke child flows. Those flows can use embedded connections with entirely different execution identities. Foundry and Copilot agents can connect to MCP servers. Agent identities can map directly to Entra service principals. Foundry projects can connect to Azure Key Vaults. 

These relationships turn agents into interchanges between security domains. 

Power Automate and Execution-context Loss 

A low-privileged user may invoke an agent that delegates execution to a Power Automate flow. That flow may then invoke a child flow, which executes using its own configured connections. 

The original user’s identity may be entirely excluded from the authorization decision. 

What the BloodHound Entra Agents Extension Models 

At a high level, the current extension adds validated Entra Agent ID, Copilot Studio, Power Automate, and selected Foundry control-plane relationships to the BloodHound Enterprise attack graph, showing how control propagates through Microsoft’s agent ecosystem. 

• Entra Agent ID. The extension models agent identity blueprints, tenant-local blueprint principals, agent identities, ownership and administrative control, blueprint-to-identity relationships, and the mapping of agent identities to existing Entra service principals. 
• Copilot Studio. The extension models Copilot agents, owners, invocation access, maker-credential identity transitions, and the connections and Power Automate flows used by agents. 
• Power Platform and Power Automate. The extension models flows, flow-to-flow delegation, and the connections used by those flows.  
• Azure AI Foundry. Current validated coverage includes Foundry projects and account-scope role assignments. Foundry agents, project-contained connections, project-scope roles, agent identities, and A2A relationships remain under development. 
• Cross-graph relationships. Perhaps most importantly, agent identities are connected to their corresponding Entra service principals, allowing attack paths to continue into the existing Entra and Azure graph. 

Combined, these relationships allow BloodHound Enterprise to represent agents not as isolated AI applications but as active participants in the environment’s identity and authorization fabric. 

A Complete Attack Path Through an Entra Agent 

Let’s review a simplified example. 

A low-privileged employee has permission to invoke a Copilot Studio agent. The agent uses maker-provided credentials for its outbound actions. The maker has access to sensitive Azure resources. 

Individually, each configuration may appear reasonable: 

• The employee is allowed to use the agent. 
• The maker intentionally configured the connection. 
• The maker legitimately requires access to the Azure resource. 

But the attack graph reveals the effective path: 

The employee’s own Azure permissions are irrelevant. The agent became the bridge. 

This is why agent security cannot be reduced to asking who owns the agent, whether authentication is enabled, or which connections are configured. The important question is how all of those relationships compose. 

The attacker does not experience the environment one configuration page at a time, and neither should the defender. 

Modeling Effective Control Conservatively 

One of the challenges in modeling agent platforms is that not every relevant security property is exposed through a clean enumeration API.  

The extension distinguishes between relationships that can currently be enumerated with defensible semantics and relationships that remain under development. For example, AZAgent_ActsAs is created only when a non-OBO credential mode is confirmed. Other relationships, including connection sharing, connection-to-identity access, run-only flow access, and several Foundry data-plane relationships, are not currently created. Rather than infer those relationships, the extension omits them until they can be collected and validated reliably. 

This is important. 

An attack graph is useful only when its edges have defensible semantics. The goal is not to create the largest possible graph. It is to represent viable relationships that accurately depict how control can propagate. 

Why Attack Path Management Matters for AI Agents 

Agent security is often approached as an inventory or governance problem. 

• How many agents exist? 
• Who created them? 
• Which models do they use? 
• Which connectors are configured? 

Those are useful questions, but they do not tell us what an attacker can reach. 

Attack path management asks a different set of questions: 

• Who can invoke an agent that acts with someone else’s identity? 
• Which public agents bridge anonymous callers to authenticated resources? 
• Who can invoke an agent that uses maker-provided credentials?  
• Which publicly accessible agents create anonymous-to-authenticated bridges?  
• Which blueprints control agent identities that map to Entra service principals?  
• Which agents delegate execution to Power Automate flows?  
• Which flows and agents depend on particular Power Platform connections?  
• Which principals hold account-scope roles over Foundry resources? Can the compromise of one blueprint expose many agent identities? 
• And, most importantly, how do those relationships combine into a path to something the organization cares about? 

AI agents do not replace traditional identity systems. They sit on top of them, interact with them, assume their identities, invoke their APIs, and increasingly make decisions about when and how to use their privileges. 

That makes them part of the attack graph. 

Getting Started 

The Entra Agents extension brings Microsoft agent platforms into BloodHound Enterprise via OpenGraph, modeling Entra Agent ID, Copilot Studio, Power Automate, Azure AI Foundry, and the relationships connecting agent identities to existing Entra/Azure graph.

The collector is designed to use read-only Microsoft Graph and Azure permissions and does not read credential material or Key Vault secrets from the data plane. 

The result is not simply an inventory of agents. It is a graph of who can reach them, who can control them, which identities they act as, where they delegate execution, which credentials and connections they depend on, and what those relationships ultimately make reachable. 

As agents become more autonomous and more deeply connected to enterprise systems, understanding those paths will become increasingly important. The question is no longer just what an agent can do. It is who can make it do it, under whose identity, and where that path leads. 

With Attack Path Management for Entra agents, BloodHound Enterprise extends Identity Attack Path Management to the next generation of enterprise identities, helping organizations continuously understand how AI agents change effective access across hybrid environments. By connecting agent identities to the existing enterprise attack graph, defenders can prioritize the attack paths that matter most, eliminate the underlying conditions attackers exploit, and reduce risk before those paths are abused.