Cross-Tenant Confused Deputy

What a cross-tenant confused deputy really is

A cross-tenant confused deputy appears when a trusted intermediary, such as an identity provider, broker, API gateway, or cloud service, accepts a request from one party and then applies its own authority in a different tenant or trust domain. The core failure is misplaced trust, where valid privilege is exercised for the wrong caller.

This is more than “too much access.” The authority may be correct inside one boundary, yet become dangerous once the intermediary crosses into another organisation’s tenancy, federation boundary, or delegated trust relationship. That is why these bugs often sit at the intersection of authentication, authorization, and trust boundary design.

Why cross-tenant confused deputy failures are dangerous

The danger comes from the mismatch between who initiated the action and whose authority is used to complete it. When an intermediary is allowed to translate or forward requests across tenants, a small validation mistake can turn one tenant’s legitimate access path into another tenant’s unauthorized control path. In cloud identity, that can mean impersonation, administrative elevation, data exposure, or tenant-wide blast radius.

The pattern is especially risky in federated systems because the intermediary is often designed to be helpful and high-trust. If it does not bind tokens, audiences, tenants, and request context tightly enough, it may honour a request that should have been rejected. That failure can be invisible to the caller, which makes it harder to notice during normal testing.

Where the failure usually lives

Cross-tenant confused deputy issues usually arise in token handling, trust delegation, and request validation. Common weak points include audience confusion, token passthrough, missing tenant binding, weak delegation checks, overbroad federation trust, and services that reuse their own credentials when acting on behalf of a caller.

Cloud platforms and identity brokers are not the only places this can happen. Any intermediary that makes authorization decisions after receiving a request from an external or semi-trusted tenant can become the deputy. The risk increases when trust is reused across many tenants, because one validation flaw can affect a large population at once.

For a practical view of the surrounding control problem, NHIMG’s Cloud Workload Identity Guide shows why temporary credentials, federation, and trust boundaries must be designed so one tenant cannot borrow another tenant’s authority.

How organisations should think about prevention and review

Defenders should treat this as a trust-boundary engineering problem first and an identity problem second. The right question is not only “is the caller authenticated?” but “is the intermediary proving that the caller is entitled to act in this tenant, for this resource, under this audience, with this delegation path?”

That is why secure designs usually narrow token scope, bind tokens to the intended resource, minimise cross-tenant trust, and make delegation explicit rather than implicit. After any suspected abuse, organisations should review federation configuration, token validation logic, delegated permissions, and administrative actions taken through intermediary services.

NHIMG’s Federation and Trust Relationships Guide is useful here because the same trust relationships that enable collaboration can also expand exposure when they are too broad or too loosely constrained.

For cloud and platform owners, the key control expectation is simple: an intermediary should not be able to cross a tenant boundary unless the authorization model explicitly allows that exact move. NHIMG’s MCP Security Guide is a helpful parallel for delegated access design, because it highlights why token passthrough and weak authorization boundaries are dangerous in any brokered model.

What to check after exposure or suspected abuse

After suspected exploitation, organisations should verify whether the issue was limited to one request path or whether it affected a broader trust relationship. That means checking whether tokens were accepted outside their intended audience, whether cross-tenant access settings were permissive, and whether any privileged actions were performed through the intermediary on behalf of the wrong tenant.

If the intermediary handled credentials, tokens, or service identities, those materials may need rotation or revocation, depending on how the compromise occurred. Post-incident review should also focus on logs that show tenant switching, delegation changes, unusual consent events, or administrative actions that do not match the expected caller and tenant context.

NHIMG’s Red Teaming AI Agents for Identity Abuse also helps frame the detection mindset, because delegation abuse and confused-deputy behaviour often look legitimate unless the logs preserve the full chain of authority.

Risk and Threat Considerations

Cross-tenant confused deputy failures are dangerous because they let a trusted intermediary carry out a privileged action in the wrong trust domain. The resulting exposure can include tenant takeover, unauthorized data access, and broad lateral movement across federated or cross-tenant trust relationships.

Failure mechanism: The intermediary validates the request in one context, then reuses its own authority in another context without correctly binding tenant, audience, and delegation state.

Impact: An attacker or unauthorized caller can abuse a legitimate trust path to reach resources, permissions, or administrative actions that were never intended for that tenant.

Practitioner Guidance

Why practitioners should care: This term signals a design failure in delegated trust, not just a bad permission setting. If your platform brokers access across tenants, the security question is whether every forwarded action is constrained by explicit tenant binding and audience checks.

What to watch for: Pay special attention to services that accept one tenant’s credential or token and then call another tenant’s API, directory, or control plane. Those flows deserve stricter validation, tighter scoping, and more aggressive logging than ordinary single-tenant requests.

Related resources from NHI Mgmt Group

• Why do bundled workflow APIs increase the risk of confused deputy bugs in multi-tenant systems?
• How should security teams secure AWS cross-account access to avoid confused deputy risk?
• Why do OIDC token validation failures create confused deputy risk?
• How can organisations prevent confused deputy problems in API access?