Expanding attack path management to the AI frontier 

Attackers don’t move through isolated systems. They move through the relationships between those systems and identities, chaining privileges to move laterally across the attack surface until they reach critical assets.  Hybrid, decentralized environments and the rapid growth of AI agents and other non-human identities (NHIs) have dramatically expanded the trust relationships defenders must secure. 

Go back just 10 years and, for most enterprises and government agencies, identity lived in Active Directory. That is no longer true. Today, identity is spread across diverse systems, including Okta, GitHub, Jamf-managed Mac environments, and AWS, with different rules governing access, privileges, and the classification of critical assets. At the same time, the number of identities in the enterprise has exploded as AI agents and non-human identities (NHIs) outnumber human identities by orders of magnitude. 

An attacker does not experience your environment as a set of platforms or products. They experience it as a connected system of opportunities. Defenders need the same connected view. 

The attack graph has become vastly more complex and distributed, and far more specific to each organization. This is a challenge for the defenders who must protect these sprawling environments. For attackers, however, the techniques remain the same. 

Today we’re announcing new features to support defenders navigating this increasingly complex landscape. Extensions for Amazon Web Services and Entra Agent ID in the new BloodHound Enterprise deliver AI and AWS attack path management across hybrid enterprise environments and agentic identity platforms. 

To help support organizations in their AI-driven workflows, we’re also announcing BloodHound Hunter, which connects approved AI agents knowledge sources to BloodHound findings through a purpose-built interface. 

Request access to the beta for BloodHound Hunter, AWS, and Entra Agent ID 

AWS attack path management: why now 

AWS is one of the world’s dominant cloud platforms and hosts business-critical production workloads, data, and a rapidly growing population of workload identities. That makes AWS attack path management more than a cloud-configuration problem. It is an identity and attack-path problem. 

The scale of identity inside those environments is the real problem. Inside an AWS organization, are hundreds, sometimes thousands, of accounts, each with its own IAM boundary of users, roles, and policies.  A compromised role in one account can sometimes create a path to broader control across the organization. At scale, the authorization surface is impossible to reason through policy documents alone. Identity policies, resource policies, service control policies, permission boundaries, and trust policies all intertwine, with expressive conditions layered on top, until intent and reality drift apart. 

Most AWS security tooling asks a configuration question. Is this policy overly permissive? Is this bucket public? Those are good questions, but they’re incomplete. An attacker doesn’t care whether a policy is “overly permissive.” They care whether the identity they just compromised through an exposed EC2 instance or a CI/CD pipeline can reach the role with the administrator policy, or the Lambda function holding production credentials. They care about the chain, not the control. 

Native AWS controls and cloud-security tools answer important questions about configuration, exposure, and individual access relationships. Is this policy overly permissive? Is this bucket public? Attack path management asks a complementary question: how do those conditions compose a path from an initial foothold to a consequential outcome? An attacker cares whether an identity compromised through an exposed EC2 instance or a CI/CD pipeline can reach an administrator role or a Lambda function with access to production credentials. Attackers care about the chain, not individual control. 

That’s the question AWS attack path management in BloodHound Enterprise now answers. BloodHound Enterprise evaluates supported AWS policies, trust relationships, organization controls, and service permissions together, then renders their effective relationships as traversable attack paths. At launch our AWS collector models the services where we see privilege escalation and lateral movement most often on our own engagements: IAM, AWS Organizations, STS, S3, KMS, Lambda, EC2, CloudFormation, EKS, and SSM. That’s more than 20 AWS resource types and over 150 distinct relationships, from IAM privilege escalation to PassRole abuse to cross-account trust. 

Read the technical deep dive on the BloodHound AWS extension 

Consider a representative scenario: a CI/CD identity in a development account cannot administer production directly, but it can modify a Lambda function that runs under a more privileged role. That role can assume a deployment role in another account, which can ultimately reach production. No individual policy says that development has production access; the architecture grants it one relationship at a time. 

BloodHound composes those relationships, shows the complete path, and helps defenders identify the choke point that breaks it. 

Here’s what that lets you finally ask and answer: 

• Who can actually assume a privileged role, including principals in trusted accounts, external vendor identities, and identities whose effective access is created through delegated permissions rather than named directly in the trust policy 

• Who can escalate to an administrator, whether it takes one hop or ten, with the exact permission and policy that enabled it 

• Who can reach your keys, secrets, and data, through any combination of role chaining and privilege abuse 

• What an outsider can do across your AWS organization, tracing the real blast radius of a compromised vendor or development account from a child account up to the management account 

The outcome is not another inventory of identities or another queue of isolated alerts. It is a focused set of relationships defenders can remove or constrain to eliminate many attack paths at once. 

Extending attack path management across agentic identity 

Agents are themselves a fast-growing class of identity, and they rarely act as the user who invoked them. A low-privileged employee can invoke a Copilot Studio agent that reaches sensitive Azure resources using its maker’s credentials. A public agent can become an anonymous-to-authenticated bridge. Compromise a single Entra agent identity blueprint and you may inherit every child identity beneath it. 

None of these scenarios results from a single bad setting. Each emerges from several valid configurations, often owned by different teams, that collectively create an attack path. Our new BloodHound Enterprise extension for Microsoft Entra Agent ID, currently in preview, maps agent identities, Copilot Studio, and Power Automate relationships into the same attack graph, built on SpecterOps research into abusable Copilot configurations.  

Read the technical deep dive on the BloodHound Entra Agent ID extension 

BloodHound Hunter: attack path intelligence in your agentic workflows 

If AWS and Entra Agent ID is where attack paths form, BloodHound Hunter is about enabling agentic workflows for SOCs, helping reduce the investigation and remediation time for Enterprise security teams. . BloodHound Hunter is an MCP interface built into BloodHound Enterprise. It lets approved AI clients access BloodHound’s analytics and graph context, which they can combine with the organization’s own knowledge, controls, and priorities. 

Read the technical deep dive on BloodHound Hunter 

In practice, that means your analysts can: 

• Prioritize remediation based on your specific environment, cutting through noise to the paths that actually matter to you 

• Translate a technical attack path into language an executive or identity team can act on 

• Automatically pinpoint critical assets and enclaves and isolate from attack paths with custom Privilege Zones 

We spent a lot of time on why wrapping an API is the wrong abstraction for an AI agent. If you’re building your own MCP tooling, the design deep dive on BloodHound Hunter is worth your time.  

One graph, from the cloud to the agents 

With Entra Agent ID and AWS attack path management joining Active Directory, Entra ID, Okta, GitHub, and Jamf, BloodHound Enterprise now resolves dangerous trust and identity relationships across cloud, SaaS, code, AI, and on-premises systems in a single attack graph.  Where connecting relationships are present and modeled, defenders can analyze paths that cross traditional platform boundaries, from a foothold in one platform toward a critical asset in another, and sever them at the most effective choke point. 

Cloud and agent identities are where enterprise privileges are multiplying. We expanded BloodHound to cover them because identity and trust relationships increasingly determine the blast radius of modern incidents. Detection alone cannot carry the load; defenders must also identify and remove the paths attackers rely on. 

Join us at the SpecterOps Kennel Club in Black Hat’s Cyber District for live workshops, demos, and talks featuring OpenAI and the UK AI Security Institute.