Auditing Application Permissions in Microsoft Entra ID: Hidden Risks, Pitfalls, and Quarkslab's QAZPT Tool

2026-04-30T00:00:00+02:00

Introduction

If you work in security, development, or cloud architecture, and your organization uses Microsoft Azure or Microsoft 365, there is a high chance you have already come across Azure applications, whether intentionally or not. You may have even read the Wiz blog post detailing how they were able to modify Bing search results because of Microsoft's own applications misconfigurations. However, as common as they are, Azure applications can be hard to fully understand, and they can hide, through their own complexity and the Microsoft permission model, more serious security risks than most other Microsoft Entra ID entities, if not properly managed.

Beyond applications themselves, understanding how permissions actually propagate across an Entra ID tenant is surprisingly difficult in practice. Permissions inherit through ownership, federated identity, group membership, and several less obvious paths; the data needed to map all of this is scattered across multiple APIs and portal sections. The gap between what is configured and what is effectively reachable through inheritance is where most of the practical risk lives, and it is also where existing tooling tends to stop short.

This post is structured in three parts:

Azure Applications: Definition, permissions, and hidden complexities is a deep dive into how AppRegistrations and Service Principals work, the permission types they expose or require, and the credential behaviors that are not always visible from the Azure Portal.
Auditing permissions in Entra ID: a real challenge explains why auditing permissions in a real tenant is hard in practice, walks through the transitive inheritance paths that make manual analysis impractical at scale, and reviews the existing tooling landscape.
Quarkslab Azure Permission Tracker (QAZPT): Mapping the full picture introduces QAZPT, an open-source tool we built to compute and visualize effective permissions in an Entra ID tenant, with examples of its outputs and use cases.

Azure Applications: Definition, permissions, and hidden complexities

Applications within Microsoft Entra ID (formerly Azure Active Directory) actually refer to Application Registrations, shortened to AppRegistration, and Enterprise Applications, also known as Application Service Principals. Applications are entities that represent a software program or a service that can interact with Microsoft Entra ID and other Microsoft services, such as Azure Resource Manager (ARM). In simpler terms, they act as a layer between your software and Microsoft cloud services.

Their use cases are various, from enabling single sign-on (SSO) for users on a custom application or a third-party service, to allowing applications to access APIs or resources on behalf of a user, or independently, without user interaction.

