Cirro shows why Azure attack paths are a graph problem

At a glance

What this is: Cirro is a graph-based way to model Azure attack paths by linking identities, permissions, resources, and data-plane context.

Why it matters: It matters because IAM and cloud security teams need to see how apparently safe entitlements combine into reachable abuse paths across management and data planes.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Bishop Fox's analysis of Cirro and Azure attack-path modelling

Context

Azure attack paths are not defined by a single risky permission. They emerge when identity, role assignment, scope, resource configuration, and downstream secrets are connected into one reachable route. That is the core IAM problem this article addresses: the control surface is relational, not atomic.

Cirro is presented as a graph model for cloud attack paths, with enough management-plane and data-plane context to show how access can move from a user or managed identity to a Key Vault, secret, or application permission. For identity teams, the useful question is not who has a role, but what that role can unlock next.

This is a typical cloud governance problem, not an edge case. In environments where Azure RBAC, managed identities, and secrets all intersect, the visible permissions often look compliant until they are joined together and traced end to end.

Key questions

Q: How should security teams map Azure attack paths across identity and RBAC relationships?

A: Start with the full chain, not the permission list. Trace how group membership, role assignment, resource scope, managed identity, and downstream service permissions connect to the final target. The goal is to identify reachable abuse paths, especially where several low-risk assignments combine into one high-risk route.

Q: Why do managed identities and secrets complicate cloud access reviews?

A: Because the review boundary is usually too narrow. A managed identity can be harmless on paper but dangerous once it is linked to a secret, certificate, or downstream API permission. Cloud access reviews need to account for where those credentials can travel after initial authorization, not just where they were granted.

Q: What breaks when cloud traffic lacks context?

A: When cloud traffic lacks context, teams lose the ability to distinguish normal behaviour from malicious movement. Detection becomes noisy, prioritisation becomes inconsistent, and response decisions rely on guesswork instead of evidence. The practical failure is not just missed alerts, but the inability to connect access, communication, and impact in time.

Q: How should teams govern environment identities across dev, QA, staging, and prod?

A: Treat shared identities across environments as a blast-radius problem. If one secret or token works across multiple stages, a compromise in the weakest environment can reach the strongest one. Separate identities by environment and review any bridge that allows the same credential to authenticate everywhere.

Technical breakdown

How attack paths emerge across Azure identity and scope

Azure attack paths form when individually reasonable entitlements are chained across identity, group membership, RBAC scope, and resource relationships. A user may only have one role, a managed identity may only access one vault, and a VM may appear isolated, yet the combined route can still lead from directory access to data-plane exposure. Graph modelling matters because it preserves the hop-by-hop relationship that flat inventories hide. In practice, the security question becomes reachability, not just assignment.

Practical implication: Model the full route from identity to resource to downstream secret so you can spot chained access that single-object reviews miss.

Why the data plane changes the attack graph

Management-plane data shows who can administer resources, but data-plane context shows what those resources can reveal or indirectly expose. In Azure, that includes Key Vault secrets, certificates, and the identities tied to them. Once those objects are part of the graph, the analysis can identify situations where a configuration, a secret, or an application token becomes the real path to compromise. This is why data-plane coverage changes attack-path analysis from governance theory into abuse-path detection.

Practical implication: Extend graph collection beyond administration rights so secret and certificate relationships can be analysed alongside RBAC and scope.

How templated schema engines keep cloud graphs extensible

Cirro avoids hardcoding every Azure resource into the binary by separating shared constants, Tera-rendered YAML schemas, and a generic loader. That pattern lets new resource types be added without rewriting the ingestion engine, while conditional logic handles inconsistent API responses and legacy fields such as access policies. The design goal is scale without one-off code paths, which is important because cloud attack graphs degrade quickly when each new service requires bespoke logic.

Practical implication: Use declarative schemas and shared graph vocabulary so new resource types can be onboarded without fragmenting the ingestion model.

Threat narrative

Attacker objective: The attacker wants to convert legitimate-looking Azure relationships into a practical route to Key Vault access, secret exposure, or broader resource control.

1. entry: A user, group membership, or managed identity becomes the starting point for a reachable Azure path when permissions and scope are joined together.
2. credential_harvested: A Key Vault secret or application credential becomes available through the chain, allowing the attacker to obtain a token or privileged access path.
3. escalation: The attacker uses the linked resource scope, RBAC inheritance, and managed identity relationships to move from one controllable object to the next.
4. impact: The final route exposes administrative control or sensitive secrets that were not obvious when each object was reviewed in isolation.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation — Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cloud attack-path governance fails when teams review entitlements as objects instead of relationships. The article is right to treat identity, scope, resource, and secret as a single graph because abuse rarely begins with one dramatic permission. It begins when individually acceptable assignments compose into a reachable path. For IAM and cloud security teams, the operational unit of control is the chain, not the record.

