Azure machine-identity discovery is trustworthy only when the VM principal and scope are established before management-plane, data-plane, and Microsoft Entra directory access are evaluated separately. This article shows how those boundaries become connected attack paths and how selected transitions can be proved and restored safely.
Consider a VM that can describe an Azure Key Vault, Microsoft's managed service for secrets and keys. The same VM receives a denial from the vault's secrets endpoint. A broad operator session can hide that distinction because it describes what an administrator sees instead of what the workload reaches.
Pentest Copilot is an internal assessment system. It starts from the managed identity attached to the VM and binds that identity to one approved subscription and resource group. Each service is then tested through the authorization plane that governs the requested action. Azure Resource Manager visibility, service data access, and Microsoft Entra directory access are related, but they are not interchangeable.
| Security question | Discovery rule | Why it matters |
|---|---|---|
| Which principal is running on the VM? | Resolve the managed identity from the VM context | Avoids measuring an operator's cached session |
| Where is discovery bounded? | Match the VM to one approved subscription and resource group | Prevents unrelated Azure environments from entering scope |
| Which authorization plane answered? | Record management, data, and directory results separately | A visible resource is not proof that its content is readable |
| What forms an attack path? | Connect identities, role assignments, workloads, data, and private services | Shows how control moves rather than listing objects |
The four paths below explain the model:
| Layer | What is established |
|---|---|
| Machine identity | The token belongs to the managed identity attached to the assessment VM |
| Scope | One approved subscription and resource group |
| Management plane | Azure Resource Manager objects, configuration, and RBAC scope |
| Data plane | Service-specific access to secrets, blobs, files, queues, databases, or workloads |
| Directory plane | Explicitly approved Microsoft Entra and Microsoft Graph visibility |
| Hybrid reach | Cloud resources remain connected to private network services |
| Active proof | State-changing paths use named targets, explicit approval, and rollback |
Microsoft describes managed identities as identities maintained in Microsoft Entra ID whose tokens can be requested from the VM's Instance Metadata Service. The identity can authenticate without storing an application password, as shown in How managed identities work with Azure VMs.
The assessment reads the VM's subscription and resource-group context, then requests a token for the attached identity. The token identifies the principal whose access is being measured. When more than one user-assigned identity is present, the intended identity must be selected explicitly rather than relying on an ambiguous default.
Resource-group containment matters because a subscription often spans teams, applications, and environments. If the workload's context does not match the approved subscription and resource group, discovery stops instead of broadening into the rest of the tenant.
Impact: every later result is attributable to the workload identity and bounded Azure resources, not to a human administrator or an adjacent environment.
Azure does not have one universal “can access” decision. Resource configuration is governed through Azure Resource Manager, which is the management plane. Reading or using the content inside a resource is governed by that service's data plane. Directory data adds a third boundary because Microsoft Graph applies its own permissions and consent.
| Example | Management-plane question | Separate data or directory question |
|---|---|---|
| Key Vault | Can the identity describe or configure the vault? | Can it read a secret, key, or certificate? |
| Storage account | Can it view account configuration? | Can it read blobs, files, queues, or tables? |
| Function App | Can it update application settings or deployment configuration? | Can it reach protected application data? |
| Managed identity | Can it be attached to a workload? | What can a token for that identity access? |
| Microsoft Entra group | Is an Azure role assigned through the group? | Can directory membership be enumerated or changed? |
Microsoft's managed-identity security guidance explicitly distinguishes Azure's control plane and data plane. A 403 from a data endpoint therefore must not erase the resource discovered through Resource Manager. It means the object exists while this identity could not cross that data boundary.
An absent resource, a data-plane denial, and an unexpected collection failure are retained as different outcomes. This prevents missing visibility from appearing as a clean environment.
Impact: defenders see the exact plane that accepted or denied the action, preventing ARM visibility from being reported as secret, storage, or directory access.
A VM, role assignment, managed identity, Function App, and Key Vault are not automatically one path. The security story depends on the edges between them.
| Azure object | Relationship that matters | Candidate path |
|---|---|---|
| VM | Uses a system-assigned or user-assigned identity | Workload compromise becomes token access |
| Role assignment | Grants a principal actions at a specific scope | Identity reaches configuration or data |
| Function or Logic App | Executes as an identity | Code or workflow control becomes identity control |
| Automation account | Runs runbooks with identities and connections | Configuration control becomes execution |
| Storage account | Contains data and may expose shared-key paths | Management access may bypass narrower data RBAC |
| Network interface | Connects a VM to a subnet and private endpoint | Cloud control reaches internal services |
These relationships also preserve hybrid reach. A VM represented in the Azure control plane can be the same machine that exposes SSH, RDP, Windows management, file sharing, a directory service, or a database on a private address. Treating cloud and network discovery as separate inventories would hide that transition.
Impact: the result answers causal questions-whether identity attachment, workload control, shared access, or private connectivity creates a usable path.
Discovery should nominate a path, not improvise a target. Active proof is limited to the exact resource and vulnerability category approved for the assessment.
| Candidate path | Bounded proof | Recovery requirement |
|---|---|---|
| Managed-identity attachment | Add one selected identity, obtain its token, verify the principal, perform one approved read | Restore the complete original identity set |
| Disk export | Create a short-lived read grant and read a bounded range | Revoke the grant and restore the original power state |
| Function or Logic App control | Apply one controlled package or workflow change | Retain and restore the baseline |
| Role assignment change | Add one identifiable assignment at the approved scope | Remove it and verify the prior authorization state |
| Monitoring or network change | Modify one disposable target | Restore and re-read the original configuration |
A permission to attach an identity is not itself proof that the new identity can be used. The proof has to request a token for that identity and perform an action within scope. Likewise, permission to export a disk is not the same as reading its contents; the evidence should show the bounded read and cleanup.
If the identity transition, bounded operation, or restoration fails, that failure remains the result. It is not replaced with a weaker conclusion based only on the role assignment.
Impact: theoretical Azure permissions become verified transitions without leaving identities, grants, deployment changes, or network state behind.
A resource-group boundary does not establish what exists elsewhere in the subscription. A management-plane denial leaves configuration visibility unknown, while a data-plane denial leaves content access unknown. Microsoft Graph access is not implied by an Azure resource role, and project or tenant administrators outside the workload path are deliberately excluded.
Machine-identity discovery is trustworthy when the principal, scope, authorization plane, resource relationship, proof, and recovery all agree. If one is missing, the result should keep that uncertainty visible instead of replacing it with an empty inventory or an assumed compromise.