If you are using a calendar application, an email client, or any other software that integrates with Microsoft 365 services (did you have to create an account, or to agree to share some data from your Office 365 account with that HR platform your company is using?), chances are high that you are interacting with an external application. The web application you visit to read your mails (https://outlook.office.com) is itself an application registered in Microsoft Entra ID (Outlook Web App), which you cannot see because it is a built-in, core, and non-configurable application.

One of the most popular applications, for developers and power users, is probably Microsoft Graph. It is a RESTful web API that allows access to Microsoft 365 services data, such as users, groups, applications, mails, etc.

By default, any member user in an Entra ID tenant can register applications, unless this ability has been restricted (as it should be). To do that, one can use the Azure Portal, the Entra ID admin center, or the Microsoft Graph API.

Definition

Applications in Entra ID are represented by two main objects: the Application Registration (AppRegistration) and the Service Principal (ServicePrincipal). While they are closely related, they serve different purposes which are important to understand and not very intuitive nor well explained in Microsoft documentation.

An Application Registration (AppRegistration) is a global template or blueprint for an application within an Entra ID tenant. It defines the application's identity, configuration, redirection URI, and settings. It also includes the permissions the application will expose or require. As this part is of course a bit more complicated than that, we will detail it in the next section. Even though the AppRegistration is a template object, credentials for authentication (client secrets, certificates) are created and stored on it. They can be viewed and managed from the Web Portal, in the Entra ID section, under "App registrations", or through the Microsoft Graph API:

$ curl https://graph.microsoft.com/v1.0/applications -H "Authorization: Bearer {token}"

An Application Service Principal (shortened to ServicePrincipal) is the actual instance of the application within a specific Entra ID tenant. It represents the application's identity and permissions in that tenant. When an application is registered through the web portal, a corresponding Service Principal is automatically created in the same tenant. The Service Principal is what is used during authentication and authorization processes when the application interacts with resources or APIs. They can be viewed and managed from the Web Portal, in the Entra ID section, under "Enterprise applications", or through the Microsoft Graph API:

$ curl https://graph.microsoft.com/v1.0/servicePrincipals -H "Authorization: Bearer {token}"

Note: Managed Identities are also referenced as Service Principals in Entra ID. They are a special type of Service Principal, primarily used by Azure resources to access other Azure or Entra ID services without needing to manage credentials. They are created and managed by Azure itself (systemAssigned) when you enable Managed Identity on an Azure resource, or you can create them manually (userAssigned) and assign them to one or several resources. It's like a simplified, auto-piloted Service Principal for Azure resources.

While only one AppRegistration can exist for an application in its home tenant, multiple Service Principals can be created in different tenants if the application is used across multiple organizations. When, for example, a user consents (delegate permission) to an application, a Service Principal is created in their tenant based on the AppRegistration.

Permissions

One of the biggest challenges when dealing with Azure applications is understanding their permissions model, which not many people actually know about, or that some think they know about but do not really understand. This confusion primarily stems from the lack of clear documentation from Microsoft, the complexity of the model itself, and the AppRegistration/ServicePrincipal duality.

There are, of course, the Entra ID roles (Global Administrator, Application Administrator, Directory Reader, etc.) that can be assigned to them (the Service Principal, if you remember the previous section), even if it is not a common practice and is highly not recommended.

However, the main way to grant access to resources for applications is through application permissions (also known as App roles), or delegated permissions (also known as OAuth2 permissions or scopes).

Types of permissions and their specificities

Applications can expose, or require, two types of permissions.

Application permissions / roles

These are permissions that can be granted to applications, users, groups, or some combination of those. When granted to an application, they allow it to perform actions in another application without any user interaction. When granted to a user or a group, they appear as claims in the issued token and act as application-level roles for that user. In short, an app role is a way for an application to define capabilities and to assign other applications, users, or groups to them so they can accomplish specific tasks.

Below is a screenshot of an AppRegistration configured to require the application permission User.Read.All from the application Microsoft Graph:

As the administrator consent has not been granted, the associated Service Principal does not have this permission yet.

For an application to create its own application role permissions, it must define them in the App roles section. Below is the app role MyCustomScopeRole.Read.All defined, so that another application or a user/group can be assigned to it:

Application roles can be assigned either through the AppRegistration API permissions section for applications (as shown above), or through the Service Principal for both applications and users/groups. Below is the assignment of the MyCustomScopeRole.Read.All app role to a user from the Service Principal:

Delegated / OAuth2 scope permissions

These are permissions that applications can be granted on behalf of a user. Once the user has authenticated and consented to the permissions, the application can perform actions as the user, within the scope of the granted permissions. This is commonly used for applications that need to access user data or perform actions on behalf of a user.

What is sometimes unclear is that users can delegate any permission to an application without any error, but the application will only be able to perform actions that the user is actually allowed to perform.

Delegated permissions can sometimes require admin consent, depending on the sensitivity of the permissions being requested, before the application is allowed to request them. Additionally, administrators can pre-consent to delegated permissions for applications, so that users do not have to individually consent to them and will not be prompted when using the application.

Below is a screenshot of an AppRegistration configured and allowed to request the delegated permission email from the application Microsoft Graph for users that will use it:

Unlike application permissions, which are granted to the Service Principal once admin consent is given, delegated permissions are granted on a per-user basis and only take effect once a user has authenticated and consented through the application (or once an administrator has pre-consented on their behalf).

In order for an application to define its own permissions to be used by other applications, it must declare them in the Expose an API section. Below is the scope MyCustomScope.Read defined, so that another AppRegistration can request it from users to delegate it:

You probably have already heard about consent phishing attacks, where an attacker tricks a user into consenting to an application that requests excessive permissions, allowing the attacker to gain access to sensitive data or perform actions on behalf of the user. If you have not, you can read more about it in the Microsoft documentation.

While this type of attack is still current and relevant, something that most people do not know is that the consent prompt does not always concern delegated permissions only. Application permissions can also be targeted in this way.

If we take our earlier example of the AppRegistration with the User.Read.All application permission from Microsoft Graph, an attacker with sufficient privileges to create or manage an AppRegistration who successfully tricks an administrator into consenting to that application will see the associated Service Principal immediately granted that permission, in addition to an administrator consent for the delegated permission email, meaning regular users will not be prompted for permission delegation at all.

Below is the consent prompt that would be displayed to an administrator in this case:

Immediately after consenting, the Service Principal has the application permission granted:

This is another good reason to pay attention to prompts and consent requests, even when the application is registered in your own tenant, and to never use an administrator account for regular activities.

Credentials

Depending on the use case of the application and the authentication flow wanted, applications may need to authenticate themselves to Microsoft Entra ID to obtain access tokens for accessing resources or APIs. For this, credentials can be registered to the AppRegistration, either through the Web Portal or the Microsoft Graph API. Credentials can be client secrets (basically passwords), certificates, or federated identities. However, we are talking about Microsoft here, so this cannot be that simple.

Service Principal credentials creation: it's not a bug, it's a feature

As mentioned earlier, credentials are created and managed from the AppRegistration object, either through the Web Portal or the Microsoft Graph API. However, what is not very new nor well known (but should be) is that credentials can also be created for the Service Principal object itself, but only via the Graph API.

As these credentials can only be created from the Graph API, they are therefore not visible from the Web Portal, and can go unnoticed during permission reviews.

For example, let's create a new client secret for a Service Principal using the Graph API:

$ curl -X POST "https://graph.microsoft.com/v1.0/serviceprincipals(appId='00000000-0000-0000-0000-000000000001')/addPassword" -H "Content-Type: application/json" -H "Authorization: Bearer $bearer" -d '{"displayName":"test"}'
{
  "@odata.context":"https://graph.microsoft.com/v1.0/$metadata#microsoft.graph.passwordCredential",
  "customKeyIdentifier":null,
  "displayName":null,
  "hint":"m_q",
  "keyId":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "secretText":"[REDACTED]"}

The newly created client secret is not visible from the AppRegistration object, either from the Web Portal or the Graph API:

$ curl "https://graph.microsoft.com/v1.0/applications(appId='00000000-0000-0000-0000-000000000001')" -H "Content-Type: application/json" -H "Authorization: Bearer $bearer" | jq '.passwordCredentials'
[]

Note that this is currently not true for federated identity credentials, which for now can only be created for the AppRegistration object, or managed identities.

Federated identities: a nice privilege escalation feature

Federated identities allow other identities to impersonate the application without needing to manage credentials directly. This can be used to enable scenarios where an external identity provider authenticates on behalf of the application, Kubernetes Service Accounts access resources, or for other cross-identity scenarios.

While this is a good feature for avoiding the management of secrets, it can also pose security risks, and be easily forgotten about or not properly monitored. An attacker could leverage a compromised identity to impersonate the application, or, in a post-exploitation scenario, configure this feature to maintain persistence.

The PoC is in production

Even though it is currently not documented, the Graph API endpoint /servicePrincipals/{id}/federatedIdentityCredentials exists and allows listing the federated identities of a Service Principal, but returns an error when trying to create one:

$ curl -X POST "https://graph.microsoft.com/v1.0/servicePrincipals(appId='00000000-0000-0000-0000-000000000001')/federatedIdentityCredentials" -H "Content-Type: application/json" -H "Authorization: Bearer $bearer" --data '    {
      "name": "f",
      "issuer": "https://login.microsoftonline.com/{tenant_id}/v2.0",
      "subject": "{id_of_managed_identity}",
      "audiences": [
        "api://AzureADTokenExchange"
      ]
    }'
{"error":{"code":"Request_BadRequest","message":"Property  is not currently supported.",...}}}

