Azure’s Hidden Operators: A Threat Model for Platform-Level Managed Identities

In this post, we'll explore, name, define, and threat-model an Azure identity type that has quietly operated inside every customer tenant - never documented under a single name, never owned by you, and never fully visible to you. If someone from the Azure team wants to set the record straight on the canonical term for these identities, my DMs are open.

Introduction

When security teams think about Managed Identities in Azure, they think about the ones they create: a system-assigned identity on a Virtual Machine, or a user-assigned Managed Identity attached to an App Service. These are customer-managed - you create them, name them, assign roles to them, and delete them.

But there is another class of Managed Identity that you did not create, cannot see in your portal, and cannot control. These are the identities that Azure creates for itself to operate the platform on your behalf.

I'm calling these Platform-Level Managed Identities (PLMIs).

What They Are

Platform-Level Managed Identities are identities managed by Azure. They use the same token path, the same metadata endpoints, the same RBAC model as every other managed identity, but their ownership and lifecycle are categorically different than system-assigned managed identities or user-assigned managed identities we are all accustomed to:

These identities are assigned to Azure resource providers, the backend services that make up Azure. For example, when you deploy an API connection or logic app, it's the platform-level identity that operates behind the scenes, performing actions on your behalf to fulfill the service's functionality.

The Naming Problem

There is no unified, public-facing term for these identities. Although the documentation throughout the Microsoft ecosystem has called them many things:

• Platform Identities or Platform MSIs - a catch-all used internally for identities owned by Azure itself
• Resource Provider Identities - e.g., the identity used by Microsoft.ApiManagement or Microsoft.Logic
• First-Party Managed Identities
• Service Identities or Service MSIs - a generic term used for identities used by Azure services
• "Backend Identity" or "Backend Principal" - terminology observed in internal tooling
• Internal Managed Identities (Internal MSI)

⚠️ What they are NOT: Platform-Level Managed Identities should not be confused with First-Party Service Principals (also called Microsoft First-Party Applications, or FPSPs). FPSPs are the identities I discuss in the Comparing CSP-Managed Machine Identities whitepaper - these live in Entra ID as enterprise applications (e.g., SharePoint Online, Microsoft Teams) and are visible in your tenant. Platform-Level Managed Identities are a completely separate category.

If you work at Azure and have a definitive answer for what these should be called, please reach out. 

How to Detect One

Because Platform-Level Managed Identities live in Microsoft's tenant, not yours, the only signal you will see is an RBAC log entry indicating that the principal comes from outside your tenant. The log entry below is an example fetched from an Azure tenant showing a PLMI in action (with identifiable information redacted):

An object ID that returns no result when you run az ad sp show --id <objectId> is a strong indicator that you are looking at a Platform-Level Managed Identity.

Key Architectural Characteristics

A quick breakdown of this architecture:

• Microsoft Internal Tenant: The Platform-Level MI resides in Microsoft's own internal tenant.
• Customer Tenant: The customer holds the downstream resources (e.g., Key Vault, Storage).
• Customer-Assigned RBAC: Crucially, unlike their AWS and GCP equivalents, the RBAC grant that allows the PLMI to access the resource is assigned by the customer within their own tenant.
• Cross-Tenant Access: The PLMI uses these customer-assigned grants to perform actions across tenant boundaries.

Two defining characteristics set these apart from customer-managed identities:

1. Multi-Tenancy: A single Platform-Level Managed Identity for a given Resource Provider is used to operate across all customer tenants. It is a global actor, not a per-customer one.
2. Fully CSP-Managed: The identity itself lives in Microsoft's own environment. Customers cannot directly manipulate, restrict, or even enumerate it.

This is the fundamental tension: these identities are highly privileged global actors. Because they live outside your environment, the only direct control you have of them is the RBAC permissions you assign them. But as we will see, those assignments are typically required to allow for PaaS functionality. The only 'opt-out' is often to plainly just not use a service.

What Can Go Wrong?

