Scoped identity with iam:PassRole could potentially run as prod-admin via a Lambda function it creates, if unblocked by policy controls

Taken one at a time, each of the three permissions is defensible: PassRole is delegation, CreateFunction is deployment, InvokeFunction is operation. Together they are a route to administrator. Finding it takes a three-way correlation a permission list does not contain: which roles the identity is allowed to pass, what those roles' trust policies permit, and which compute resources the identity can create or modify ^[9]. AWS's own documentation is the reason the join matters. The permission lets an identity attach a role with broader permissions than its own to a service or resource it controls. AWS says it has to be evaluated in combination with other permissions ^[5]. On its own it grants nothing; escalation needs the second half, control of something that will execute under the delegated role ^[6].

The trust policy is the first gate. prod-admin has to name lambda.amazonaws.com as a principal allowed to assume it ^[8]. IAM conditions or a permission boundary on the delegating identity can stop it, and so can a service control policy on the account ^[4]. The path is only exploitable if none of those three blocks it ^[12]. A path-analysis hit is therefore a candidate until someone reads policy in three places.

Lambda is one of several execution surfaces. EC2 instances and ECS tasks run with an assigned IAM role the same way ^[7], so closing the Lambda variant and stopping there leaves the instance profile and task role versions of the same delegation in place.

The remediation is policy text. Replace PassRole on * with the specific roles an identity operationally needs ^[10]. For deployment automation, that means Lambda execution roles and none of the broad administrative ones ^[10]. The scworld.com explainer says narrowing role trust policies to specific services and adding conditions such as iam:PassedToService limits which roles can be delegated and into which service contexts. The same explainer says the constraint does not block legitimate automation ^[11].

That explainer describes the pattern and its controls, and reports no incident, actor or affected organisation. The test it sets for tooling is whether the analysis can flag an identity holding both resource-control permissions and delegation permissions aimed at roles broader than its own. The second half of the test is validating that path against trust policies, permission boundaries and SCPs ^[15]. Without that correlation, PassRole in a review looks like routine automation enablement ^[9].