If this behavior becomes supported in the future, it could lead to even more unnoticed credentials for applications: federated identity credentials are not included in the returned JSON object when querying the AppRegistration or Service Principal through the Graph API. They can only be viewed through the Azure Portal, or by requesting the dedicated /federatedIdentityCredentials endpoint, which is not very intuitive and can be easily missed during permission reviews.

A new federated identity credential for an AppRegistration can be created either from the Web Portal or the Graph API, using the dedicated endpoint mentioned above. For example, let's authorize a managed identity to impersonate an application by creating a new federated identity credential for the associated AppRegistration:

$ curl -X POST "https://graph.microsoft.com/v1.0/applications/<application_id>/federatedIdentityCredentials" -H "Authorization: Bearer $bearer" -H "Content-Type: application/json"  --data \
'{
    "name": "myFederatedIdentityCredential",
    "issuer": "https://login.microsoftonline.com/<tenant_id>/v2.0",
    "subject": "<id_of_managed_identity>",
    "audiences": [
      "api://AzureADTokenExchange"
    ]
}'

Managed Identities and federated identities: the rules change during the game

Recall that a Federated Identity Credential cannot be created for Service Principals, but only for AppRegistrations: the feature is "not currently supported". Recall also that Managed Identities are represented as Service Principals. So, does that mean that we cannot create federated identities for them? The rules are not the same for everyone.