The architecture above sets up a specific class of vulnerability: a Cross-Tenant Confused Deputy.

A confused deputy attack occurs when a powerful intermediary - a service or process that acts on behalf of multiple principals - is tricked into using its own privileges to perform an action on behalf of an unauthorized party. When the deputy is multi-tenant, the blast radius of that confusion extends across organizational boundaries.

Case Study: The Binary Security API Connections Research

In March 2025, researchers at Binary Security published findings that are the most concrete, publicly documented example of a Platform-Level Managed Identity abuse as a confused deputy.

Background: What are API Connections?

API Connections are Azure resources, often created automatically when you add an action to a Logic App. When you configure a Logic App to perform an action for you, say, retrieve a secret from a Key Vault, an API Connection resource is created in your subscription that stores the authentication context for that backend service. The API Connection is what holds - and uses - the permission to access your Key Vault.

Behind the scenes, that API Connection is operated by a Platform-Level Managed Identity belonging to the Microsoft.Web Resource Provider. When the connection was authorized by whoever set up the Logic App, that authorization necessitated an RBAC grant to this platform-level identity on the backend resource.

The Vulnerability

While the administration needed to authorize RBAC permissions to the Microsoft.Web PLMI seemed sound, Binary Security discovered a path traversal issue in the APIM service's /extensions/proxy/{action} endpoint. This flaw allowed anyone with Reader access to the subscription to leverage that deputy to call ANY tenant's Key Vault secrets, SQL instance, or external connections—whatever they had configured Microsoft.Web to access.

What fell within an attacker's reach:

Backend Resource

Accessible via API Connection Proxy

Azure Key Vault

List all secrets; retrieve secret values

Azure SQL Database

List databases, datasets, tables; read table rows

Jira

List projects, users, issues; read issue content

Salesforce

Account data, contact records

Azure Defender ATP

Alerts, incidents, and investigation data

Azure Storage Blobs

Blob contents

In the Jira example, Binary Security also found an SSRF: the X-Request-Jirainstance header was not validated, allowing an attacker to redirect requests to an attacker-controlled server and exfiltrate the Jira API token stored in the connection.

The Attack Pattern

Here is a breakdown of how the attack unfolds:

