TL;DR: Azure’s platform-level managed identities are globally scoped, customer-invisible actors that can create a cross-tenant confused deputy problem when customer-assigned RBAC grants let platform services reach backend resources, according to Vectra AI. The trust boundary fails when a provider-managed identity can act beyond the customer’s direct control.
At a glance
What this is: This analysis defines platform-level managed identities in Azure and shows how provider-owned, tenant-invisible identities can be abused as a cross-tenant confused deputy.
Why it matters: IAM and cloud security teams need to understand that customer-assigned RBAC can still expose backend resources when the acting identity is owned and operated outside the tenant boundary.
Context
Platform-level managed identities are Azure-controlled identities that act behind the scenes on customer resources, but they are not the system-assigned or user-assigned identities most teams expect to govern. The problem is a visibility and ownership gap: when the identity lives outside the tenant, standard inventory and lifecycle assumptions no longer hold.
That gap matters because the trust boundary moves from customer-managed identity governance to provider-managed platform behaviour. In practice, the only direct customer control may be the RBAC grant on the downstream resource, even though the identity itself is not enumerable or administratively owned by the customer. Cloud Workload Identity Guide
Key questions
Q: What breaks when a cloud service uses a provider-owned managed identity outside the tenant boundary?
A: The customer loses direct ownership of the actor while still depending on it for access to backend resources. That breaks the normal assumption that identity lifecycle, visibility, and permission scope can all be governed from one tenant. The practical result is a delegated access model that may be secure in design but opaque in operation.
Q: Why do provider-managed identities create cross-tenant confused deputy risk?
A: Because a powerful intermediary can be tricked into using its own authority on behalf of a caller that should not inherit that authority. When the identity is global and tenant-invisible, the attack is not confined to one customer boundary. The risk comes from delegated trust crossing organisational lines, not just from excessive permissions.
Q: How can security teams tell whether a managed-identity control is only working at provisioning time?
A: If the control depends on a deployment workflow, but the service can later forward runtime requests to arbitrary backend targets, the check is incomplete. Teams should verify that the same authority validation exists at execution time, not only when the resource is created or updated.
A: Only with clear service-level approval, a documented business need, and an explicit understanding that customers may have little or no preventative control over cross-tenant behaviour. If the service cannot be used safely without broad delegated authority, the risk decision belongs in governance, not in a hidden permission grant.
Technical breakdown
Why cross-tenant managed identities behave like confused deputies
A confused deputy appears when a powerful intermediary is asked to act for one party but reuses its own authority in ways the caller should not control. In Azure, a platform-level managed identity can sit in the provider tenant while acting against customer resources through customer-assigned RBAC. That combination turns a normal service dependency into a cross-tenant authority problem because the identity’s privileges are both broader and less visible than a customer-managed workload identity. See the Microsoft Azure Security Guide. See the Microsoft Azure Security Guide.
Practical implication: Treat provider-owned managed identities as delegated authority that must be constrained at the service boundary, not just at the customer resource boundary.
How the API Connection proxy enabled arbitrary backend access
The disclosed attack path used a proxy endpoint that forwarded requests from an Azure service to backend resources through the platform-level identity. The attacker needed only Reader access, then used path traversal to escape the intended scope and induce the deputy to call back-end systems such as Key Vault, SQL, Jira, or Storage. The core failure was not authentication in the usual sense, but an authorization context mismatch between the caller’s rights and the platform identity’s downstream authority. See the Active Directory and Entra ID Hardening Guide.
Practical implication: Review any proxy or connector that relays caller intent into backend access for scope escape and target-resource validation failures.
Why link-by-reference controls work in control plane but fail at runtime
Azure’s link-by-reference pattern is meant to prove the caller already has authority over the referenced resource before the platform identity is invoked. That is effective in control-plane provisioning flows because ARM can compare the target resource against the caller’s permissions. It breaks when the same logic is pushed into a runtime data-plane proxy, where the target URI is supplied dynamically and the service must enforce the check itself. Runtime forwarding and control-plane validation are not interchangeable security models. See the Cloud Workload Identity Guide.
Practical implication: Separate deployment-time authority checks from runtime request forwarding and do not assume one can stand in for the other.
Threat narrative
Attacker objective: The attacker wanted to use a low-privilege tenant foothold to exfiltrate data from backend resources protected by provider-managed delegated access.
- Entry began when an attacker with only Reader access targeted the API Connection proxy endpoint with a path-traversal payload.
- Credential access followed when the platform-level identity was induced to retrieve backend data from customer resources that had already been granted access.
- Escalation occurred because the proxy allowed the attacker to extend a low-privilege tenant role into the authority of a provider-managed identity.
- Impact was unauthorized retrieval of secrets, records, or connection tokens from backend systems reachable through the proxy.
Breaches seen in the wild
- Okta support system breach 2023: A support service account credential saved in a personal Google profile let attackers take HAR files and hijack five Okta customers' sessions.
- Microsoft Storm-0558 key breach 2023: China-based Storm-0558 used a stolen, never-retired Microsoft signing key to forge tokens and read email at 22 organisations in 2023.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Platform-level managed identities create a trust boundary that customer IAM does not fully own: these identities are provider-managed, tenant-invisible, and still capable of acting on customer resources through customer-assigned RBAC. That is a materially different governance problem from ordinary workload identity, because the customer can grant access without being able to enumerate or lifecycle-manage the actor behind it. The implication is that identity governance must distinguish ownership of the resource from ownership of the identity acting on it.
Cross-tenant confused deputy is the right failure model, not just overprivileged access: the issue is not simply that a service had too much permission, but that a globally scoped intermediary could be induced to use its legitimate authority on behalf of an unauthorized caller. That is the kind of failure that breaks the assumptions behind least privilege and tenant isolation in cloud identity design. The implication is that cloud governance must account for delegated authority that spans organisational boundaries.
Link-by-reference is a governance pattern, not a complete control plane: it works when a platform can verify caller authority before a resource reference is accepted, but it does not solve runtime forwarding where the target path is selected dynamically. In other words, pre-authorisation checks are only as strong as the boundary in which they are enforced. Practitioners should treat runtime connector flows as a separate identity control surface, not an extension of ARM policy.
Provider-managed identities expose a missing customer control surface: when a cloud vendor owns the identity, the vendor must also own the preventative controls that constrain how that identity can be used across tenants. Customer-side RBAC alone does not solve cross-tenant abuse if the platform can still be tricked into acting beyond the intended scope. The implication is that governance for provider-owned identities must be evaluated as part of cloud service design, not as a local tenant permission problem. identity security programme
Read next: Cloud Workload Identity Guide
What this signals
Tenant visibility is not the same thing as identity control: when the actor lives in the cloud provider’s tenant, customer IAM can approve access but cannot fully govern the actor’s lifecycle or scope. That means managed identity reviews need to distinguish between identities you own and identities the platform owns, especially when one can reach your Key Vault, storage, or external connectors.
Cross-tenant trust deserves a named control review: provider-managed identities introduce a governance gap that is best understood as cross-tenant authority leakage. The right response is to map every service that depends on a platform-owned identity and decide whether the service boundary, not the tenant boundary, is the real enforcement point. identity security programme
For practitioners
- Inventory provider-owned identity touchpoints Identify services where Azure-managed platform identities can access your Key Vault, storage, APIs, or third-party connectors, and classify them separately from customer-managed managed identities.
- Review runtime proxy and connector flows Test API Connection and similar forwarding paths for path traversal, target-URI manipulation, and scope escape before assuming deployment-time checks cover runtime access.
- Validate RBAC grants at connection creation Require explicit approval for every customer-assigned RBAC grant that enables a provider-managed identity to reach backend resources, and keep an exception record for each one.
- Separate control-plane checks from data-plane enforcement Document which checks happen during provisioning and which must happen during request execution, then verify that neither layer is treated as a substitute for the other.
- Escalate missing provider-side controls Track services where the provider-owned identity has no customer-enforceable boundary control, and treat that absence as a cloud risk acceptance decision rather than a configuration issue.
Key takeaways
- Platform-owned managed identities can act on customer resources without ever becoming customer-owned identities, which changes how governance must be assigned.
- The key risk is a cross-tenant confused deputy, not just a misconfigured permission, because the platform can be induced to use its own authority on the caller’s behalf.
- Practitioners need separate control thinking for provisioning-time checks, runtime forwarding, and provider-side boundary enforcement.
Related NHI Mgmt Group resources: Cloud Workload Identity Guide · Microsoft Azure Security Guide · Identity Security Programme Guide · Active Directory and Entra ID Hardening Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Provider-owned platform identities can expose customer resources through third-party service dependencies. |
| NHI-05 — Overprivileged NHI | The platform-level identity can reach multiple back-end resources across tenants through broad delegated authority. | |
| NHI-06 — Insecure Cloud Deployment Configurations | The attack depended on a service configuration that let runtime forwarding bypass intended path restrictions. | |
| Recommendation — Map provider-owned connector and resource-provider identities to NHI-03 and review their downstream access paths. Scope provider-managed identities to the minimum backend resources needed and remove unnecessary delegated access. Test cloud service configurations for runtime scope escape and enforce boundary checks where requests are forwarded. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is directly implicated when a provider-managed identity can act beyond the intended backend scope. |
| Recommendation — Apply AC-6 to every delegated service identity and remove access that is not strictly required for function. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack path used a low-privilege foothold to reach privileged backend resources through delegated identity use. |
| Recommendation — Map proxy-abuse paths to TA0006 and TA0008 and hunt for delegated access that crosses resource boundaries. | ||
Key terms
- Platform-Level Managed Identity: A provider-owned managed identity that acts inside the cloud platform but is not created, enumerated, or lifecycle-managed by the customer tenant. In practice, it can perform backend actions on behalf of a service while remaining outside normal tenant governance boundaries.
- Cross-Tenant Confused Deputy: A failure mode where a powerful intermediary is tricked into exercising its own legitimate authority for an unauthorized caller across organisational boundaries. In cloud identity, the danger is not just excess privilege, but privilege that is valid in one trust domain and misused in another.
- Link by Reference: A control pattern that checks whether a caller already has authority over a referenced downstream resource before the platform identity is allowed to use it. It is effective only when the validation happens in the same execution path as the action being authorised.
- Credential Forwarding: Credential forwarding is the act of sending a live authentication token or session credential along with a request to another endpoint. When it happens without clear user consent, the receiving server can act as the user within the scope of that credential. The risk is highest when the destination can be changed through configuration.
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.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org