Federated identities can in fact be created for User-Assigned Managed Identities, but not through the Graph API (which only allows reading them). Even though Managed Identities are represented as Service Principals, they are actually managed by Azure Resource Manager (ARM); the only way to create federated identities for them is therefore through the ARM API or the Azure Portal.

For example, let's create a new federated identity credential for a User-Assigned Managed Identity using the ARM API's dedicated endpoint:

$ curl -X PUT "https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<rg_name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<managed_identity_name>/federatedIdentityCredentials/<federated_identity_credential_name>?api-version=2024-11-30" -H "Authorization: Bearer $bearer" --data \
'{
  "properties": {
    "audiences": [
      "api://AzureADTokenExchange"
    ],
    "issuer": "https://login.microsoftonline.com/<tenant_id>/v2.0",
    "subject": "<id_of_managed_identity>"
  }
}'

The credentials matrix as a summary

In order to summarize the different types of credentials, their creation methods, and their visibility, here is a matrix that can be used as a quick reference. Note that this is true at the time of writing, but Microsoft can change the rules whenever they want, so it is important to always check the latest documentation and test the actual behavior when reviewing permissions and credentials for applications.

Entity Type	Secret	Certificate	Federated Identity	API	Web Portal
AppRegistration	✅	✅	✅	✅ - Graph	✅
ServicePrincipal (regular)	✅	✅	❌	✅ - Graph	❌
ServicePrincipal (Managed Identity, User Assigned)	❌	❌	✅	✅ - ARM - Graph: Read-Only	✅
ServicePrincipal (Managed Identity, System Assigned)	❌	❌	❌	❌	❌

The concrete differences between AppRegistration and ServicePrincipal

AppRegistration and Service Principal are two different objects, closely related and often confused, mainly because they share too many properties and settings, where they should not. They have different purposes, and owning one or the other does not mean having the same control or capabilities. This is why security auditors need to pay attention to both objects when reviewing application permissions and transitiveness.

Below is a screenshot summarizing the main differences and similarities between the two objects:

Owning an AppRegistration gives you the ability to manage it, and its associated Service Principals as well; the reverse is not true.
Both AppRegistration and Service Principal can have their own credentials. However, AppRegistration credentials allow authenticating as the application in any tenant where a Service Principal exists, while Service Principal credentials can only be used for that Service Principal itself. This is why you must not give application permissions or Entra ID roles to Service Principals for which you do not own the AppRegistration.
Defined application roles and exposed API scopes can be found on both objects. This can be confusing in the case of the Service Principal, as it may lead to thinking they are permissions actually granted to it, while they are only definitions inherited from the AppRegistration.
AppRegistration exposes the required application roles and delegated permissions under the same section requiredResourceAccess, differentiating them only by the type property (Scope for delegated permissions, Role for application roles). The Service Principal, in contrast, shows actual permissions granted to it, and separates them into two sections: appRoleAssignments for application permissions, and oauth2PermissionGrants for delegated permissions. This is important to understand when reviewing permissions through the Graph API.

All of these differences and hidden behaviors make application permissions notoriously difficult to audit in practice. In a real tenant with hundreds or thousands of applications, understanding who actually has access to what, and through which chain, is far from straightforward.

Auditing permissions in Entra ID: a real challenge

Entra ID roles: technically visible, practically painful

Checking which Entra ID roles are assigned to a given entity through the web portal is technically possible, but far from efficient. To check the roles of a single Service Principal, you need to navigate to the Entra ID admin center or the Entra ID section of the Azure portal, find the right entity, and click through several menus before reaching the role assignments. You can also list all the existing roles and click through each of them to see which entities are assigned to them.

There is no consolidated view showing all role assignments across all entities at once. For a tenant with dozens of Service Principals and users, doing this manually quickly becomes unrealistic.

Not to mention the fact that when using Microsoft Entra Privileged Identity Management (PIM) to manage privileged roles, the actual role assignments are not visible in the portal at all, as they are only granted on demand when users activate them. This is a good security practice, but it also means that auditing effective permissions requires either having access to PIM logs or asking users to activate their roles one by one during the review process, which is impractical.

On top of that, the portal does not show transitive role assignments. Roles that are effectively granted to an entity through group membership are not visible directly. An entity can inherit Global Administrator rights through a group it belongs to, and nothing unusual will appear when you look at that entity's role assignments directly.

Application permissions and delegated permissions: close to invisible