• Step 1: An attacker (with only Reader access to the victim's subscription) sends a GET request to the connection's proxy endpoint, using a path-traversal payload ("../../../") to escape the intended API scope.
• Step 2: Azure Resource Manager (ARM) checks if the attacker has Reader access. Since it's a GET request, ARM says "✅ Yes - proceeds".
• Step 3: ARM forwards the call to the Platform-Level MI to invoke the backend API.
• Step 4: The Platform-Level MI checks its own RBAC permissions on the Key Vault. Since it was granted access during connection creation, it proceeds.
• Step 5: The Platform-Level MI retrieves the secret from the Key Vault and returns it to ARM, which delivers it to the attacker.

‍

Why This is a Cross-Tenant Confused Deputy

While the flow above illustrates how it acts as a confused deputy, the true severity of the vulnerability lies in its cross-tenant impact. Because the PLMI is a global actor, an attacker in a completely different tenant who discovers an exposed proxy endpoint can leverage the PLMI's authority to cross tenant boundaries. The confused deputy-the Platform-Level Managed Identity-had legitimate authority across multiple customers. It was tricked into exercising that authority on behalf of an unauthorized party from another tenant, making it a cross-tenant issue rather than just a local privilege escalation.

What Are We Doing About It?

Unlike AWS - where customers have both the ability and the responsibility to add condition keys to resource policies to constrain confused deputy attacks, Azure customers have no controls over cross-tenant impact. They do have control over same-tenant confused-deputy risks, as RBAC permissions for PLMIs are not automatically assigned; an admin must assign them. But thinking critically: how good of a control is it when, in order to use it (by not assigning an RBAC permission), you must just not use the service functionality? Furthermore, the responsibility for true cross-tenant mitigations falls entirely on Microsoft.

This mirrors the pattern seen with Google Cloud Service Agents: the provider controls the identity, so the provider must also own the security of its use. The absence of a customer-side control is not a missing tool — it is the provider shouldering their own security burden.

Mitigation 1: Service-Level Path Enforcement (Provider-Side)

In the API Management case specifically, the intended mitigation was a Swagger/OpenAPI document that restricted which paths could be called through the API Connection proxy. The platform identity would only invoke backend paths that the Swagger document declared valid.

This is a sound mitigation in principle: constrain the actions to which the PLMI can be directed, regardless of who is asking.

The problem: Binary Security found that this Swagger validation was vulnerable to path traversal. By manipulating the path, an attacker could escape the declared scope and reach arbitrary backend endpoints. Microsoft fixed this silently — customers were unknowingly protected by a patch they never knew was needed.

More fundamentally, this type of path-level enforcement is not universally applicable across Azure services. It is a control specific to how the APIM service processes API Connection requests. Other Resource Providers using Platform-Level Managed Identities do not have equivalent controls.

Mitigation 2: RBAC Authorization at Connection Creation (Customer Responsibility)

The second mitigation is the one within the customer's control, even if only indirectly: the approval step when creating an API Connection.

When a Logic App developer creates an API Connection to a Key Vault, they (or someone with appropriate access) must authorize the connection. This authorization step results in an RBAC grant to the Platform-Level Managed Identity on the backend resource.

This is the only meaningful checkpoint in the flow:

This approval gate matters, but not to the extent Microsoft might think. In order to use this mitigation (by not assigning the RBAC permissions), you are effectively choosing not to use the service. Sure, in its strictest sense, it is a mitigation (have vulnerable code? delete the App!). But relying solely on this means there are no customer-side controls to prevent a malicious tenant from accessing your resources via a globally scoped PLMI once those permissions are granted to enable the PaaS functionality.

Mitigation 3: Link by Reference (Provider-Side)

Azure has an additional control plane check that acts as a 'Link by Reference' control. This control mitigates PLMI abuse to some degree by ensuring that a caller who references a downstream resource during an ARM deployment actually possesses equivalent permissions on that resource.

For example, if you attempt to create an Azure Monitor autoscale setting targeting a Virtual Machine Scale Set (VMSS), ARM checks that you have Microsoft.Compute/virtualMachineScaleSets/Write permissions on the VMSS. If you don't, the deployment fails with a LinkedAuthorizationFailed error before the platform identity is ever engaged.

So, why wasn't this mitigation present in the API Management/Logic Apps service? Because the 'Link by Reference' control is typically enforced by Azure Resource Manager (ARM) during the control-plane creation or update of a resource. The APIM vulnerability involved a data-plane proxy runtime endpoint (/extensions/proxy/{action}) that accepted a target resource URI dynamically and immediately forwarded the request. Since the proxy endpoint operated outside the standard ARM resource-creation flow and did not independently implement a linked-resource check for the forwarded path, the platform identity was invoked without validating the caller's target-side authority.

Missing Customer Controls

The key control Azure is missing with Platform-Level Managed Identities is any form of customer-side preventive control to prevent cross-tenant confused deputy issues. AWS has such control with condition keys in resource policies, and Google Cloud has mitigated this issue by not having global service identities at all. What Microsoft has failed to realize is that highly privileged global actors inherently have the capability to abuse resources across organizational boundaries. In these scenarios, cloud service providers must put preventative controls directly into the hands of their customers, giving them the peace of mind that they can positively prevent such abuses, the ultimate breach in trust with their customers.

The research in this post draws on the Binary Security API Connections disclosure (March 2025), the Comparing CSP-Managed Machine Identities whitepaper (Vectra AI, October 2025), and original research presented at RSA Conference 2026.

📣 A note to the Azure team: If you can point to authoritative documentation for Platform-Level Managed Identities - including canonical naming or policy control surface - I would genuinely like to be corrected.

‍