The Two Mitigations for the Service-Account Confused Deputy in the Cloud
A confused deputy is nothing more than a privileged intermediary tricked into acting for a caller who lacks the authority itself. In the cloud, it has two distinct flavors, one leveraging a non-human identity (NHI) owned by you, the customer, and one leveraging a non-human identity (NHI) owned and operated by the CSP.
The Organizing Axis: Who Owns the Identity
Every cloud splits non-human identities into two camps.
- Customer-managed: identities you create and attach to your own compute — GCP service accounts, AWS IAM roles, Azure user-assigned andmanaged identities. The confused-deputy risk is you (or a lower-privileged principal in your account) attaching an identity to an execution environment you control and thus, creating a privilege escalation route to use its permissions.
- Provider-managed: identities the CSP creates and wields as a deputy inside your tenant — GCP service agents (per-product, per-project service accounts), AWS service-linked roles/service principals, Azure platform-level service principals. Sometimes they carry standing trust whose privilege can be abused, leveraging service functionality.
For more detailed information on these two types of service accounts, see my whitepaper comparing CSP-managed Identities and a blog I wrote on Azure’s Platform-Level Managed Identities.
The mitigation for privilege escalation varies between the two types of service accounts.
Mitigation 1 — Mark the Attachment (Customer-Managed Identities)
When a caller attaches an identity to an execution environment such as a VM, function, job, or container, their code inherits that identity's privileges. The control is a bind-time authorization check on the caller, scoped to the target identity, evaluated when the (identity → execution-environment) association is created or changed.
It is not a runtime check. Once the identity is attached, the resource's code automatically retrieves that identity's token from the metadata endpoint without re-evaluation. The gate check is performed at attachment time, not when the already-deployed workload runs.
None of the three gates is a standalone API — each check is the responsibility of the service that performs the attachment.
Lots of Privilege Escalation, Only One is Via A Confused Deputy
Attaching an identity, editing who may wield it, and minting its tokens are three distinct actions in a cloud that could lead to privilege escalation. Let's make sure we are clear on which are confused deputy issues and which ones are not.
On GCP:
- attach: iam.serviceAccounts.actAs — controls which identity is bound to a resource.
- delegate: iam.serviceAccounts.setIamPolicy on the SA — the write that grants the actAs edge in the first place (changing the SA's own roles on other resources is different again).
- mint: iam.serviceAccounts.getAccessToken via roles/iam.serviceAccountTokenCreator — token issuance, which roles/iam.serviceAccountUser does not grant.
All three permissions above manage privilege escalation; only the first marks privilege escalation via confused deputy.
Mitigation 2 — Guarding the Provider's Deputy
Provider-managed identities are the other half with GCP service agents, AWS service-linked roles, and Azure platform-level managed identity. The risk is a lower-privileged caller (or another tenant) inducing that deputy to use its permissions (standing or otherwise) against a resource the caller isn't entitled to.
The mitigation here lives on the provider side: internal authorization checks that validate the true originating caller has rights on the target, optionally supplemented by customer-supplied condition keys. The sharp contrast is observability — AWS names and exposes its machinery; GCP and Azure hide theirs behind a denial.
AWS is the only one of the three that surfaces its confused-deputy machinery as first-class primitives and gives the customer some control. The two AWS sub-mechanisms:
- FAS: Forward Access Sessions internally carry the original IAM principal's identity and permissions, and the downstream service rechecks that same principal and its permissions. The deputy never exceeds the caller's own rights; the downstream call succeeds only if that same caller already holds the permission on the downstream resource (e.g., the KMS key), never more.
- Condition Keys: When a service acts via an assumed service role or service-linked role, it uses the role's permissions, and the caller's identity is not carried forward. So, on the customer, condition keys can be supplied, limiting who the global principal can act on behalf of against their resources (keys include: aws:SourceArn, aws:SourceAccount, aws:SourceOrgID, aws:SourceOrgPaths).
GCP's and Azure's internal checks stay opaque — you learn they exist only when one denies you. Azure's fires whenever an operation references a second resource: try to create something that joins a subnet you don't control, and ARM demands you also hold Microsoft.Network/virtualNetworks/subnets/join/action on that subnet — not just permission on the resource you're creating. That extra check is the confused-deputy guard: it stops a create you're allowed to make from quietly pulling in a resource you're not. You'll only ever see it as a LinkedAuthorizationFailed error.
Wrap-Up
The mitigation follows the ownership. If you own the identity, the attachment gate applies (.actAs / iam:PassRole / 'assign/action'). If the provider owns it, the guard is theirs, with the outlier being AWS condition keys (aws:SourceAccount, aws:SourceOrgID).