Cross-service impersonation is a confused deputy condition where one service is tricked into acting on behalf of an unauthorized caller. In cloud IAM, the control objective is to constrain service roles so they can only interact with approved services, resources, and trust paths.
Expanded Definition
Cross-service impersonation describes a confused deputy failure in which one service is induced to use its own authority in ways the caller should not be able to trigger. The key boundary is that the service is not merely “calling another service”; it is acting with trust that has been overextended across services, tenants, or execution paths. In cloud IAM, that usually means a role, token, or delegation chain can be used in a context the original trust policy did not intend.
The practical distinction is between legitimate service-to-service delegation and an impersonation path that bypasses the real authorization intent. This is why the issue is often discussed alongside trust policy design, service role scope, and conditional access controls. When the subject is machine-to-machine trust, the identity question is not optional: the service’s authority becomes the security boundary. The OWASP Non-Human Identity Top 10 is a useful external reference because it frames how non-human trust relationships can fail when identity scope is too broad.
A common misunderstanding is to treat the service as “safe” because it is internal. In reality, the confused deputy risk comes from internal trust being reachable through an untrusted request path.
Examples and Use Cases
Cross-service impersonation appears wherever one workload can call another with delegated authority, especially in cloud-native systems and identity-aware APIs. The pattern is not limited to one vendor or protocol; it is a design issue in how trust is expressed and constrained.
- A file-processing service accepts a user-supplied object reference and then uses its own storage permissions to retrieve data the user should not access.
- An orchestration service forwards a caller’s context to a downstream API, but the downstream service trusts the orchestrator’s role more than the original caller’s entitlement.
- A serverless function assumes a broad execution role, then a parameter change allows an attacker to trigger actions in a different account or resource boundary.
- An internal broker signs or relays requests for multiple applications, and one application can induce the broker to act outside the intended trust path.
- A control plane integration is convenient because it reduces integration overhead, but that convenience can hide weak service scoping and make authorization failures harder to spot.
The tradeoff is familiar: broad delegation simplifies service integration and automation, but every additional trust path increases the chance that one service becomes an unintended proxy for another.
Security Implications
When cross-service impersonation is present, the impact is usually privilege amplification rather than direct credential theft. The attacker or abusive caller does not need to steal the service’s identity if they can steer the service into using it on their behalf. That makes the issue especially dangerous in systems where one workload can reach many downstream APIs, because the blast radius is defined by the service’s permissions rather than the caller’s.
The failure mechanism is usually weak separation between caller intent and service authority. If a service trusts a request parameter, forwarded header, token claim, or routing decision without binding it to a narrow authorization check, the service may execute actions that appear legitimate to downstream systems. Observable symptoms include unexpected access across resources, overbroad service-to-service calls, and audit logs that show authorized service identities performing unauthorized business actions.
Practitioners should pay attention when a service can both interpret external input and use a privileged execution context. That combination is the classic condition that turns normal delegation into confused deputy behavior.
Domain and Governance Relevance
In cloud IAM, cross-service impersonation is a governance problem as much as a technical one because it reveals where trust boundaries have been drawn too loosely. The core control question is not whether services can communicate, but whether each service is constrained to the services, resources, and delegation paths it is meant to use. That is why trust policy design, role scoping, and explicit service authorization are central to managing the term.
For NHI governance, the relevance is direct: the service identity is the actor, and its authority must be inventoried, bounded, and reviewed like any other non-human identity. If a machine identity can be induced to act outside its intended purpose, lifecycle controls, ownership, and access review become part of the mitigation, not an afterthought. NHIMG treats this as a trust-boundary issue rather than a purely permissions issue.
Practically, the term matters most where automation, delegation, and service identity are tightly coupled. The more reusable the service role, the more carefully its trust conditions need to be defined.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Service impersonation abuse often depends on overbroad machine identity authority. |
| NHI-02 — Inventory and Ownership | Cross-service trust paths require clear ownership of each non-human identity. | |
| Recommendation — Scope service credentials tightly and rotate or revoke any identity that can be abused across services. Maintain an inventory of service identities and assign owners for every delegated trust path. | ||
| CIS Controls v8 | 6.3 — Access Control Management | Restrict service permissions so callers cannot trigger unauthorized downstream actions. |
| Recommendation — Enforce least privilege on service roles and remove access paths that exceed intended delegation. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorization | Authorization must constrain how services act on behalf of callers. |
| Recommendation — Apply authorization checks that bind service actions to approved trust paths and resource scopes. | ||
| MITRE ATT&CK | T1134 — Access Token and Credential Manipulation | Impersonation conditions can be abused to gain actions under another identity's authority. |
| Recommendation — Detect and investigate attempts to coerce privileged services into executing unauthorized actions. | ||
Related resources from NHI Mgmt Group
- Why does cross-border digital service delivery raise identity governance risk?
- Who is accountable when impersonation succeeds in a service desk or onboarding workflow?
- What breaks when service account impersonation is granted too broadly?
- How should security teams verify authentication at every service boundary in cross-domain systems?