If Entra ID roles are already painful to audit, application roles and delegated permissions are close to invisible without dedicated tooling. There is no built-in consolidated view in the portal that shows which app roles have been granted to a given Service Principal, or which users have delegated which permissions to which applications. Fragments of this information are scattered across different pages (the Enterprise Applications section, individual API permissions pages), but assembling a complete picture requires navigating through multiple screens for each entity individually.

The deeper problem: permissions are transitive

Even if you could instantly see all direct permissions assigned to every entity, that would still only be half the picture. Permissions in Entra ID propagate transitively through relationships between entities, and the chains can be long, indirect, and non-obvious. Below are some examples of inheritance paths that make this hard to reason about.

- Direct ownership. The most intuitive one: an entity that owns another entity gains control over it. A user who owns an AppRegistration can manage it and its associated Service Principal, including rotating credentials and modifying permissions. Ownership is explicit and auditable in principle, but it tends to accumulate over time and rarely gets cleaned up.

- Group membership. Users, Service Principals, and other groups can be members of an Entra ID security group, and a group can itself hold Entra ID role assignments and application role assignments. Any member of such a group transitively inherits everything the group has been granted, and nested groups extend the chain further. Group membership often produces the longest and least-obvious privilege chains in real tenants: a user inherits a role granted to a group, which is itself nested in another group holding additional permissions, and so on. The portal, of course, does not surface these chains in a single view.

- ServicePrincipal of an AppRegistration. Whoever controls an AppRegistration, through ownership or by obtaining its credentials, effectively controls the corresponding Service Principal and all the permissions granted to it. Since AppRegistration credentials are valid across every tenant where the application is deployed, this relationship is particularly sensitive: gaining access to the AppRegistration is not just gaining access to one Service Principal, but potentially to many.

- Federated Identity Credentials. An application can be configured to trust an external identity via a Federated Identity Credential (FIC). When a Managed Identity is set as the FIC subject for an AppRegistration, that Managed Identity can request tokens for the application without any secret or certificate; the trust is configured at the application level, not through a stored credential.

Concretely: if Managed Identity A is the FIC subject of Application B, and Application B's Service Principal holds significant permissions, then anything that can obtain a token for Managed Identity A can impersonate the application and exercise those permissions. An Azure VM with a system-assigned Managed Identity is a common example. Compromising that VM is enough; no credential to extract, nothing to rotate. The same scenario can occurs with a Kubernetes Service Account, which can be configured as a FIC subject to allow a pod to impersonate an application. This is a common scenario in real tenants, and it is often overlooked during permission reviews.

- Entra ID roles. Privileged Entra ID roles such as Global Administrator, Application Administrator, or Cloud Application Administrator give their holder control over all entities within a defined scope: all applications and Service Principals, or all entities including users. Any entity that can reach a node holding one of these roles through an inheritance chain transitively inherits that scope.

Example: User A owns AppRegistration B, whose Service Principal C has been assigned Global Administrator. User A has no privileged role assigned to them directly, and a quick portal check on their account looks clean. But through the ownership chain, User A effectively controls everything a Global Administrator can control.

- Microsoft Graph application roles. Some Microsoft Graph application roles are as dangerous as, or more dangerous than, Entra ID administrative roles, and considerably easier to overlook. RoleManagement.ReadWrite.Directory allows its holder to assign any Entra ID role to any entity, including Global Administrator, which makes it a direct path to full tenant takeover. AppRoleAssignment.ReadWrite.All allows assigning any application role to any entity without administrator approval, which can be used to first assign RoleManagement.ReadWrite.Directory to a controlled entity and then escalate from there. Application.ReadWrite.All is similarly dangerous: it lets its holder add credentials (client secrets, certificates) to any application or Service Principal in the tenant, including ones already holding privileged roles, effectively turning it into an immediate impersonation primitive against any application of interest.

- Bonus example, Azure Resource Manager (ARM) roles. While ARM permissions are not technically part of Entra ID, an entity that has an ARM role allowing it to fully manage a resource with a Managed Identity attached (such as a Virtual Machine or an Azure Web App) can indirectly obtain an access token for that Managed Identity and impersonate it to access any resource or API the associated Service Principal has permissions for. This is a common scenario in real-world tenants.

And many more. The combinations and variations of relationships can create very long and unexpected inheritance chains. For example, an entity might have read permissions on a specific entry in an Azure Key Vault that contains secrets for an AppRegistration. However, this is probably where we draw the line of what can reasonably be audited using regular tools.

State of the art: commercial and open-source tools