Data-plane visibility is the difference between access governance and exposure governance. Management-plane analysis can tell you who can administer a resource, but it cannot fully show what that resource can leak, unlock, or authenticate to downstream. Once secrets, certificates, and application credentials are included, the attack graph becomes materially more accurate. Practitioners should treat data-plane relationships as first-class identity signals.

Template-driven schema design is the only scalable way to keep pace with cloud resource sprawl. The article’s Tera and YAML approach matters because attack-path tooling breaks when every service family needs bespoke code. Declarative schemas let teams extend coverage while preserving a consistent graph vocabulary. The practical conclusion is that attack-path coverage must scale as infrastructure changes, not after it changes.

Identity blast radius is the right mental model for Azure path analysis. A role, a managed identity, and a secret may each appear low risk, but their combined reach defines the blast radius. That is especially relevant where dev, QA, staging, and production identities overlap. Security teams need to evaluate how far a credential can travel, not just whether the credential itself is valid.

Legacy access-policy thinking is already a governance liability in environments moving to Azure RBAC. Conditional handling for deprecated access policies shows that schema logic must tolerate transition states, but governance logic should not assume those states are benign. When an entitlement model shifts, the old and new pathways coexist long enough to create confusion in review and detection. The implication is that lifecycle governance must track the transition, not just the target state.

From our research:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• Attack-path analysis pairs well with 52 NHI Breaches Analysis, which shows how chained access and stale credentials become breach enablers in practice.

What this signals

Identity blast radius is the more useful operating concept for Azure than isolated privilege review. Teams that continue to certify roles without tracing downstream secret exposure will keep missing the path that turns a valid entitlement into an abuse route.

The governance programme should shift from asset-by-asset review to relationship-based review, with special attention to managed identities, Key Vault objects, and environment-to-environment credential reuse. That is where the practical risk accumulates, especially in fast-moving cloud estates.

With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, attack-path graphs become a prioritisation tool rather than a nice-to-have visualization. They tell teams where excess reach is actually exploitable.

For practitioners

• Map attack paths as chains, not assets Build review workflows that trace from user or managed identity to group membership, RBAC scope, resource, secret, and downstream application permission in one query. Use the resulting path map to prioritise remediation where multiple low-risk hops combine into a high-risk route.
• Bring data-plane objects into identity review Include Key Vault secrets, certificates, and application credentials in the same analysis model as management-plane permissions. If the graph cannot show what a resource can disclose or authenticate to next, the review is incomplete.
• Standardise declarative resource schemas Use a shared constants layer and declarative templates for new cloud resource types so expansion does not create one-off parsing logic. That keeps attack-path collection consistent as Azure services, subscriptions, and environments grow.
• Separate environment identities by design Treat shared development, QA, staging, and production identities as a path-amplification issue, not just an architecture smell. Enforce different identities for different environments wherever a secret or token can bridge them.
• Review deprecated access-policy dependencies Track resources that still depend on legacy accessPolicies handling and verify how those paths resolve under Azure RBAC. Mixed entitlement models can hide duplicate routes to the same vault or resource.

Key takeaways

• Azure risk emerges from connected identity relationships, not from individual permissions viewed alone.
• Data-plane visibility changes attack-path analysis because secrets and certificates often reveal the real route to compromise.
• Teams should govern identity blast radius by tracing end-to-end reach across environments, scopes, and downstream credentials.

Key terms

• Attack path: A sequence of identities, permissions, systems, and data stores that an attacker can traverse after obtaining trusted access. In practice, attack paths matter more than single accounts because they show how a low-risk identity can become a route to high-value exposure.
• Data Plane: The data plane is where operational access to content occurs, including prompts, outputs, logs, training data, and secrets. In AI governance, this is the layer where over-privileged identities often expose sensitive information even when the control plane appears tightly managed.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Declarative Schema Engine: A declarative schema engine describes how source data should be transformed into graph entities and relationships without hardcoding every resource type into application logic. In cloud security tooling, this makes ingestion extensible and keeps new services from becoming one-off engineering projects.

What's in the full article

Bishop Fox's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step Cirro ingestion and schema extension workflow for additional Azure resource families
• Examples of the templated YAML and Tera structure used to render graph relationships
• Practical use of the CirroDash layer for exploring Neo4j attack-path data
• Details of the cirro-azcli-ext extension for passive API capture during Azure CLI use

👉 The full Bishop Fox post shows the schema engine, graph examples, and extension model in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.