Why do provider-managed identities create cross-tenant confused deputy risk?

How provider-managed identities become a cross-tenant confused deputy

A provider-managed identity is powerful because the provider, not the customer, owns the trust anchor and often the execution path. That creates confused deputy risk when a caller can influence the provider to perform an action with broader authority than the caller should ever receive. The key problem is not just privilege size, but whether the trust boundary is enforced per tenant.

In a single-tenant design, a misuse is often contained by local scope. In a global or tenant-invisible identity model, the same deputy can be invoked across many customer boundaries, so a weakness in request binding, tenant context, or delegation rules can spill into other tenants. Cloud Workload Identity Guide explains the broader pattern where cloud trust relationships must bind the caller, the workload, and the target resource tightly enough that a stronger intermediary cannot be reused out of context.

Where the trust boundary breaks down

The risk appears when the provider’s identity is treated as an internal implementation detail instead of a security boundary. If the service uses its own authority after receiving an ambiguous request, the caller may be able to trigger actions intended for a different tenant, another workflow, or a higher-privilege context. That is why cross-tenant confused deputy issues usually involve delegation, token exchange, or trust relationships that are too coarse for the operation being performed.

When the same identity serves many tenants, the system needs a reliable way to carry tenant context through every authorization decision. Without that, the provider can validate the caller correctly but still act on the wrong behalf. Federation and Trust Relationships Guide is useful here because it frames cross-tenant exposure as a trust design problem, not just an access-control problem.

A related failure mode is overbroad delegation. If a platform supports customer-specific access but the underlying managed identity is shared, one tenant’s request can be mistaken for a general service request. That is the classic confused deputy shape: the deputy has legitimate power, but the request lacks enough binding to prove that the power should apply in this case.

Why the blast radius is larger in provider-managed models

Provider-managed identities can increase blast radius because the identity often sits above many customer workloads, subscriptions, or projects. A mistake in one validation path may affect more than one tenant, and the attacker does not need to steal the provider’s identity to benefit from it. Instead, the attacker only needs a way to shape the request so the provider uses its own authority in the wrong context.

This is especially dangerous when tenant boundaries are invisible to the identity itself. The provider may see a legitimate service call, but not the tenant-specific intent that should constrain it. Microsoft Azure Security Guide is relevant because cloud platforms commonly mix managed identities, role assignment, and scope, and the security outcome depends on whether those boundaries are expressed clearly enough in the control plane.

In practice, the attack surface expands wherever the provider reuses one identity for multiple customers, multiple environments, or multiple trust domains. The more opaque the provider identity is to the tenant, the easier it is for a caller to rely on inherited authority that was never meant to cross organisational lines.

Risk and Threat Considerations

Cross-tenant confused deputy flaws are high impact because they turn legitimate delegated trust into an abuse path across customers. The risk is not only unauthorized access, but misattribution of authority, where one tenant’s request can cause the provider to operate with another tenant’s effective privileges or data scope.

Failure mechanism: The provider authenticates the caller, but fails to bind tenant identity, request context, and downstream authority tightly enough. The service then uses its own broader authority as a deputy, which lets a lower-privilege caller steer privileged action across tenant boundaries.

Impact: Unauthorized data access, cross-tenant action execution, privilege escalation, and wider compromise of trust in the provider’s delegation model can follow. In multi-tenant systems, the same flaw can repeat at scale because one bad trust decision may affect many customers.

Practitioner Guidance

What to verify: Confirm that every privileged action carries an unambiguous tenant binding from request to authorization decision. If the provider identity can act across tenants, check that the tenant context is enforced at the resource, token, and policy layers, not only at login or API gateway time.

Decision rule: If an operation depends on the provider’s own authority, treat it as a delegated trust path and require explicit audience, scope, or tenant restriction. If the platform cannot prove that the caller is entitled to that specific tenant context, do not allow the provider identity to act on the caller’s behalf.

What practitioners underestimate: The most dangerous cases are often not obvious misconfigurations, but design choices that make a global identity convenient. Convenience increases the chance that the same trusted deputy will be reused in places where the caller should never inherit that power.

Practitioner takeaway: Cross-tenant confused deputy risk is a delegation failure, so the control objective is to make tenant context non-optional and machine-enforced wherever provider authority is exercised.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?
• Why do tenant-scoped credentials create cross-cluster risk in managed Kubernetes environments?