Commercial tools exist to address part of this. Microsoft Defender for Cloud Apps, Grip Security, and PingCastle for Entra ID, for example, all provide more or less governance-oriented visibility into application permissions. However, these tools are mostly designed for compliance and governance teams: they help detect policy violations, enforce least-privilege policies, and generate non-technical audit reports for management. They are often not built for security auditors or red teamers who need to answer the question "if I compromise this entity, what can I do from there?". They do not trace permission chains the way an attacker would follow them, they do not model inheritance, and they generally require a commercial license that a pentester or a bug hunter will not have.

Open-source tools also exist, such as MSIdentityTools or the famous Get-AzureADPSPermissions.ps1 script, which is even referenced in the Microsoft documentation for investigating application consent grant attacks. It would also be unfair not to mention BloodHound and AzureHound from SpecterOps, which are the reference tools for attack path mapping in Active Directory and Entra ID environments. BloodHound excels at surfacing reachability paths across a broad set of relationships (ownership, group membership, role assignments) and visualizing them interactively. Its primary design goal is attack path discovery rather than effective permission aggregation per entity, and extracting specific permission-related findings generally requires writing Cypher queries, which can be a barrier for practitioners less familiar with graph databases.

Tracing these chains manually across a real tenant, mapping each entity's direct permissions, then following each ownership relationship, each FIC, and each privileged role assignment to see what they ultimately reach, is not a realistic operation at scale. The combinations grow quickly, the relevant data is split across multiple API endpoints and portal sections, and there is no unified view anywhere. No tool, commercial or open-source, gives you the exhaustive picture of permissions and an idea of the effective permissions of each entity through inheritance, in a way that is easy to read and actionable for security assessments.

This is the gap QAZPT was built to fill.

Quarkslab Azure Permission Tracker (QAZPT): Mapping the full picture

What is QAZPT?

QAZPT (Quarkslab Azure Permission Tracker) is an open-source CLI tool designed to analyze and visualize permission inheritance in Microsoft Entra ID environments. It aims to provide what other tools do not: effective permissions computation for each entity, and the most complete view possible of how permissions propagate through a tenant. It covers most of the inheritance paths described above (ownership, Service Principal of an AppRegistration, Federated Identity Credentials, privileged Entra ID roles, and privileged Microsoft Graph application roles), with partial support for group membership.

Beyond computing effective permissions through inheritance, QAZPT also exposes the direct permission state of each entity in its structured outputs: their own Entra ID role assignments, their own application role assignments, and the delegated permissions that have been granted to them. This gives practitioners a single, consolidated view of both "what this entity directly holds" and "what it can effectively reach through inheritance" in one pass.

Most importantly, as it is written in Python, QAZPT does not require PowerShell or Windows-dependent PowerShell modules.

How it works

QAZPT authenticates against the Microsoft Graph API using standard Azure credentials, supporting the full Azure identity chain (Azure CLI session, environment variables, or Managed Identity). From there, it proceeds in four main stages.

1. Data collection. A set of resource-specific brokers, one per entity type (users, applications, Service Principals, role definitions), pulls all relevant entities and their attributes from the Graph API. Responses are cached locally as JSON, so subsequent runs against the same tenant can skip the network calls and run offline. This makes iterative exploration and re-running queries cheap, even on large tenants, and limits the risk of triggering throttling or detection logic during an assessment.

2. Graph construction. Each entity is wrapped into a typed Node carrying its own direct permission set: Entra ID role assignments, application role assignments, and delegated permissions. Direct relationships (ownership links, AppRegistration to Service Principal pairing, federated identity subjects, role assignments) are then materialized as edges between these nodes, giving the inheritance computation a concrete starting point per entity.

3. Inheritance resolution. Five independent resolvers walk the graph and add inheritance edges, one per inheritance path described earlier in this post: direct ownership, Service Principal of an AppRegistration, federated identity credentials of an AppRegistration and Service Principal, privileged Entra ID roles, and privileged Microsoft Graph application roles. Resolvers are decoupled from each other, which means adding a new privilege escalation path to QAZPT only requires writing a new resolver and registering it; no other component needs to change.

4. Transitive computation. Once the inheritance graph is built, QAZPT computes effective permissions for every entity. Cycles, which are not unusual in real tenants (for example, two Service Principals that mutually own each other, which is, very unusual but a very simple example), are handled by collapsing strongly connected components into single super-nodes using Tarjan's algorithm. The resulting structure is a directed acyclic graph, on which permissions are aggregated bottom-up and then redistributed back to each individual node, with the original source of every inherited permission preserved so practitioners can trace where each permission ultimately came from.

The result is a fully resolved view of the tenant's effective permissions, ready to be exported in any of the supported output formats.

Key features

The key features of QAZPT include:

Analyzing and visualizing inheritance between Entra ID entities (Users, AppRegistrations, ServicePrincipals), uncovering complex relationships and potential permission escalation paths.
Identifying and visualizing gained permissions through inheritance, which helps detect over-privileged entities.
Exporting detailed reports in CSV and JSON formats for further analysis, containing entities with their own permissions and their inherited permissions.
Exporting the full graph to a Neo4j database for interactive exploration and advanced Cypher queries.

Use cases

QAZPT covers both sides of a security assessment.

On the offensive side, it helps quickly identify privilege escalation paths: which entities, if compromised, would give an attacker access to privileged roles or sensitive permissions, and through which chain. Finding that a VM's Managed Identity is one FIC away from a Global Administrator role is exactly the kind of finding that takes hours to trace manually and seconds to spot in a QAZPT output.

On the defensive side, it helps auditors verify that no entity has accumulated unintended permissions through indirect relationships, that ownership assignments are justified, and that no critical application permission has been silently granted somewhere deep in an inheritance chain.

Outputs

QAZPT produces three types of output across four formats.

Inheritance tree (console): an ASCII tree showing, for each entity, which entities it inherits permissions from, and through which relationship type. Useful for a quick read during an assessment.

$ uv run qazpt inheritance
### Users ###

test/test@contoso.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
     --[ownership]--> AppRegistration/general_admin_app/00000000-0000-0000-0000-000000000001
         --[sp_of_app]--> ServicePrincipal/general_admin_app/00000000-0000-0000-0000-000000000002 [HAS PRIVILEGED ROLE]
             --[Entraid_Role (Global Administrator)]--> All entities

### AppRegistration ###

AppRegistration/general_admin_app/00000000-0000-0000-0000-000000000001
     --[sp_of_app]--> ServicePrincipal/general_admin_app/19907881-667d-4959-b41d-18d85c71a844 [HAS PRIVILEGED ROLE]
         --[Entraid_Role (Global Administrator)]--> All entities

AppRegistration/graph_role_readwrite_app/00000000-0000-0000-0000-000000000003
     --[sp_of_app]--> ServicePrincipal/graph_role_readwrite_app/00000000-0000-0000-0000-000000000004
         --[Graph_App_Role (AppRoleAssignment.ReadWrite.All)]--> All entities

AppRegistration/test_cycle_app2/00000000-0000-0000-0000-000000000005
     --[sp_of_app]--> ServicePrincipal/test_cycle_app2/00000000-0000-0000-0000-000000000006
         --[ownership]--> ServicePrincipal/test_cycle_app1/00000000-0000-0000-0000-000000000007
     ↑[Cycle]        --[ownership]--> ServicePrincipal/test_cycle_app2/00000000-0000-0000-0000-000000000006

### Managed Identity Service Principals ###

ManagedIdentityServicePrincipal/test_managed_identity_2/00000000-0000-0000-0000-000000000008
     --[federated_identity]--> ManagedIdentityServicePrincipal/test_managed_identity_1/00000000-0000-0000-0000-000000000009
         --[federated_identity]--> AppRegistration/another_app/00000000-0000-0000-0000-000000000010
             --[sp_of_app]--> ServicePrincipal/another_app/00000000-0000-0000-0000-000000000011

### Orphan Service Principals ###
 Any entry in this section should be reviewed as external appRegistrations have access to the listed resources.

ServicePrincipal/An External App/00000000-0000-0000-0000-000000000099 [HAS PRIVILEGED ROLE]
     --[Entraid_Role (Cloud Application Administrator)]--> Entities of type ServicePrincipal, AppRegistration

JSON and CSV: structured exports containing, for each entity, its direct Entra ID roles, its direct app role assignments, its direct delegated permissions, and all inherited permissions, with their origin traced back to the source entity. These can be fed into report templates or processed further with any standard tooling.

Below is an example of the JSON output for a user inheriting permissions through ownership of an AppRegistration whose Service Principal has the Global Administrator role assigned to it. The output includes both the direct permissions (empty in this case) and the inherited permissions, along with the direct origin (the entity from which the permission was inherited, which might not be the ultimate source) of each inherited permission:

$ uv run qazpt inheritance --direct-origin --as-json | jq

[
 {
  "Entity": {
    "Type": "User",
    "Name": "test1",
    "ID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  },
  "EntraID Roles": [],
  "Application Roles": [],
  "Delegated Permissions": [],
  "Inherited EntraID Roles": [
    {
      "Role(s)": [
        "Billing Administrator",
        "Cloud Application Administrator",
        "Global Administrator"
      ],
      "Origin entity": {
        "Type": "AppRegistration",
        "Name": "general_admin_app",
        "ID": "00000000-0000-0000-0000-000000000001",
        "App ID": "00000000-0000-0000-0000-000000000050"
      }
    },
  "Inherited Application Roles": [
    {
      "AppRole(s)": [
        "Microsoft Graph/AppRoleAssignment.ReadWrite.All",
        "Microsoft Graph/User.Read.All",
        "Microsoft Graph/Application.ReadUpdate.All",
      ],
      "Origin entity": {
        "Type": "AppRegistration",
        "Name": "general_admin_app",
        "ID": "00000000-0000-0000-0000-000000000001",
        "App ID": "00000000-0000-0000-0000-000000000050"
      }
    }
  ],
  "Inherited Delegated Permissions": []
 }
]

Neo4j export: exports the full graph to a Neo4j database for interactive exploration using Cypher queries. This is the most useful format for large tenants, for identifying non-obvious privilege escalation paths visually, or for preparing graph-based evidence for a report.

Below is an example of a Cypher query, and its result, that finds all entities which have inherited an Entra ID role, along with the inheritance path:

MATCH (target)-[:HAS_ENTRAID_ROLE]-> (r:EntraIDRole)

MATCH (e) WHERE NOT (e)-[:HAS_ENTRAID_ROLE]->(r) AND e <> target
MATCH p = allShortestPaths((e)-[:CONTROLS*1..6]->(target))
WHERE NONE(n IN nodes (p) [1..-1] WHERE (n)-[:HAS_ENTRAID_ROLE]->(r))

RETURN e, nodes(p) AS path, r

Below is another example of a Cypher query that finds all entities controlling all entities (scope_level: "ALL"), and the path that leads to them:

MATCH q = (target {scope_level: "ALL"})-[:HAS_APP_ROLE|:HAS_ENTRAID_ROLE]->(r)
MATCH (e) WHERE NOT e.scope_level = "ALL" AND e <> target
WITH e, target, q

MATCH p = allShortestPaths((e)-[:CONTROLS*1..6]->(target))
WHERE NONE(n IN nodes(p)[1..-1] WHERE n.scope_level = "ALL")

RETURN p, q

Note that a depth limit of 6 is set in the previous queries, but it can be adjusted depending on the size and complexity of the tenant. In practice, most privilege escalation paths are relatively short, and a limit of 6 is usually sufficient to capture them without overwhelming the output with excessively long and unlikely chains.

Limitations and caveats

QAZPT is a proof of concept and has known gaps:

Azure Resource Manager (ARM) permissions are not covered: Managed Identities with ARM RBAC roles are not analyzed and so are Kubernetes roles.
Group membership is partially handled: transitive Entra ID roles granted through groups are included, but application role assignments via group membership are not.
Privileged Identity Management (PIM) is not supported: roles that are only activated on-demand via PIM do not appear.
The list of Entra ID roles and Graph application roles treated as privilege escalation paths is not exhaustive, and covers mainly the most commonly seen ones in assessments.

Conclusion

Auditing application permissions in Microsoft Entra ID is hard, and most of the difficulty comes from things that are not visible by default: hidden Service Principal credentials, undocumented or asymmetric API behaviors, and especially the transitive nature of permissions. An entity rarely accumulates risk by holding a single dangerous role; in practice, the worst exposures are the result of long chains where ownership, group membership, federated identity, and privileged role assignments stack on top of each other. Looking only at direct assignments gives you a fraction of the picture, and that fraction is often the least interesting one.

This is exactly where most existing tooling stops, and where QAZPT focuses. By computing and aggregating effective permissions per entity, with each inherited permission traced back to its origin, it gives security assessors and auditors a starting point that the Azure Portal and most commercial tools do not provide. It is not a complete solution; ARM RBAC, full group inheritance, and PIM are still on the roadmap. However, it covers a large enough share of the real-world inheritance surface to be useful in actual assessments, both offensive and defensive. The source code is available on GitHub, and contributions, issues, and feedback are welcome.

Quarkslab's blog - Cloud